The Code[ish] Podcast is back! Join Heroku superfan Jon Dodson and Hillary Sanders from the Heroku AI Team for the latest entry in our “Deeply Technical” series. In this episode, the pair discuss Heroku Managed Inference and Agents—what it is, what it does, and why developers should be using it. 

Hillary also shares tips for new developers entering the job market, and Jon pits 10 principal developers against one hundred fresh bootcamp graduates (hypothetically, of course).

A brand-new season of The Code[ish] Podcast is on the way! 

Loads of insightful episodes are on the way, featuring special guests from all corners of the Heroku community. 

This episode is a conversation led by Greg Nokes, a Product Manager with Salesforce, Dan Mehlman, a Director of Technical Architecture for Salesforce, Mike Rose, a Director of Technical Architecture for Salesforce, Jack Ziesing, a Technical Architect with Salesforce. They're interviewing Nick Sawhney, a college student who saw an opportunity to make his friends laugh and built something that grew beyond his wildest dreams. At the 2021 US Inauguration, a single shot of Bernie Sanders sitting in a chair captured the hearts of many on the Internet. People everywhere were photoshopping him in the unlikeliest of places. Nick utilized his Python skills and quickly built a Heroku app that would allow users to place Bernie anywhere in the world, by adding him to any image available on Google Street View.

To say the app was a success was an understatement. Inundated by tweets and distracted by press requests, Nick couldn't devote the time needed to keep the app stable and operational. He sent out a desperate tweet for help, only to be picked up by no less than Dan and Michael, who recruited Jack to help Nick with his operational issues. They paired together in a number of ways, optimizing Jack's Python code, securing its authentication logic, and autoscaling dynos in order to handle the waves of traffic. All of these rapid changes allowed Nick to step back and engage with fans on where they'd like to take Bernie next.

In addition to a newfound gratitude towards Heroku's team, Nick learned a few lessons from this experience. He was really humbled by the availability of the engineering community to donate their time and knowledge to help his issues. It's also inspired him to create videos to teach others how they can mitigate scaling issues in their architecture before it becomes a problem. He's also hoping to create some open source tools that to monitor things like server costs and availability issues for other small projects.

Aaron Schlesinger is the core maintainer on Athens, an open source on-prem module proxy. He walks through the history of packages and modules in Go, and introduces how Athens satisfies the needs of developers. Go modules allow you to serve up a Go project's dependencies via an API; Athens implements that API--and integrates with other implementations of the API as well--to simplify dependency management, no matter where the code is stored.

Beyang Liu is the CTO and co-founder of Sourcegraph, a company that focuses on developer tools. They use Go to build high-performance code search, code intelligence, and jump to def functionality that works across repository boundaries and across entire code bases. Their role at GopherCon 2019 is to live blog all of the talks for interested parties who were not able to physically attend the conference.

Liz Rice is a technology evangelist with Aqua Security. It's a container security company, and she came to GopherCon to teach a workshop that introduced people to the concepts behind containers. She also recently became a Google developer expert in Go, which certifies her as someone creating interesting content that the community can look towards for education and inspiration.

Johnny Boursiquot is an SRE at Heroku, and a long time gopher. He gave the closing keynote at GopherCon, and his singular focus is on ensuring that the Go community is truly diverse and welcoming to new members. Every year, new developers attend GopherCon, and he wants to encourage veterans to embrace this growth as a positive change. He also provides a wealth of resources on listeners who are brand new to Go and eager to learn more about it.

• Athens Project is a proxy server for the Go modules download API
• Several resources for newcomers to Go include:
  • A Tour of Go
  • Go by Example
  • Go Bridge workshops
• Aaron Schlesinger's talk, "The Athens Project"
• Johnny Boursiquot's closing keynote, "What Got Us Here, Won't Get Us There"

Chris Castle recently attended GopherCon 2019 in San Diego, and captured small conversations from many different Go community members. In Part One of a two-part episode, he had several conversations with GopherCon speakers about what they were building.

Nick Gerakines is the Director of Software Engineering at Mattel, the toy company. Mattel has several toys with Internet connectivity, and Go is the primary language used for all of their connected products, whether it's to support authentication and parental controls, or providing product catalog and product instance information. A lot of core gameplay mechanics, such as the number of "miles" a car has ridden on a track, are also transmitted and reported through Go services.

Robert Ross works at FireHydrant. They're using Go for their Kubernetes integration and internal developer tools for local development. For example, they are able to build Docker Compose files on the fly. His favorite aspect about the language is that it can build a portable (and performant!) binary with very few lines of code.

Jessica Lucci is an infrastructure engineer at GitHub. Her interest in Go is catered towards establishing some standardizations beyond simple code formatting. For example, with the recent introduction of Go modules, devising a system around versioning third-party libraries is an interesting problem, particularly when it comes to pinning versions for consistency or updating versions in the event of a CVE.

Tim Raymond works for Gopher Guides, and conducted a training session on testing your Go code. His favorite aspect of GopherCon is its community, where new and old friends meet to share their interests.

Jay McGavren is the author of Head First Go, a programming book designed to teach programmers about how to be effective with Go. It will take Go beginners from basic language features all the way to coding a simple web app.

Carolyn Van Slyck works for Microsoft, and she's used Go to design her perfect CLI. By focusing on the developer experience, she was not only able to abstract away some of the harder tasks which a user might rely upon piping several commands together into one, but she also isolated some of the CLI-specific aspects, such as argument parsing, for future developers to feel more confident when contributing to the project.

• The Mattel Hot Wheels id toy is powered by Go services
• Modules are a newer system of dependency management for Go
• Head First Go is a programming tutorial for Go, written by Jay McGavren and published by O'Reilly Media
• Gopher Guides leads Go workshops for interested individuals
• Jessica Lucci's talk, "You Can't Go Your Own Way"
• Tim Raymond's lightning talk, "Parsing Expression Grammar"
• Jay McGavren's talk, "Teaching Tech", on effectively teaching programming
• Carolyn Van Slyck's talk, "Design Command-Line Tools People Love"

Joe Kutner, an engineer at Heroku, leads the discussion on Cloud Native Buildpacks with Stephen Levine (engineer at Pivotal), Emily Casey (engineer at Pivotal), Ben Hale (steward of the Java Buildpack), and Terence Lee (engineer at Heroku). All of them are involved in overseeing the CNB project, and have used the technology in production at their companies. At its core, CNBs are an OCI-compliant alternative to Dockerfiles, except the container is built without very much developer interaction. By analyzing source code, CNB is able to determine the base image to start from, as well as which steps to undertake in order to ensure that an application runs correctly. It's a similar logical process to the way in which Heroku's regular buildpacks operate: one Git push command is all that Heroku needs to generate a slug of your application, including fetching any dependencies or managing assets.

A Buildpack provides you with consistency by keeping your dependencies and base image up-to-date to the latest standards. It also doesn't require the average application developer to also be an expert on everything. Rather than needing to understand all of the Unix-y commands necessary to compose an application, or knowing when a particular component has a CVE, a developer's chief concern concern is to continue building their app as usual, and CNB will handle all of the other components necessary to make a deployable container.

The aim for CNBs was to make development easier for individual developers, as well as those at large enterprises. Terrance and Ben in particular know that the value of the buildpacks come from five years of production experience. Regular applications have benefitted from buildpacks, and the ecosystem around those had grown to the point where they could take what they'd learned and apply them to container images as well.

The episode concludes with a look towards the future of CNBs. As all of the APIs and tooling are open source, groups can also design CNBs for any language and framework they wish to containerize. The project recently entered beta, and, despite the positive reaction, there are still some changes that need to be made with regards to how changes to buildpacks are applied. There are processes for community members to be involved, and multiple forums for communicating with the CNB leadership team.

• Buildpacks.io is where you can go to learn more about Cloud Native Buildpacks
• Discussion for proposals to CNB happens on GitHub on GitHub
• There's a Slack workspace where developers and users congregate

As part of its product suite to automate a business' needs, Salesforce offers a Live Agent product, whose central component is a chatbot that can respond to a user's inquiries on the web or other messaging platforms, such as Facebook or SMS. A key design requirement of the chatbot is to be able to simulate human interaction by responding quickly. For an engineering team of eight, that means being able to offload as much operational responsibility as possible to Heroku's platform.

Salesforce's customers exist around the world, from Europe to Asia to the Americas. Heroku provide multiregional offerings for its dynos and databases that don't require too much administration or configuration. The benefits of not needing to define roles or specifications further simplifies the chatbot team's own architectural decision to design it as a collection of microservices.

