53 episodes

A podcast from the team at Heroku, exploring code, technology, tools, tips, and the life of the developer.

Code[ish] Heroku

    • Technology

A podcast from the team at Heroku, exploring code, technology, tools, tips, and the life of the developer.

    53. Scaling Telecommunications Data with a Service Mesh

    53. Scaling Telecommunications Data with a Service Mesh

    Julián Duque is a senior developer advocate at the Heroku, and he's interviewing Luca Maraschi, a chief architect at TELUS Digital. TELUS is a large communications company in Canada, which processes a massive amount of data produced by millions of customers all across the country. One of their challenges, for example, was to design a single datastore which provided a consistent experience across online services and offline ones, such as call centers or brick-and-mortar stores. In the end, Luca describes how they were able to break apart the existing monolith in favor many different microservices.


    Luca notes that the data sources are not uniform; they can be coming from Excel files, Cassandra clusters, PostgresQL, MongoDB, and so on. He talks about the technologies they used to accomplish this feat, settling on GraphQL as a main component to the stack, as their services already act as edges in a graph. TELUS also makes use of Kuma and Kong, two relatively new projects. Luca finds new technologies to be not something to necessarily be afraid of, but rather, because they are often open source software, to make use of them as opportunities for driving the project's decision.


    The conversation wraps up with a discussion on the future of distributed systems. In the end, Luca believes that more responsibility for data manipulation should be placed on the client, rather the server identifying what it believes to be the "perfect" data set. This allows for greater flexibility, and opportunities for changing backend strategies as needs evolve, without user-facing disruption.


    Links from this episode


    Luca's talk at NodeConfEU 2019 titled "Scaling data from the lake to the mesh via OSS"
    Kuma (which ties microservices together) and Kong (which provides an API layer for them) are two technologies which Luca loves to use for TELUS' needs
    GraphQL helps TELUS with its goal for providing data as nodes in a graph

    52. Building and Scaling a Heroku Add-on

    52. Building and Scaling a Heroku Add-on

    Corey Martin is a Customer Solutions Architect at Heroku. He’s interviewing Adam McCrea, a software developer and the creator of Rails Autoscale, a Heroku add-on that allows developers to auto-scale their Ruby On Rails apps. They begin their conversation by talking about auto-scaling and how McCrea’s experience as a developer inspired him to create an application that would automatically handle the scaling of web and worker dynos. Having seen how valuable the initial app was for the company he worked for, McCrea set about turning his creation into a sellable product that could be used by other developers.


    If you’re working with more than one Heroku dyno, there’s a lot of guesswork involved in scaling resources. Rails Autoscale takes care of this problem, by automatically determining how many dynos an app needs, scaling them up when required and down when there is excess capacity, all in real-time. By using an app to take care of the process, McCrea knows that a vitally important process is taken care of regardless of fluctuations through the day or week, saving users money and providing peace of mind. The app also measures requests queuing time, as opposed to total response time, which provides a more accurate indication of real-time capacity requirements.


    Martin and McCrea round out their conversation by talking about McCrea’s experiences turning his application into a sellable product and how the Heroku Elements Marketplace has helped him get Rails Autoscaling into the hands of over 200 paying customers. McCrea says that as with everything there are trade-offs, but not having to worry about marketing Rails Autoscaling or handle billing have made the experience easily worthwhile for him. Finally, McCrea explains his attempts to further spread word about Rails Autoscaling, including engaging with the bootstrapper community on Twitter and attending conferences.


    Links from this episode


    Rails Autoscale, McCrea's add-on for Heroku
    How autoscaling works on Heroku
    Heroku's guide on how to build an add-on

    51. Best Practices in Error Handling

    51. Best Practices in Error Handling

    Julián Duque is a senior developer advocate here at Heroku. He attended the NodeConf EU conference in Ireland, and met up with Ruben Bridgewater, a software architect and core Node.js contributor. Julián and Ruben go over the history of Node.js (now in its tenth year), as well as how Ruben became involved with the Node.js project.


    Ruben's focus on Node is providing its users with good developer experiences. As a consultant, he has seen how organizations frequently run into the same issues over and over. JavaScript is partly to blame here, as there are three different patterns for executing asycnhronous logic: callbacks, promises, and the new async/await syntactic sugar. He'd like to help people avoid problems by strengthening their understanding around proper error handling.


    Ruben has several suggestions. First, he advises everyone to switch to using the async/await pattern of asynchronous code execution, which was introduced in Node 12. This allows errors to provide an async stack trace, which is more helpful in diagnosing errors than the obfuscated errors that come from promises. Second, he advises teams not to simply try-catch and rethrow errors. It's far more beneficial to abstract errors into individual classes (NotFoundError, NotPermittedError, etc), because it allows the programmer to identify immediately from the error name what went wrong.


    From this abstraction, Julián and Ruben discuss its role in logging strategies. By having your errors defined as distinct classes, you can place all sorts of "generic" information in them as properties, such as the status code. With no additional programming labor, this data can be exposed in the logs for additional analysis.


    Mostly, the best thing you can do is to think about errors while writing the code. For example, add tests for all the edge cases you may encounter. By investing more time upfront in the development process, you will save yourself from worries later on when the code hits production.


    Links from this episode


    Error handling: doing it right! is a talk Ruben gave at the Amsterdam JSNation Conference 2019
    Let it crash is Julián's talk on error handling from NodeConf EU 2019

    50. High Energy, Low Power: A Bluetooth Christmas Story

    50. High Energy, Low Power: A Bluetooth Christmas Story

    Armed with a Puck.js button and a bluetooth-powered power outlet, Chris Castle decided to make the Christmas lights magic. He dug into the code, Puck.js documentation, and seemingly oft-ignored specifications, eventually reverse engineering the whole thing. He built a site around it, showing how it worked, while learning more about design, SVG animation, and the occasional perils of the tools we choose to use.


    All so his nephew could press a button and see some magic happen.


    Joined by Heroku UX / UI lead Charlie Gleason, Chris delves into the project; digging into his rationale and process, the technical challenges he faced, and how kids are really great at user testing. Most of all, together they try and find a little of joy that can only be captured by kids at Christmas.





    Links from this episode


    Puck.js
    Bluetooth power outlet
    xkcd comic on standards
    Wireshark
    Slides for Keg dot io
    Sandpit.js and its terrible documentation
    Lynn Fisher
    Refactoring UI
    https://castle.christmas

    49. Building Effective Distributed Teams

    49. Building Effective Distributed Teams

    Anthony Mazzarella, a senior engineering manager at Heroku, is joined by Juan Pablo Buriticá the VP of engineering at Splice. Juan Pablo has spent the last decade building and running engineering teams across different industries. He believes in helping engineers find their role in fulfilling a business' higher level initiatives.


    Juan Pablo encourages teams to focus on planning just a little bit ahead of where you envision your business will be, in order to avoid much greater pains. This includes establishing communication channels that are agreed upon, even if your team is rather small. This way, there will be less ambiguity about where decisions are discussed, should your team grow in the future.


    In order to validate your successes, you need metrics to keep track of how your team is doing. Juan Pablo recommends four: how long it takes for a feature, from its first commit, to release to production; how long it takes to recover from an outage; how often you introduce new errors into production; and how often you're deploying code to production. By measuring these ideas, iterating on them, and introducing new metrics, the entire businesses—not just the engineers—can understand their role in the health of the company.


    Finally, the utmost priority for any business should be to satisfy their customers. It is worth paying someone else to solve any problem which deviates from this goal. That includes relying on Heroku for infrastructure and LaunchDarkly to handle feature flags. Tackling interesting technical problems is ultimately going to cost a company money anyway, as engineering time will be diverted away from helping a customer.

    48. From NodeConf EU 2019

    48. From NodeConf EU 2019

    Alex Korzhikov is an engineer at ING Bank. He's at NodeConf to lead a workshop on using oclif, as well as working with classes and OOP in TypeScript. oclif is a command-line framework developed in TypeScript by Heroku, and ING is using several different tools built on oclif to communicate with each other. He talks with Julián about why they chose oclif, and how TypeScript has enabled them to build better systems faster.


    Tierney Cyren works as a developer advocate for Microsoft Azure. He's also the Chairperson of the Community Committee for Node.js. He's passionate about helping open source communities become more inclusive by helping them work on internationalization, documentation, and various governance needs. His talk is centered on four factors he's found are fundamental to growing a successful and healthy open source project.


    Chris Dickinson is building Entropic, a new package manager for Node.js. As opposed to npm, Entropic is comprised of federated hubs, ensuring that no single company or entity is responsible for all of the community's third-party packages. Previously, he worked on NPM itself, and knows first-hand how much a a distributed system is needed.


    Links from this episode


    oclif is an open source framework for building a command line interface (CLI) in Node.js
    Typescript: The Complete Developer's Guide is a recommended resource to master Typescript and build complex projects
    openopensource.org provides some guidance on building an empowered community
    Entropic is a distributed package manager for Node.js

Customer Reviews

jThurston ,

Sound quality

Get a volume level balancer. Talk about more than ruby

Top Podcasts In Technology

Listeners Also Subscribed To