Code[ish]

Code[ish]

By Heroku from SalesforceBusinessTechnologyManagement
Download on the App Store

Code[ish] episodes

  • Building APIs that Integrators Want To Use

    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.

    36 min
  • Becoming a Junior Developer

    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.

    Links from this episode

    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
    36 min
  • Securing the Web with Let's Encrypt

    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.

    Links from this episode
    • 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.
    23 min
  • The Making of Trailhead

    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.

    Links from this episode
    • Trailhead is an e-learning platform focused on Salesforce and other web technologies
    • New Relic is a monitoring tool for an application's performance
    44 min
  • Integrating Terraform with Heroku

    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.

    Links from this episode
    • 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
    44 min
  • Accessibility in Web Standards

    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.

    Links from this episode
    • 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.
    40 min
  • Pursuing a Career in Tech

    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.

    Links from this episode
    • 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
    20 min
  • Talking About Talks

    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.

    Links from this episode
    • 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
    32 min
  • oclif: An Open Source CLI Framework

    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.

    Links from this episode
    • oclif.io, the main landing page for learning more about oclif
    • Microsoft's Powershell, which Jeff believes is the most incredibly advanced CLI platform
    36 min
  • Mindfulness at Work

    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.

    Links from this episode
    • Search Inside Yourself
    • DIY Meditation Guide
    • Social Meditation
    30 min

About Code[ish]

From the publisher's feed

Code[ish] takes a closer look at the stories, tools, and people that make Heroku and our global developer community so exciting.