Furthermore, the chatbot team uses Terraform to define the infrastructure requirements of their application. By predefining the necessary add-ons, data services, and private spaces for every application, they are able to quickly spin up new external services whenever necessary.

• Salesforce's Live Chat is powered by chatbots to reply to users' issues in real-time.
• Heroku buildpacks are open source packages which turn an application's source code into an executable slug. The Salesforce chatbot team built their own customized buildpacks to support their unique needs.
• Terraform offers a provider that integrates with Heroku

Cory Haber is the VP of Technology for Furnished Quarters, a global corporate housing company. But he's also an educated painter. He's interviewed by Erin Allard, a Platform Support Engineer at Heroku, to delve into the effect technology has had on art, and vice versa. For Cory, art is about the intent of the artist; it's a moot point to ask whether anything a computer produces can be considered art. In the end, a human has trained an AI or written the software, and the computer becomes a tool, similar to a camera or a pen.

Engaging in artist practices allows Cory to take a break from the purely logical examinations which programming requires of him. To some, it may be seen as procrastination, but he believes that the best way to solve a problem is to allow your mind to wander of. That's what his current painting practices allows him to do. At the same time, he also follows along on the generative art movement, which takes place primarily on Twitter. There, artists and programmers share their programs that generate art that can be represented on screens or canvases.

The history of generative art goes back to the 60s. For individuals curious to learn more about this practice, he recommends the Processing programming language. Similar to a Jupyter notebook, it's a part-framework, part-application hybrid that works in generating visual arts. He also encourages individuals with no artistic background to just start taking classes on painting or music. No one knows everything about programming when they first start; they learn the skill and become better at it the more time they invest. Art is created under a similar focus.

Cory has compiled a list of resources with more information on the intersection of technology and art:

• Vera Molnar
• Lillian Schwartz
• Ken Knowlton
• Frieder Nake
• Georg Nees
• Michael Noll

• Tyler Hobbs
• Paul Rickards
• Benjamin Kovach
• Anders Hoff
• Matt Deslauriers
• Manuel Gamboa Naon
• Casey Reas (Co-Founder of Processing)
• John Maeda
• Jared Tarbell

• Robbie Barrat
• Mario Klingemann

• Processing
• openFrameworks

• Art Nome
• The Coding Train
• Daniel Shiffman
• Books on Generative Art
• Manohar Vanga

• Piet Mondrian
• Sol Lewitt
• Hilma af Klint
• Kasimir Malevich
• Wassily Kandinsky
• Joseph Albers

Trey starts the conversation with Shirley by noting the difference between being a manager and being a leader. Managers are a framework for discussing pay, onboarding and offboarding, HR interactions, and so forth. Leadership is about inspiring others to unite together to work behind a purpose. Any IC, for example, can be a leader for just a handful of his teammates. Being a good leader means knowing what's important, conveying that to someone else, and executing on it.

To do that, Trey emphasizes that a foundation of psychological safety is essential. Allowing people to speak up when they disagree with an issue, or admitting your faults when you've made a mistake, is an incredible method of breaking down barriers between people and fostering a culture of truth. Fostering individual growth is also a good strategy, as people generally want to continue improving, whether it's learning a new programming language or a new technical system they're curious about. Removing obstacles to people achieving their goals is key as a leader.

Shirley notes that the role of a leader requires an immense amount of mental and emotional energy, as your concerns are not just your own, but also those of the people who rely on you. Trey responds by emphasizing health as an important priority that's often neglected. Individuals will take better care of their pets than themselves. By demonstrating that he is not infallible, by taking vacations, encouraging exercise, or ensuring enough hours of sleep, his team in response understands that taking breaks is a good decision, not a dangerous one.

Finally, communication is always necessary. If there are too many distractions that prevent you from accomplishing an objective, you should tell your team you'll need some quiet time, rather than silently disappear. If you're concerned about a path a company is embarking on, you should tell a leader you feel comfortable talking with. Communication breeds trust, and that's the foundation of any successful relationship.

Trey recommends several books on effective leadership:

• "Chasing excellence"
• "The Score will Take Care of Itself"
• "Extreme Ownership"
• "Dichotomy of Leadership"
• "Drive"
• "How to Win Friends"
• "Crucial Conversations
• "Slack"

Design is at the very core of Heroku, influencing every aspect of the brand and the platform.

Join Vikram Rana, product marketing and developer advocacy lead at Heroku, as he chats with Heroku’s head of brand design and front-end developer Charlie Gleason on his role—covering his history and background, what it’s like to work at Heroku, and how he handles being a custodian for a brand he loves.

From tooling, to teamwork, to the ethos of the brand itself, Charlie and Vik dig into what makes good design (and more importantly) what makes design good. They cover topics like ethics, empathy, humility, education, and bringing your authentic self to work.

(Also, one correction—The Cut is based in Perth, not Melbourne. Sorry, Scott.)

• Charlie Gleason
• Goodfilms
• Unbound
• The Cut (which is based in Perth, not Melbourne)
• Heroku Brand
• Heroku Design
• Alasdair Monk’s GitHub
• Whimsical
• Figma
• Sketch
• Web Assembly / WASM
• Adobe Creative Suite
• Tailwind CSS
• Refactoring UI
• Airbnb design
• Glitch
• Offscreen Magazine
• Kai Brach

Getaway is a startup that offers short-term rentals. They specialize in ensuring that the domiciles they offer are far outside city limits and often inaccessible to Internet and cellular connectivity.

Zach Feldman, their VP of Technology, chats with Jason Salaz, a member of the Heroku Support Team, about the unique challenges this requirement imposes. For example, rather than providing a physical key, guests can unlock their cabin door's smart lock with a unique pin code. In order to support their efforts to scale, a custom API was built to ensure that pin codes are registered and deactivated for every check-in and check-out.

Cabins are also equipped with other IoT automation devices, such as leak sensors, which report back to Getaway House if pipes are leaking. Both of these technologies were designed to work on the low latency connections that the cabins are equipped with.

Relying on SMS is another way that the team is able to provide service, as those networks predate much of the current infrastructure that smartphones have come to rely on. Building correct and functional software is difficult, but Zach notes that there's an even greater challenge in scaling fault-tolerant systems in the woods.

• Getaway is the service featured in this episode
• POTS lines are still in service to provide telephone service in remote locations

Heroku Front-end Engineer Jamie White sits down with René Winkelmeyer, a developer evangelist at Salesforce, to talk about the company's commitment to advancing web components. Web components are a collection of standardized web and browser APIs designed to overcome some of the limitations with the design of the Internet, particularly when it comes to page rendering. Web components exist outside of web frameworks such as React, Ember, or Vue in that they are built using standard web technologies and can be used in any application, regardless of the framework or language it's architected in. They're built for reusability and consistency across your application's UI.

Lightning Web Components is a toolkit built and open sourced by Salesforce to ease the development of web components. These components are Enterprise-level, in that they provide functionality for many complicated UI scenarios. Although there are other web component frameworks, such as LitElement, a core goal of LWC is to make the process of building web components more declarative.

The conversation turns towards attracted Salesforce to investing time in web components, with the conclusion being that open standards would continue to succeed in the future when compared against closed and proprietary tools. Their focus is also on ensuring that accessibility needs are met for every user of a website.

• The Lighting Web Components site has more information on LWCs, including documentation and a demo application.
• The LWC GitHub repo is where all of the community conversations occur.
• LitElement is one alternative web component framework
• You can follow René on Twitter @muenzpraeger

The web started off weird, and there’s a wonderful and concerted effort to ensure that, at least parts of it, stay that way.

Heroku designer Charlie Gleason and lead strategist Stephen Barlow dive into their experiences working on side projects—small, silly, funny, and emotive vignettes on the web—that span random Arrested Development episode selectors, Kanye West browser-based mini games, collaborative art projects, and everything in between.

Learn how to get involved with your own community of makers, why it’s more important to have fun than it is to try and get internet famous, and some things to look out for when working with others.

So, put away the kanban board, get inspired, and keep the internet weird with a side project of your own.

• Charlie’s music video, Tweetflight
• Stephen’s Kanye Zone
• Stephen’s community, Botnik
• Indie game company, Blyts
• Matt Desl (canvas-sketch)
• Jenn Schiffer
• Glitch
• Tim Holman

Chris Castle, a developer advocate at Heroku, is joined in conversation with Andrew Lenards, a 20-year programming veteran and meditation coach. He believes that meditation is the practice of familiarizing one's mind with its various states.

Concentration is the ability to place attention on something for as long as desired. Clarity is about identifying the sensory experiences in your body. Equanimity is about accepting the state of the world around you. In programming terms, mindfulness becomes a sort of monitoring and observability tool for our bodies.

Andrew suggests that curious listeners focus their attention on sourcing materials from secular sources. As well,the benefits of meditation can only come after quite a bit of time. The inclination of most starting practitioners is to quit before investing to see the benefits. Even if you feel like you're doing it "wrong" or feeling your mind get distracted, the core tenant of the practice is to not judge yourself. This in turn will help bring about the calmness which meditation can offer.

• "The Mind Explained"
• Niksen is a methodology focusing on "doing nothing"
• Mindfulness-based Stress Reduction
• "The Art of Noticing"
• Search Inside Yourself
• “99% Invisible” podcast
• Meditation information on Andrew's site: lenards.us and Afternoon Idle - 15 min guided meditation via a YouTube live stream
• Headspace, Calm and Ten Percent Happier are just a few apps which can help your meditation practice

Chris Castle continues his conversation with Claire Lee, the head of the early stage group at Silicon Valley Bank. In this half, Claire begins by providing hard data that indicates companies which are founded by individuals from diverse backgrounds are wildly profitable. She goes on to say that conversely, the members in the top VCs firms are of a disproportionate make-up. She concludes that in order for more funds and ancillary services to be available to start-up founders, the individuals distributing the capital also needs to change, in order to give everyone a fair shot at success.

Claire goes on to point out that in addition to money, mentorship is a valuable (and limited) resource in Silicon Valley. A good partnership with a VC includes them granting access to advisors, potential board members, and potential customers. Her passion extends beyond just funding good ideas; it's about making connections between people and helping them to grow.

The episode concludes with advice and encouragement for anyone interested in founding a start-up. If you feel that you can solve a problem in ways that no one else has before, that passion will manifest itself into an opportunity in one way or another, whether that's within a start-up accelerator or in a digital community. Surround yourself with people who believe in you.

Several resources for founders just getting started with their idea were mentioned on this episode:

• Startup Grind
• Tech Stars
• Endeavor Global

For legal assistance, the following firms were offered:

• Cooley
• WilmerHale

For staffing, Atrium was one option which Claire named.

Chris Castle sits down with Claire Lee, the head of the early stage group at Silicon Valley Bank. Claire discusses the various startups she is involved with across various sectors, such as cleantech, fintech, and healthcare. Much of the conversation revolves around her experience at Recode's Code Conference 2019 and three lessons she took away from her attendance.

First, media platform companies such as YouTube, Facebook, and Twitter need to make large changes to become more transparent. Their user base is losing trust due to the persistent problems of hostile environments, hate speech, and misinformation.

The second takeaway was on the role of technology throughout our lives. For example, automated content moderation through AI can only go so far, as the technology behind them require a certain baseline standard of ethics which is as yet to be defined. A generation of new users are looking for tooling to place constraints on bad actors, which are problems that have not been tackled at scale.

Finally, Claire's third realization was the adaptation of technology in decidedly non-startup environs. For example, she cites how both Harley Davidson and Goldman Sachs are revolutionizing their businesses to adapt to both new consumer needs and to attract engineering talent. Both consumers and employees are demanding better corporate values before acquiring or working for a brand.

• Recode's Code Conference is the world’s premier technology conference.
• Steven Sinofsky's blog post summarizing CodeCon 2019.

Matte Noble is a Senior Software Engineer at Sentry, an application with the capability to stitch together different developer tools through their APIs. For example, an exception that occurs in your application can be automatically represented as an item in your project management tool's backlog. On top of this, Sentry provides a platform for tools to also integrate with. Matte identifies his past work experiences as leading him to conclude that when building an application like this, it's important to consider your two types of users as having distinct concerns: one group is content with using the product as-is, and another group is the set of developers who are building tooling and integrations for that first group. By intentionally building your product as a set of APIs that communicate with various systems, you simultaneously build features your users want that your integrators can build on top of.

In order to design a good interface, Matte says that it's important to keep the responses concise, in order to avoid blurring the lines between individual resources and their responsibilities. In order to translate your internal understanding of your product's primitives into something consumable, it's important to listen to your customers and ask what their needs are, before simply exposing an API that is hard to change once it's public.

Sentry's primary technical challenges are surfaced in one of two ways. First, there's an issue of consistency, in that if two services are being connected, and one of them fails for some reason, Sentry is responsible for reacting to that, even if the external service did not provide any indication that something went wrong. Second, while Sentry is sufficient at handling large volumes of data, the same might not be true of a service they are pushing data to. In order to make Sentry scalable, it's not just a matter of working with their own engineering and product teams: they must also be mindful of third-parties over which they have no control.

The episode concludes with Matte's advice for any organizations interested in offering an add-on marketplace. For him, it's about providing capabilities that make the integrator want to integrate with your platform. For example, if billing is a component of the marketplace, it's important to build tools and features that allow an integrator to understand the revenue that they're making from your ecosystem. It's also important to focus on request/response times and errors rates, so that you can have the confidence in the health of those integrations and fix potential issues as soon as possible.

Chris Castle sits down with Shirley Xu, who went through a coding bootcamp, and Eric Chen, who is a recent graduate, to talk about their journey into their first programming jobs at Heroku. For both of them, the experience of programming in a day-to-day role is vastly different than what they experienced at school; namely, rather than analyzing algorithms, they were exposed to Ruby, Rails, and entire groups of people involved in shipping features. They recognize that they went through a period experiencing imposter syndrome, before realizing that every developer, no matter their status, shares those same feelings.

Certain soft skills were also acquired. Eric learned how to move past his fear of looking ignorant and just ask questions whenever he didn't know a term or a process. He felt that this made him into a better engineer and, besides which, no one had ever refused to explain a concept. Shirley discovered that in order for her to achieve her goals, she needed to express them clearly to her mentors and manager. For example, after she expressed that she would one day like to become a technical lead or manager, her mentor was better able to develop a long term plan of the concrete steps that Shirley would need to take to get there.

Tech moves fast, and a portion of this episode is dedicated to how everyone keeps up with the latest trends and terms. All agree that the breadth of knowledge is simply too much to consume, and it's okay to not know everything. That doesn't make you a better or worse developer: it simply means your expertise lies elsewhere.

The episode concludes with some advice for anyone not in software development, but is considering a change. Eric suggests keeping yourself motivated, with time blocks in your schedule dedicated to simply learning. Shirley provides a long list of resources, as well as a six-to-twelve month timeframe to go from a neophyte to your first job.

Several coding bootcamps and online tutorials were mentioned as possible starting points for those interested in transitioning into a career in tech:

• HackBright
• CodeAcademy
• PluralSight
• L'Ecole No 41
• freeCodeCamp

Josh Aas, the co-founder of the non-profit Internet Security Research Group (ISRG), is interviewed by Craig Ingram, a Runtime Engineer at Heroku. Amongst other outreach programs, ISRG is in charge of developing Let's Encrypt, which is a Certificate Authority (CA) designed to provide free TLS/SSL certificates to any website on the web. While starting ISRG in 2013, Josh noted that only about a third of websites on the Internet were secured by HTTPS. He discovered that not only was the price of acquiring a certificate a barrier to entry, but the technical requirements to apply a certificate was also cumbersome. Let's Encrypt began as a way to simplify the application of aTLS/SSL certificate for any website.

Founding a CA was no easy task. To begin with, a brand new CA is "untrusted," and it takes up to a decade for every company and Internet-ready device in the world to accept your validity. In 2015, Let's Encrypt partnered with another CA called IdenTrust by having them cross-sign certificates. This allows Let’s Encrypt to operate and provide certs while making progress towards becoming a fully independent CA.

Over the years, there have been several trade-offs between Let's Encrypt original goals and features that users have requested. Although ISRG would like to limit the technical scope of what Let's Encrypt offers to keep the process simple, they have worked through feedback to ensure that they meet a majority of their users' needs. Although HTTPS certainly helps secure communication between a user and a website, there are still more layers of the Internet which require protection. One of these is called Border Gateway Protocol (BGP) hijacking. The team is working on mitigations to make these sorts of attacks impractical.

• Let's Encrypt is a free, automated, and open Certificate Authority with the goal of creating a 100% encrypted Web.
• The Border Gateway Protocol is, in Josh's opinion, another major component of the Internet which requires stronger security.

Tyler Montgomery, Trailhead's engineering director, and Shaun Russell, its principal engineer, kick off a conversation with Chris Castle as to how Trailhead came about. One of Salesforce's developer evangelists, Josh Burke, wanted to create some teaching material for classes he taught. The idea was that students wouldn't just read some content and take a quiz; they would perform real actions, such as making a dummy user an admin, and an API call would assert that they accomplished the task successfully.

Due to its tight deadline of just six weeks before Dreamforce, the Trailhead team built the app using Ruby and Rails, and hosted the site on Heroku. Although they've seen huge growth, a lot of naive technical decisions have lead to a mix of addressing performance issues as well as launching new features over the past few years. Their largest near-outage came about when hundreds of thousands of students in India began to use the site all at the same time in order to participate in a competition. Heroku was able to scale up, but this exposed many problems which, when the traffic subsided, better prepared the Trailhead team for future scaling issues after all the code fixes were in place.

The conversation concludes with advice on scaling up an application on Heroku. Shaun suggests an APM tool like New Relic to stay on top of performance problems before they become an issue. Tyler suggests implementing an entire pipeline of tooling--PagerDuty, errors logged into Slack, segmented environments for staging and production--before continuing work on any feature code.

• Trailhead is an e-learning platform focused on Salesforce and other web technologies
• New Relic is a monitoring tool for an application's performance

Terraform is an open source project to help automate the provisioning of infrastructure resources and services for your application. It integrates with cloud platforms through open source plugins, called providers. Mars Hall is a Heroku engineer that works on the Heroku provider. Rather than using a CLI or a web UI, Terraform provides a platform-agnostic configuration file written in the Hashicorp Configuration Language, or HCL. This sets Terraform apart from similar tools like Chef, which relies on Ruby, or Ansible, which only relies on provisioning server state.

The conversation veers towards the architecture of a provider and how individuals can contribute to the Heroku provider integration. Essentially, a platform exposes some HTTP endpoints that a provider than communicates with. This means that while open source community can contribute to a provider, there are some feature requests which are dependent on the platform exposing accessibility first. Mars suggests that individuals first open an issue with their request, and a Heroku engineer will convey whether that's on the roadmap or free to accept pull requests. Although HCL is easy to learn, all of the providers—and Terraform itself—is written in Go.

Some best practices are provided for larger organizations interested in working with Terraform on Heroku. Among these include strict guidelines for always using Terraform to manage an app's configuration; using consistent naming schemes to indicate that an app is managed by Terraform; and relying on provisioner health checks to help guide Terraform's automation steps. The episode ends with a look forward at the next release of both Terraform and Heroku's provider plugin.

• Terraform, an open source program to create and change infrastructure, is the core subject for this episode
• On GitHub, the Terraform Providers organization lists all of the open source providers that work with Terraform
• Using Terraform with Heroku is a Dev Center article with more information on the integration of Heroku with Terraform

Léonie Watson does many things: she worked on overhauling the UK government's digital services, is on the W3C advisory board, acts as co-chair of the W3C web platform working group, is an advisor for Google's Accelerated Mobile Pages project, and also runs the Inclusive Design 24 conference. She also happens to be visually impaired. The show begins with how she went from drama school towards a career as a web programmer, and how she become a strong advocate for improving accessibility in web standards.

Léonie stresses that anyone can get involved in the decisions that power the web by contributing to the W3C's public conversations at GitHub. She details the lifecycle of a proposal, and highlights how considerations such as accessibility, security, and privacy are built-in. While existing standards are well-conceived for realms such as SVG, HTML, or ARIA, there are still new frontiers to work towards every year, particularly with API-driven interfaces. Léonie mentions how the interfaces for the "Internet of things" still need to make progress to ensure those devices are usable by all.

There are several tools to help software developers build more accessible systems. Chrome's Dev Tools, for example, have a suite of checks you can run on a website to grade its accessibility. Platforms such as Axe or Tenon can run automated tests as part of a CI flow to maintain high quality code before it ships. For Léonie, it's important for designers, developers, and product managers not to be overwhelmed by all the requirements and allow perfect to be the enemy of good. Even attempting inclusive design advances technology towards a much better place.

The conversation continues with some discussion on Léonie's work with TetraLogical, a consultancy focused on accessibility in emerging technologies, such as virtual reality, augmented reality, and WebXR. By setting a standard for inclusive design principles, Léonie hopes that organizations can incorporate accessibility as yet another aspect of good design, beyond just the bare minimums required by tech specs and test suites.

• Nomensa and The Paciello Group are two agencies Léonie Watson worked at. Their focus is on better UX for web accessibility. She's since founded TetraLogical, which focuses on accessibility issues in emerging technologies like VR, AR, and WebXR.
• GitHub.com/W3C is the central meeting point for many of the discussions on web standards
• tink.uk is Léonie's blog, focused on accessibility in web standards
• Inclusive Design Principles is a set of guidelines on how to go above and beyond in making your site accessible
• Axe is an accessibility engine for automated web UI testing.
• Tenon is an "accessibility as a service" platform for websites.

Designer and front end developer Charlie Gleason and developer David Routen are both on Heroku's marketing team, and both of them transitioned into the world of programming from disparate career paths. For them, moving into tech was about following their passion for creative problem solving. They did so by first creating a plan for what they needed to learn. After viewing several job postings, they got a sense of what skills each potential employer required, and then set about to learn them. Fundamentally, they believe that a strong grasp of the building blocks of the web, like HTML and CSS, plus at least one other higher level language (JavaScript, PHP, Ruby, Python), is a great way to get started. There are many free resources to learn programming on the web, but there are also more structured courses which you can pay for.

In order to practice those skills, they recommend speaking to members of your community who need basic web work done, and asking if you can volunteer there in exchange for putting the work in your portfolio or CV. This will show potential employers an idea of who you are and what you're capable of. Even if programming isn't your thing, there are loads of other roles as well, such as data scientists, project management, or software quality assurance. As well, following people in the industry—either through their blog, Twitter, or local meetups—is a great way to network and hear about additional opportunities.

• Adobe Creative Suite
• Figma
• Sketch
• Airbnb.io
• Facebook Open Source
• Codecademy
• Udacity
• edX
• Udemy
• Google Web Fundamentals
• Pluralsight
• A link to ‘Learn how to program’ in a search engine

This episode begins with a roundtable introduction from five Herokai engineers who describe what motiviated them to speak at their first conference. If you're a first-time speaker, it's best to let conference organizers be aware of this, not only because they will support you, but also because they will try to give you a prime time slot in order to boost your message (and spirits).

The group then delves into how to prepare and practice for your talk. In general, they agree that improvising is not a good idea, unless you're absolutely an expert in the subject matter. You should also be able to account for the lack of Internet access, which means that live coding is also not recommended. Every speaker is nervous, no matter how many talks they give, but everyone in the room wants you to succeed, and doesn't know if you've skipped a specific sentence or word. It's best to just roll with the flow.

In terms of deciding the subject matter, some of the engineers pick two or three variations on a single topic, and try to submit each flavor to as many conferences as they can. Another strategy is to hone one really unique angle--or even choose a subject matter that is so "common" to a developer's day-to-day routine they don't think about it. Those sorts of talks get people to really engage in something they may have never realized before.

The conversation concludes with ways to get better at public speaking, whether that's rewatching your recorded self and noticing your body language, or simply giving the same talk at another conference, and building on what works.

• Fog City Ruby, a San Francisco-based meetup about Ruby, co-organized by Stella Cotton
• caffeinate, a MacOS app which prevents your laptop from entering Sleep Mode

Nowadays, the internet is so huge that it can be hard for people to find others who share their niche interests. But when they do find that rare kindred spirit, it can feel like a magical moment. Lynn Fisher and design agency &yet have been exploring ways to help people build community around their passions (which can sometimes be a little “weirdâ€). The team launched a project called “Find Your Weirdos†that incorporates different tools, sites, and techniques for helping people connect with their fellow weirdos. Their project also helps companies connect with customers through niche interests.

Inspired by the Weirdos project, the &yet team envisioned ways to help Heroku developers connect and the Wicked CoolKit was born. The kit harkens back to the earlier days of the internet, when simple, fun web widgets and tools helped people connect without all the noise of today's mega social platforms. The initial version of the kit offers a new take on a few nostalgic web widgets, including:

• Developer trading cards — Echoing the retro joy of collecting baseball cards or playing card-based games, this widget allows developers to create their own profile card. They can specify their personal bio, coding skills, niche interests, “feats of strength,†and more, and share it within an elegantly designed UI.

• Themed stickers — A perennial favorite, stickers are a colorful way to identify interests, such as baking or woodworking. Users can download stickers to use as they wish, or add a sticker to their trading card that links to other people’s cards that have the same sticker.

• Webring — Years ago, fans and friends would use a webring to share a collection of websites dedicated to a specific topic. The kit brings the old school webring into the modern context and allows people to easily share and access web resources.

• Hit counter — Everyone wants to know how many visitors came to their site. The old-fashioned hit counter is a fun way to track and display page visits. The higher the number, the more likely people will want to engage with the site (and the developer behind it).

The Wicked CoolKit is fully open source and available to use.

• Lynnandtonic.com — Lynn’s personal website.
• wickedcoolkit.com — Home of the Wicked CoolKit
• Show, don’t tell — the story behind the Wicked CoolKit.
• Find.yourweirdos.com — a series of essays on how companies connect with customers through sharing mutual niche interests.
• Face.camp — an app that connects to Slack for people to capture and post animated gifs.
• Wegotchu.cards — digital cards that people can pass around and sign.

For many years, Jeff Dickey was a lead architect for Heroku's CLI tool, which was used by application developers to get their apps deployed to Heroku's platform. He muses on his history with CLIs with Nahid Samsami, a director of product at Heroku, as the two of them worked together on oclif.

oclif was designed from the start to be a framework for developers to use when building their own command-line interfaces. It's currently written in TypeScript, but Jeff goes through its four-year history, starting with its roots in Ruby and on thorough its Frankenstein's monster mashup of Go and JavaScript. While each language had its pros and cons, the key constraint was how the resulting command-line binary program would be distributed.

The project has been incredibly popular, both through internal adoption at Heroku and Salesforce, to its reception and use from other companies, as well as the active contributions made on GitHub. The episode concludes with some theories about the future of CLI tooling. PowerShell, for example, is a fully object-oriented environment which a developer can program against. Jeff is also interested in better integration between the terminal and UI elements.

• oclif.io, the main landing page for learning more about oclif
• Microsoft's Powershell, which Jeff believes is the most incredibly advanced CLI platform

Francis Lacoste, a Director of Engineering at Heroku, is a longtime meditation practitioner. In 2015, he attended public seminar on mindfulness by the Search Inside Yourself Leadership Institute, which was co-founded by a former Google engineer. The workshop emphasized mindfulness as a benefit to businesses by framing the mental health benefits as something that could improve worker productivity. Enlightened by this discovery, he worked to bring the lessons over to Heroku.

Heroku's remote culture introduced some challenges to the original structure of the program. Participants are connected through Zoom meetings, rather than being seated in a room together. As well, the workshop take place over the course of a week, rather than two very long days. Herokai have responded very positively to the lessons, and some have earnestly applied the practices at home and with their families.

The actual practice itself is very secularized, even though it draws on Buddhist traditions. Francis Lacoste believes that culturally, we are not given the appropriate tooling to deal with conflicts and stress, and finds mindfulness to be a fantastic aid to those problems.

• Search Inside Yourself
• DIY Meditation Guide
• Social Meditation

With the explosive growth of people using, and contributing to, open source projects over the last decade, more and more of us are spending their time reading, writing, and understanding documentation.

Heroku's Dev Center is the central hub of documentation for Heroku, covering everything from getting started, to how Heroku works, to extending the platform. It acts as a manual for the entire platform, spanning an enormous number of topics and tools.

Stephen Barlow, lead strategist for Dev Center, joins Heroku designer / developer Charlie Gleason to discuss why good documentation is so important—from some of the common challenges you and your team might face while writing them, to advice for rationalising and improving your documentation workflow.

Tune in to learn why good docs aren't just good—they're great.

• Heroku Dev Center
• Heroku Buildpacks
• Rust
• Create React App
• Write The Docs Conference
• Prettier
• Typescript
• Git hooks and Husky
• Runbooks
• Heroku Changelog
• Stack Overflow

Vaidehi Joshi found that many resources on the web about core computer science concepts she wanted to know more about were either too obtuse or too academic. She started a blog, basecs, where she wrote down something she had learned that week--every week--for an entire year. While learning something new in and of itself was a delight, her curiosity led her to question how people learn best.

She discusses the Feynman Technique, which, through a processes of iteratively explaining a concept to someone who doesn't know anything about it, strengthens the knowledge for both the student and the teacher. The best way to do this is by telling a narrative. It keeps the listener engaged, while also serving as a way of identifying gaps in ones' own understanding, as new questions arise.

• basecs and baseds are two of Vaidehi's websites which teach concepts about computer science and distributed systems
• The Feynman Technique: The Best Way to Learn Anything

Heroku splits its units of work into squads; on this episode, we're joined by some members of the squad responsible for the Private Spaces feature. Every member of the squad is remote from one another. The team talks about the pain points around this setup, and the solutions they've set up to minimize feelings of isolation. One tactic has been to keep a long-running meeting URL. Individuals from around the team can hop in and enter a space where they can just be social with one another.

Each teammate also explains why they joined Heroku, and what they appreciate about a company that values remote work. They conclude with a discussion on their favorite programming languages and editors.

• An introduction to Heroku's Private Spaces

Chris Castle introduces Becky Jaimes, the product manager for Heroku Dataclips. Dataclips is a feature that allows you to save and version SQL queries against a Postgres database. You can export these queries to JSON or CSV, share them online, or simply access them through an HTTP API.

The two discuss the history of Dataclips, namely what its original needs were and how it has evolved. It was originally targeted towards individuals who simply wanted a quick way to get access to rows from a database, and now it's grown to be a useful source of information for BizOps teams, engineers, and product managers.

The newest release of Dataclips came out of a very long beta program involving customers of various sizes. Some customers had a few dozen queries they accessed frequently, while others had thousands of them. The team at Heroku wanted to create a one-size-fits-all solution, while at the same time reducing technical debt which had been a hinderance to shipping quickly. Becky shares some of the features that are now available.

• A Dialog with Your Data Using the New Dataclips
• Dataclips is often used as a lightweight Extract, transform, load (ETL) framework

Chris Castle introduces Ryan Townsend, CTO of Shift Commerce, and the two begin by discussing the absolutely abysmal performance of web sites in areas with bad latency: airplanes, the rural countryside, or even just within a crowded cafe or conference. Shift Commerce provides a customizable shopping platform for its customers, who are several big brand retailers. For them, every millisecond of delay means lost revenue, as studies have shown that customers are unlikely to complete their purchase if it takes too long.

It's important for Shift Commerce to stay hyper-tuned into its performance. Since it's a multi-tenant application, they have several safeguards in place to ensure that one customer's traffic spike doesn't affect any other retailers. One such strategy is to lean into several of Heroku's features, such as its API, to do some of the heavier lifting. They're perfectly contently to let Heroku manage the operations work while they focus on the application itself.

When it comes to increased traffic, although there are "quick wins" by increasing the number of dynos available, fundamentally what Ryan has found important is to think about the architecture of the site holistically. That means everything from trimming down the amount of JavaScript delivered to efficiently managing the number of database connections made.

• Ryan's talk at #PerfMatters Conference 2019
• Web Performance Optimization stats, listing articles about how popular websites have sped themselves up
• How One Second Could Cost Amazon $1.6 Billion In Sales
• Facebook's '2G' Tuesdays, an initiative that artificially slows down the Internet connection at Facebook to spur empathy towards creating faster response times

More than half of the employees who work on Heroku are remote or distributed employees, meaning Heroku is what you might call remote-first. Host, Chris Castle, brings together five Heroku employees who have had interesting distributed employee experiences. They share some personal stories and discuss setting boundaries, self-awareness, timezones, and some advice for others interested in distributed work.

Raúl Barroso is based in Madrid, Spain. He compares his experience working at Heroku HQ with his current experience as a distributed employee, working from Spain with a team across Europe and the U.S. He also shares his thoughts on the phrase “remote employee” vs “distributed employee” (hint: use “distributed” if you are serious about fostering a culture that values distributed employees as equals to those at HQ).

Alasdair Monk is based in the UK. He published a blog post in September 2016 titled Making remote work: What we’ve learned at Heroku discussing distributed work in three categories: working asynchronously, working together, and staying aligned. He reflects on his experience in the past two years since writing that post and also shares his perspective of UX and Design work as a distributed employee.

Jon McCartie lives way up in northern Idaho by the Canadian border. He and his wife decided to spend 1.5 years with three kids (ages 7, 5, and 2) traveling around the western U.S. in an RV. Oh, and he did this while working on the Customer Support team -- successfully. He shares some fun stories of video meetings with gorgeous views, choosing the right size RV, and using a mobile Wi-Fi hotspot as your family’s primary internet connection. Here is a picture of Jon’s “office”.

Annie Sexton currently lives in Austin, TX. For most of 2017, she was a “digital nomad” fulfilling a life-long dream of hers. She started with a month in Thailand, and then went to Japan, Bali, Morocco, Croatia, Slovenia, back to the U.S., and then back to Thailand, and then Panama. Her Instagram makes it look glamorous, but she says, “it’s easy to romanticize the lifestyle of working on your laptop on the beach drinking coconut water, but it’s just not like that.”

Niklas Richardson is based in the UK. He shares why and how he put his desk in the garden. He poured a foundation and then bought a pre-fab shed that he had insulated and electrified. Here’s what Niklas’s beautiful backyard office--aka garden oasis--looks like, and also the website he mentions in the podcast showcasing other beautiful sheds.

1. Alasdair Monk’s blog post Making remote work: What we’ve learned at Heroku
2. Website with other beautiful sheds Niklas mentioned

Isaac Slavitt is the co-founder of DrivenData, a platform for organizations to solicit help from data scientists to solve real-world problems. DrivenData does this by running "competitions" which asks teams to comb through data sets to solve problems for cash rewards.

One such competition was Zamba. Researchers set up cameras in African forests and asked engineering experts to develop AI software which could classify the types of animals which were captured. This would then help with research and conversation efforts without disturbing the natural ecosystem. Another such competition is DengAI, which seeks ML techniques to try and predict future outbreaks of dengue fever.

Isaac concludes the interview by talking about DrivenData's tech stack. He discusses the uses of both R and Python in the data scientist community. He notes that many computationally intensive task, such as ML classification and testing, are able to be offloaded to a service like Paperspace, while the majority of their platform runs on Heroku.

1. DrivenData
2. Zamba
3. DengAI
4. Paperspace

Nickolas Means likes to tell stories. His conference talks [1] often center around a curious anecdote, but he deftly weaves both technical and organizational relevancy into them. Nickolas talks about how he builds a talk from conception to execution and goes over some fundamentals of good presentation slides. The goal is to provide a narrative without overwhelming the user with too much textual content.

He continues with advice for novices and experts alike, including how to craft a CFP that will increase the likelihood of your talk being accepted. He suggests that new speakers choose a larger conference to speak at, rather than a smaller one, as they have more capacity to provide mentoring. Even if you're not a Ruby or Rails developer, their conferences tend to be very welcoming, and he suggests taking a look at rubyconferences.com to find one that fits.

1. Nickolas’ conference talks
2. Nickolas Means on Confreaks TV
3. How to Talk to Developers by Ben Orenstein
4. What Your Conference Proposal Is Missing by Sarah Mei
5. Better talk proposals in 3 easy steps

Corey Martin leads the discussion with two developers about production incidents they were personally involved in. Their goal is to inform listeners on how they discovered these issues, how they resolved them, and what they learned along the way.

Ifat Ribon is a Senior Developer at LaunchPad Lab, a web and mobile application development agency headquartered in Chicago. For one of their clients, they developed an application to assist with the scheduling of janitorial services. It was built with a fairly simple Ruby on Rails backend, leveraging Sidekiq to process background jobs. As part of its feature set, the app would send text messages to let employees know their schedule for the week; these schedules were assembled by querying the database several times, fetching frequencies and availabilities of workers. Unfortunately, a client noticed a discrepancy between how many notices were being sent out, versus how many jobs they knew they had: of the 400 jobs total, only 150 had notifications. It turned out that all of the available database connections were being exhausted--but that was only half of the issue. Sidekiq was attempting to process far too many jobs at once, and each of these jobs were responsible for connecting to the database, exhausting the available pool. The solution Ifat settled on was to reduce the number of parallel jobs processed while increasing the number of connections to the database. From this experience, she also learned the importance of understanding how all these different systems interconnect.

Christopher Ostrowski is Chief Technology Officer at Dutchie an e-commerce platform for the cannabis industry. One Christmas Eve, while celebrating with his family, Chris began receiving pager notifications warning him about some sluggish API response times. Since it didn't really have any significant end user impact, he ignored it and went back to the festivities. As the night went on, the warnings became significant alerts, and he pulled together a response team with colleagues to figure out what was going on. By all accounts, the website was functioning, but curiously, the rate of orders began to drop off. Through some investigation, they realized what was going on. Customers' order numbers were assigned a random, non-sequential six digit numbers. Dutchie was about to track its one-millionth order, a huge milestone. Before any orders are created, though, the app generates a six digit number, and tries to create one that doesn't already exist. The database was constantly being hit, as less and less six digit numbers were available for use. The solution ended up being rather simple: the order number limit was increased to nine digits. Although they had monitoring in place, the data was set up as an aggregate reporting; even though the "create order" API was slow, all of the others were low, keeping the average within tolerable levels. Christopher's solution to avoid this in the future was to set up more groupings for "essential" API endpoints, to alert the team sooner for latency issues on core business functionality.

• LaunchPad Lab is a web and mobile application development agency
• Dutchie is an e-commerce platform for the cannabis industry

Brendon Murphy, CTO of Kajabi, talks about his company's experience with Dataclips [1]. Instead of requiring developers to connect to their database, everyone in the company is able to generate analytics on-the-fly, and they even democratize the information via a Slackbot. Their marketing team is able to get real-time feedback on their campaigns through Lita.io [2]

The advantage of using Dataclips dovetails with their preference for using Heroku in general. While they could build their own wrapper to communicate with Postgres, or even manage their own infrastructure, they've found that the financial and operational costs are simply not worth it. By offloading this vital work, they free themselves up to focus on building features for their users.

Brendon concludes by talking about Postgres, and why it's the right choice for his team. It can act as a NoSQL document store via its JSONB data type, serve as a key-value store obviating the need for Redis, and comes with strict type assurances reducing the need for checks in the software layer. He also mentions add-ons provided by Heroku, such as PGBouncer [3], along with his feature request for how Heroku can better serve Kajabi's large data needs.

1. Sharing Query Results with Dataclips
2. Lita.io chat bot
3. Heroku buildpack: pgbouncer

In this episode Aaron Patterson joins our own developer advocate Jonan Scheffler to discuss his experiences as an open source developer within GitHub, and explains how he manages to balance his work as a member of the Ruby and Rails core teams with his other responsibilities.

Aaron is the only member of both the Ruby and Rails core teams, and he's been working with Rails since 2005 when his friends attended the No Fluff Just Stuff (NFJS) Pacific Northwest Software Symposium and heard Dave Thomas speak.(1)

In discussing his path to becoming a Ruby developer, Aaron walks through his time working with Perl and Java, covering language regular expression engines (PCRE, Oniguruma, POSIX), the joy he felt in finding Ruby, and how falling in love with Ruby eventually forced him to become a C programmer.

Later in the episode Aaron offers some advice to aspiring open source developers and discusses the future of Ruby, along with some features he would like to see around deep freezing data structures(2) and concurrency/parallelism(3).

If you’d like to learn more about Ruby development and how you can contribute, please visit https://bugs.ruby-lang.org.

1. Dave Thomas "Ruby on Rails" talk abstract from NFJS PNW Software Symposium
2. Vaidehi Joshi explains frozen hashes in Ruby
3. Rob Pike explains concurrency and parallelism at Waza 2012:

Andrew Garcia is the co-founder of Goodshuffle, and as one of the first Grails users on Heroku, he worked closely with Joe Kutner, Heroku's Java Platform Owner over the years. They chat with Chris Castle, a developer advocate at Heroku, about Goodshuffle's experience with building a startup on top of the JVM.

When building an application, it's often tempting to reach for the latest and greatest technologies to build your app. Andrew Garcia argues for something different: by using "boring" technology--that is, languages and frameworks that have been around for years, not months--you can iterate much more quickly on features. He's chosen JDK8 (released in 2014) to run Goodshuffle, a startup founded in 2013 to help event companies manage their business operations.

Goodshuffle uses frameworks like Gradle and Angular because of their stance on convention over configuration, which is another opportunity for being more productive. The more reliable the tools you use are, the more you can focus on your users needs.

• https://devcenter.heroku.com/categories/java-support
• https://devcenter.heroku.com/articles/getting-started-with-gradle-on-heroku
• https://www.heroku.com/java

Rick Newman is a Director of Engineering at Salesforce Heroku. He's joined by Marco Faella, a professor of advanced programming and author of "Seriously Good Software." In Marco's view, there are of course several ways ways to characterize "good" software. Excellent software that goes above and beyond correct functionality includes code that is readable, robust, and performant. Each of these have different importance, depending on context. Robust software, for example, includes addressing issues with scalability, but only if one expects the software to be in such a high availability environment.

It's important to address these requirements from the beginning, when the software architecture is being mapped out. Marco gives the example of developing software for an external client. This client might know all the business logic and how it ought to function, but addressing the code's future evolution and maintenance are just as important, and whose responsibility lands squarely in the hands of the developer.

It can also be worthwhile to make an investment in education, learning about algorithms, data access, and other key concepts in the world of computer science. Such a foundation would allow one to adapt to the changing conditions of programming, whether those are caused by new hardware or modifications in the languages themselves.

• "Seriously Good Software" is Marco's book on the subject of writing strong code -- get a 40% discount with the code podish19

Host Greg Nokes is a distinguished technical architect with Heroku. His guests are Alli McGee, a product manager, and Lewis Buckley, a senior application engineer, from BiggerPockets. BiggerPockets was founded 16 years ago to educate non-professionals about real estate investing.

As a self-funded company, it’s critical for BiggerPockets to create products that customers will pay for. One way they achieve this product/market fit is by building cross-functional teams that are user-focused. All product teams have a project manager, tech lead, and designer that work closely together. This design-led approach allows teams to collaborate with representation from users, technology, and design.

As the PM on one of these teams, Alli lives at the intersection of what can we do for business, what can we do from a technology perspective, and what can we do for the user. She advocates for the customer, bringing knowledge of what customers want, what problems they are facing, and how they have interacted with prototypes in usability studies. Alli also advocates for the business to be sure products make money. Finally, Alli advocates for developers to make sure the project is technically feasible and won’t cause technical debt.

Another way BiggerPockets creates market fit is by creating Minimum Lovable Products—the smallest cheapest thing they can build that people love. With their current product, BP Insights, Alli and Lewis used this strategy to create the first iteration of a product that provides insight into local real estate markets. They then tested the product with users, iterated, and slowly built out a more fully formed offering.

For their tech stack, BiggerPockets is built on a Ruby on Rails monolith. While some in the industry say Ruby on Rails’ time is over, Lewis argues that it has been a great choice, as using a well-known stack has allowed them to worry less about the technology and focus more on building value for users. The BP Insights product was built on this monolith using a massive data set of nearly every property in the US. BiggerPockets imported the data to an Amazon S3 bucket and eventually copied the data to Amazon Redshift for querying.

• BiggerPockets

Robert Blumen is a DevOps engineer with Salesforce, and he's joined in conversation with Andrzej Ludwikowski, a software architect at SoftwareMill, a Scala development shop. Andrzej is introducing listeners to the concept of event sourcing against the more traditional pattern of CRUD, which stands for create-read-update-delete. CRUD systems are everywhere, and are most typically associated with SQL databases. In comparison, event sourcing is a simply a sequential list of every single action which occurred on a system. Whereas in a database, a row may be updated, erasing the previous data in a column, and event source system would have the old data kept indefinitely, and simply record a new action indicating that the data was updated. In a certain sense, you can get the state of your system at any point in time.

Each architectural pattern has its pros and cons. For one, an event source system can make it easier to track down bugs. If a customer notes an issue an production, rather than pouring through logs, developers can simply "rewind" the state of the application back to some earlier event and see if the faulty behavior is still there. On the flip side, since the event stream is immutable, fixes to previous data needs to be made at the end of the stream. You can modify old events or insert new ones into the flow.

CQRS, or Command Query Responsibility Segregation, builds on top of event sourcing. The idea is to separate the part of the application responsible for handling commands and writes from the part responsible for handling queries and reads. This separation is not only on a software level (different repositories and different deployments), but also on the hardware level ( different hosts and different databases). The motivation for this is to be able to scale each part independently. Maybe your app has more writes than reads, and thus requires different computing power. It allows for a separation of concerns, and can make overall operations more efficient, albeit at a complexity cost. Andrzej is quick to note that event sourcing and CQRS divisions are not necessary for every application. Teams, as always, need to understand how the data flows in their application and which architectural pattern is most efficient for the problems they are trying to solve.

• SoftwareMill is a Scala development shop
• Martin Fowler gives a brief run-down on event sourcing
• On the SoftwareMill blog, Andrzej has a blog posts on entry-level event sourcing, keeping your domain clean in Event Sourcing, and the best serialization strategy for Event Sourcing
• CQRS.nu provides more educational resources
• Andrzej Ludwikowski's web site and talk Event Sourcing: What could go wrong?

Luke Kysow is a software engineer at HashiCorp, and he's in conversation with host Robert Blumen. The subject of their discussion is on the idea of a service mesh. As software architecture moved towards microservices, several reusable pieces of code needed to be configured for each application. On a macro scale, load balancers need to be configuring to control where packets are flowing; on a micro level, things like authorization and rate limiting for data access need to be set up for each application. This is where a service mesh came into being. As each microservice began to call out to each other, shared logic was taken out and placed into a separate layer. Now, every inbound and outbound connection--whether between services or from external clients--goes through the same service mesh layer.

Extracting common functionality out like this has several benefits. As containerization enables organizations to become more polyglot, service meshes provide the opportunity to write operational logic once, and reuse it everywhere, no matter the base application's language. Similarly, each application does not need to rely on its own bespoke dependency library for circuit breakers, rate limiting, authorization and so on. The service mesh provides a single place for the logic to be configured and everywhere. Service meshes can also be useful in metrics aggregation. If every packet of communication must traverse the service mesh layer, it becomes the de facto location to set up counters and gauges for actions that you're interested in, rather than having each application send out non-unique data.

Luke notes that while it's important for engineers to understand the value of a service mesh, it's just as important to know when such a layer will work for your application. It depends on how big your organization is, and the challenges you're trying to solve, but it's not an absolutely essential piece for every stack. Even a hybrid approach, where some logic is shared and some is unique to each microservice, can be of some benefit, without necessarily extracting everything out.

• HashiCorp helps automate infrastructure configuration
• Consul, Linkerd, Istio, and Kuma are several open source components for service meshes and control planes
• Mastering Service Mesh: Enhance, secure, and observe cloud-native applications with Istio, Linkerd, and Consul by Anjaki Khatri and Vikram Khatri
• Consul service mesh
• What's a service mesh? And why do I need one? by William Morgan offers additional advice on when to use service meshes
• The Service Mesh: What Every Software Engineer Needs to Know about the World's Most Over-Hyped Technology
• What is a Service Mesh? - a blog from NGINX

Rick Newman interviews Mikolaj Pawlikowski, who recently wrote a book called "Chaos Engineering: Crash test your applications." The theory behind chaos engineering is to "break things on purpose" in your operational flow. You want to deliberately inject failures that might occur in production ahead of time, in order to anticipate them, and thus implement workarounds and corrections. Typically, this practice is often used for large, distributed systems, because of the many points of failure, but it can be useful in any architecture.

One of the obstacles to embracing chaos engineering is finding high level approval from other teammates, or even managers. Even after the feature is a complete and the unit tests are passing, it can be difficult to convince someone that some resiliency work needs to continue, because there's no visible or tangible benefit to preparing for a disaster. Mikolaj suggests that people clearly lay out to other colleagues the ways a system can fail, and the impact it can have on the application or business. Rather than try to fear monger, it can be useful to point to other companies' availability issues as words of caution for their teams to embrace. Mikolaj also says that chaos engineering doesn't need to focus solely on complicated problems like race conditions across distributed systems. Often, there's enough low hanging fruit, such as disk space running out or an API timing out, that can be useful to consider fixing.

The chaos engineering mindset can also extend beyond pure software. If you think about people working across different timezones as a distributed system, you can also optimize for failures in communication before they occur. Everyone works at a different pace, and communication issues can be analogous to a network loss. Rather than fix miscommunications after they occur, establishing shared practices (like writing down every meeting, or setting up playbooks) can go a long way to ensuring that everyone will be able to do their best under changing circumstances.

• Mikolaj's book is called Chaos Engineering: Crash test your applications -- get a 40% discount using the code podish19
• powerfulseal is a testing tool for Kubernetes clusters
• Mikolaj distributes the Chaos Engineering Newsletter
• Conf42 is a conference focusing on high-level computer science
• ChaosConf is the world’s largest Chaos Engineering event
• Awesome Chaos Engineering is a curated list of Chaos Engineering resources

Robert Blumen is a DevOps Engineer at Salesforce, joined by Ev Haus, Head of Technology at ZenHub. Together, they're going over a critique over several methodologies when writing code as part of a large team. First, there's DRY, which stands for Don't Repeat Yourself. It's the idea that one should avoid copy-pasting or duplicating lines of could, in favor of abstracting as much repeated functionality as possible. Then, there's DAMP, or Don't Abstract Methods Prematurely, which is somewhat in opposition to DRY. It advises teams to not create abstractions unless they are absolutely necessary. Last on the list is WET, or Write Everything Twice. This is the idea to embrace duplication whenever possible.

Ev notes that, like many programming absolutes, the success of each strategy depends entirely on the context. DRY, for example, sounds like a really good idea, until it happens everywhere. Suddenly, a chunk of code becomes difficult to reason, as a developer jumps around various method definitions to piece together a flow. DAMP often makes sense as a counterpart to DRY, because if you abstract too early in your codebase, you may find yourself overloading methods or appending arguments to handle one-off cases. DRY is typically best suited for testing environments, where an absolutely reproducible set of explicit steps is often preferable in order to quickly understand what is occurring.

No matter the strategy you use, the core tenant is to solve the problem first. Try to accomplish the goal you need to, whether that's adding a feature or squashing a bug. Don't over optimize until you've finished what you need to, and don't think too far into the future about all the possible edge cases. The rest of the balance comes with experience. Some duplication is bad, but not all of it. Figuring out the absolute perfect solution is unlikely, so you've got to put the code out into the real world to find out what works. After that, bake some flexibility into your processes to adjust hot code paths or refactor them when needed!

• ZenHub is an agile project management tool for GitHub
• Wikipedia's definition of DRY
• "Using DRY, WET & DAMP code" is Ev's article on different coding methodologies
• Codewars is a website with programming puzzles and challenges
• The Pragmatic Programmer by Dave Thomas is a popular book highlighting some of these concepts
• DRY code, DAMP DSLs by Jay Fields and DRY vs DAMP in Unit Tests by Vladimir Khorikov are more write-ups on the subject

In this episode, Ian, Laura, and Wesley talk about the importance of communication skills, specifically writing, for people in technical roles. Ian calls writing the single most important meta skill you can have. And the good news is that you can get better at it, with deliberate practice!

Ian and Wesley both come from engineering backgrounds but have moved into more writing-intensive roles as their careers have progressed. Laura is an instructional designer with experience across many industries. They all agree that writing plays several different important roles for people, whether it's to educate, persuade, or even mark a decision.

So if writing is such a critical part of what you're doing from an engineering perspective, how can you get better at it? Laura offers a handful of practices, including providing context, supplying the appropriate level of detail for the audience, using stories or analogies, incorporating repetition, and finding a good editor (even if it's yourself coming back to a piece with fresh eyes).

The guests close the episode by sharing some of their favorite resources for improving communication skills, which are listed below.

• “Programming as Theory Building" by Peter Naur
• Example of an RFC process
• Illusion of Explanatory Depth
• The Sense of Style by Steven Pinker
• Write and Organize for Deeper Learning by Patti Shank
• Tech Writing course from Google

Host Joe Kutner is an architect working at Salesforce, and his guest is Cornelia Davis, the CTO of Weaveworks, a platform for infrastructures. Cornelia argues that most companies building complex web-based applications are doing so without fully understanding the unique operational challenges of that environment. Even several well-known patterns, such as adding circuit breakers or retry patterns, are not standardized across the industry, and certainly not across languages, let alone in frameworks and other easily consumable dependencies. In many cases, there are over reliances on infrastructure availability that only become obvious once a problem occurs. Cornelia gives the example of a massive AWS outage that occurred several years ago. For many companies lacking redundancy contingencies, their applications were offline for hours, through no fault of their own.

Another potential conflict between operational patterns and software design emerges around container-based lifecycles. If you have a new application configuration that you want to deploy, Kubernetes, which is designed to be stateless, encourages you to simply get rid of a pod and start up a new one. But it's entirely possible that there's some running code that doesn't know how to pick up these new changes, or even a service which can't recover from unexpected downtime. Considering these issues is the difference between running the cloud and being truly cloud native.

To the industry's credit, Cornelia does see more platforms and frameworks adopting these patterns, so that teams don't need to write their own bespoke solution. However, it's still necessary for software developers and operational engineers to know the features of these platforms and to enable the ones which make the most sense for their application. There is no "one size fits all" solution. As the paradigms mature, so too does one's knowledge of the interconnected pieces need to grow, to prevent unnecessary errors.

• The twelve-factor app
• Cornelia wrote a book called Cloud Native Patterns (get a 40% discount using the code podish19)

Hailey Walls is a Customer Solutions Architect with Heroku, and she's engaged in a conversation with Paul Orland, the founder of Tachyus and author of Math for Programmers. Paul took graduate level math classes, and even ended up with a Master's degree in Physics, but even he admits that he comes down with his own kind of math anxiety. Now, he works as a programmer, building predictive models, but he encounters many engineers who don't have a basic understanding of fundamental math concepts, like calculus or linear algebra. Seeking to rectify this, he wrote a book called Math for Programmers, which methodically explains mathematical concepts using real-world examples. He hopes to be able to teach math to many more people.

Paul emphasizes that, although thinking of mathematics can be intimidating, it's not different than working on any other skill. If you decide to go weight lifting, you start with a 10 pound weight, then a 15 pound one, and on and on. Similarly, with math, if you train on problems that are simpler, future problems will build upon the techniques you've honed. The appeal for gaining math skills is almost analogous to that of programming: there is always a right and final answer. Just as a compiler determines how a program works and whether a syntax is valid, taking in input and producing output, so too is math deterministic. Fundamentally, better mental acuity with math can help teach you how to consider the behaviors of complicated systems.

For people interested in studying math more closely, Paul advises students to not be discouraged by problems which appear hard. It can be best to pick a problem that you are naturally interested in, which will lead to a general willingness to try and solve it. Similarly, he'll also take a math concept and turn it into a program, which has helped him reason about flow and patterns much more clearly in the past.

• Tachyus helps energy producers optimize their production
• Math for Programmers is the book Paul wrote -- listen for a 40% off code

Julián Duque is a Lead Developer Advocate at Salesforce and Heroku, and he's continuing a previous discussion with some members of Respeecher. Respeecher has created AI software which works within the speech-to-speech domain: it takes one voice and makes it sound exactly like another. Dmytro Bielievtsov, its CTO and co-founder, explains the practical uses of the software, such as re=recording the lines of an actor who is unavailable, or bringing historical figures to life in a museum.

In terms of sophistication, there are quite a few speech ML models already available on the Internet. The best source of audio to duplicate the speech patterns of a famous person is to grab an audiobook and pass it through one of these pre-existing models. But these models produce outputs which are poor in quality. That's one reason that speech-to-speech is hard to fake. The variation in our mouths and speech patterns, not to mention the emotive qualities, make the process of creating duplicate voices extremely difficult to pull off. One way Respeecher data can't be faked is by the fact that they position themselves as a B2B business, dealing with studios and other large estates which have access to immense amounts of hard-to-acquire sound data. The likelihood of another entity abusing a well-known voice is close to none. Another feature is that the audio is watermarked. Certain "artifacts" are embedded into the audio, which are imperceptible to humans, but easily identifiable by a computer program.

There's a consortium of several companies working on synthesized media who strategize in Slack on various ways to keep the tech from being misused. As well, Dmytro believes that there needs to more investment in education, to let people know that such technology exists, and to therefore be a bit suspicious with media they encounter online.

• Respeecher is a speech-to-speech voice cloning software
• Google's DeepMind and Tacotron are two popular AI/ML projects
• Module empowers the future of identity, online safety, and communication through voice
• Previous episode: 98. The Ethical Side of Deep Fakes

Julián Duque is a Lead Developer Advocate at Salesforce and Heroku. He's joined by Alex Serdiuk, the CEO of Respeecher. Respeecher has created AI software which works within the speech-to-speech domain: it takes one voice and makes it sound exactly like another. Alex rejects the premise that all deep fakes--that is, pictures and videos generated by AI--are inherently evil. He considers tools like CGI and Photoshop to fall within the realm of synthesized media, which helps artists create content. He positions Respeecher within that same mileu.

Respeecher has been working with Hollywood studios for some time. It removes pressure from actors who are unable to rerecord lines. It's also been used in situations where actors need to sound much younger, a visual-audio process called de-aging. In the future, applications of speech-to-speech work could also be used in museums, to provide a new dimension of history for audiences.

Of course, Alex recognizes that the main issue with deep fakes is not their existence, but their inability to be detected. To solve this problem, Respeecher watermarks its audio, to generate inaudible metadata which can nonetheless be analyzed to show whether a particular recording was faked. He also believes that more people need to be educated that synthesized media exists. Something one sees or hears might not be real, because technology is getting more and more advanced. We should all be mindful about the content we consume.

• Respeecher is a speech-to-speech voice cloning software
• Samsung Next provides an overview of the synthetic media landscape