Code[ish]

Code[ish]

By Heroku from SalesforceBusinessTechnologyManagement
Download on the App Store

Code[ish] episodes

  • The Difference Engine

    Join Charlie Gleason, a designer and developer at Heroku, as he interviews two people representing The Difference Engine: Kimberly Lowe-Williams, its founder and Executive Director, and Rachel Marro, a recent graduate. The Difference Engine is a Chicago-based nonprofit with the goal of empowering professionals from nontraditional backgrounds to launch their careers in tech. They do this through an apprenticeship web development program, mock technical interviews, and ways to highlight their relevant experience.

    Kimberley stresses that The Difference Engine expects applicants to have some familiarity with coding. The programs are designed to help adults with prior work experience navigate the often insular and nepotistic tech industry. One of her biggest tips is to encourage individuals to attend meet-ups, conferences, and other information sessions, to connect with others from similar backgrounds. Rachel concurs; it wasn't until she joined a few Slack groups that she realized her predicament was not unique, and it gave her more confidence in pursuing her career change into tech.

    Although just over three years old, The Difference Engine has already placed several apprentices into tech careers. One of Kimberley's goals for 2020 is to involve more corporate sponsorship, in two forms. First, The Difference Engine can guide tech companies in reevaluating their interview practices to eliminate unconscious biases. Second, employees at companies can volunteer their time to serve as mentors for apprentices.

    Links from this episode
    • The Difference Engine is a non-profit transforming the lives of people through careers in tech
    • Women in Technology and Chicago Tech Diversity Initiative are two communities which Rachel also participates in
    • Get in touch with The Difference Engine to get involved
    38 min
  • From Engineer to Entrepreneur

    Erin Allard is a Platform Support Engineer at Heroku, and she's interviewing Ben Orenstein, one of the co-founders of Tuple. Screenshare was a popular pair programming app that was discontinued after being acquired by Slack. Finding no other alternative for this functionality, Ben and his friends built Tuple.

    Ben spent much of the early months of Tuple investigating pricing strategies, because he understood that the business wouldn't exist unless he could charge a reasonable price customers would be willing to pay. This process also reduced the risk of their efforts, knowing that they could burn through months of savings with the likely goal of being able to turn a profit. To that end, Tuple became completely bootstrapped and self-sufficient.

    Ben continues by pointing out that having a group of advisors has been instrumental to Tuple's success. These are friends and former colleagues who provide direct feedback, which allows Tuple to shape their own product roadmap based on real needs. He mentions the importance of being able to focus on the product and not the infrastructure as the main reason for choosing Heroku as the backend platform.

    Links from this episode
    • Tuple is the app featured on this episode
    • The Art of Product is Ben's podcast detailing his experiences running a business
    33 min
  • All About the Cloud

    Giorgio Regni, the co-founder and CTO of Scality, and Robert Blumen, a DevOps engineer at Salesforce, cover the basics of on prem, public cloud, private cloud and multi-cloud. The discussion covers business drivers, use cases, division of workloads, architecture, and networking concerns present in each of these categories.

    For enterprises, there is no "one cloud fits all" approach to building applications. The public cloud is more than an experimental platform for non-critical applications and unproven products - nor is the path of all computing migrating to its final home in the public cloud inevitable. Instead enterprises are arriving at the right mix of on premises private clouds which are increasingly containers providing APIs, and one or more public clouds. The motivations for selecting a cloud type can be vertical best-of-breed based on the offerings of a specific cloud provider, distributing peak capacity at lower cost, off site disaster recovery, or choosing a mix of vendors to avoid lock in.

    This mixed model works conceptually, but it also introduces issues around security, privacy, and the ability of enterprises to meet service level agreements. Increasingly, companies are grappling with integrating authentication solutions for these disparate locations. As a cloud storage provider, Giorgio provides his insights on how companies are building out these infrastructures and the tools they use to solve their problems.

    Links from this episode
    • Scality is a company which develops storage software
    • https://www.docker.com/
    • https://kubernetes.io/
    • https://aws.amazon.com/
    • https://cloud.google.com/gcp/
    • https://azure.microsoft.com/
    • what is hybrid cloud eBook
    • what is hybrid cloud according to MS Azure
    • what is hybrid cloud according to Red Hat
    24 min
  • Capturing and Analyzing Energy Usage Metrics

    David Morganthaler, an Account Manager at Heroku, interviews two members from Kevala: Emmanuel Levijarvi, its engineering lead, and Teddy Ward, a software engineer. Kevala is building a one-to-one map of a community's energy grid, to identify how power is produced and model how it's consumed. They pull data from public sources and aggregate data to reliably predict when energy will be needed, and what an optimal price to pay for that energy generation.

    Balancing the exact amount of energy that people want alongside the amount that is being produced is an incredibly hard problem for the utility sector. If you don't produce enough, electronics won't work and vehicles can't be charged; if you produce too much, it's either wasted or has the potential to fry wiring and infrastructure. Kevala tries to monitor these figures by using machine learning on models they create, as well as tracking usage throughout the day.

    The Kevala engineers spend some time also talking about the dependencies used to achieve their goals. These range from hardware, like the IoT devices which consumers install or the access points they tap into to collect accurate data, as well as the software services which make up their app, like Auth0 and Postgres. Because of the unreliable nature of energy consumption, Heroku's autoscaling platform allows Kevala itself to spin up resources in a cost-effective manner.

    Links from this episode
    • Kevala is a software company focused on analytics for the energy industry
    42 min
  • Discussing Docker Containers and Kubernetes with a Docker Captain

    Mike Mondragon interviews Bret Fisher, who works as a freelance DevOps/sysadmin consultant, and who also has the designation of being a Docker Captain. Docker Captain is a distinction that Docker awards select members of the community that are Docker experts and are passionate about sharing their Docker knowledge with others. To that end, Bret walks us through the history of how he became involved in Docker, and indeed, the history of Docker itself: the problems it tried to solve, and the way the codebase evolved to provide those solutions.

    Much of the conversation centers around the confusing terminology and processes present in the Docker ecosystem: when to use Docker Compose, the differences between running Docker locally and in production, and when to consider adopting Kubernetes. There are also various container runtimes which developers can make use of, and Bret touches on the characteristics of each as well.

    Bret looks towards the future of Docker, the company, as they recently sold off a portion of their enterprise-focused business. Docker is returning to its original intent to provide developers with better tooling to deploy and isolate their applications. He urges caution to teams ready to move wholeheartedly to Docker and instead focus on solutions that match their problems, not those of immense enterprise corporations.

    Links from this episode
    • An explanation of a Docker Captain's role
    • DevOps in Docker Talk is Bret's podcast
    • Kata Containers, containerd, and cri-o are just some of the container runtimes out there
    • Kelsey Hightower's Kubernetes: the hard way is a tutorial that walks you through setting up Kubernetes
    47 min
  • Updating Legacy Code

    Corey Martin is a Customer Solutions Architect at Heroku. On this episode of Code[ish], he's interviewing Joe Leo, the founder and CEO of Def Method, a service-oriented software consultancy based out of New York City. The conversation begins with Leo providing his personal definition of legacy software as being any software that is not currently in the process of being written. He emphasizes that this does not mean something is immediately obsolete once it's been written, but that at that point an individual or company must shift its energy and focus to maintenance and improvement.

    From there Martin and Leo move on to discussing how customers Def Method helps customers find solutions to their software issues. Whether a company is dealing with brownfield, greenfield or minefield software, Def Method attempts to help them determine how to deal with the problems they are faced with and how they can keep their system healthy as they continue to evolve. As Leo points out, no piece of software is future-proof or bug-free, so honesty and openness are required if a company wants to succeed. It's Def Method's goal to help its customers get to this point.

    The pair round out the conversation by talking about Leo's recent book, The Well-Grounded Rubyist. The text, which was originally penned by Leo's close friend David A. Black, is considered one of the most influential pieces of writing on Ruby and Leo was brought in to help co-author the third edition, which is published by Manning Publications. Leo views The Well-Grounded Rubyist as a text book with a philosophical bent and says that his primary focus was capturing the how the language has developed throughout its history and the very real tectonic shifts it has undergone during that time.

    Links from this episode
    • Def Method is Joe Leo's consultancy that focuses on rescuing legacy software
    • Def Method has also been featured as a Heroku Customer Success case study
    • Code Climate is a code analyzer that runs as part of CI to ensure the quality of your code
    • The Well-Grounded Rubyist is the Joe's book, available from Manning
    33 min
  • When Side Projects Become Real

    Mike Mondragon is the Lead Member of Technical Staff at Heroku. He's interviewing Ben Curtis, one of the co-founders of Honeybadger.io, which is an exception monitoring service for web developers. Curtis reminisces about how he came to Ruby through Rails during the early 2000s. Having already spent a few years as a web developer, he says he quickly fell in love with Ruby because everything he had learned, from templating and database abstraction layers, were built into its framework.

    The conversation then moves on to the founding of Honeybadger. Its genesis came when Curtis and one of the company's other co-founders, Starre Horne, were working together at a startup building a Rails app and were using Airbrake to track exceptions. Frustrated by the lack of detail they were getting in their descriptions, they used Airbrake's published code to create a new tool that would provide developers with a more thorough breakdown of what was happening. Initially, there was some pushback creating the project, but Curtis, a longtime proponent of open source, believes that Honeybadger's development was in keeping with the ethos of open source.

    From there, the conversation moves on to a general discussion about the benefits of side projects both as a creative outlet and as a means to solve problems. Curtis said his approach to side projects has evolved over the years, and while he still does them for fun each project needs to be something he is willing to put his time and effort into regardless of whether other people will care. From there the interview moves on to discussion about burnout and the importance of a positive work-life balance, something which the entire Honeybadger.io team is very mindful of. Curtis concludes by saying that in the end the most important aspect of side projects is creating something that is your own.

    Links from this episode
    • Curtis and his co-founders built Honeybadger.io
    • FounderQuest is a podcast run by Curtis and his co-founders
    • PackageBot is another of Ben's projects, which sends information about APT packages straight to Slack
    31 min
  • Building a Business by Teaching Developers

    Mike Mondragon is interviewing Geoffrey Grosenbach, the Director of Product Education at Hashicorp. Before that, he launched PeepCode in 2006, a platform for developers to share and sell screencasts of programing tutorials. Over the years, he was able to grow the company until its acquisition by Pluralsight; he describes what the experience was like.

    The conversation turns towards how to best learn new programming skills, after you've plateaued to being a "good" developer. Geoffrey suggests two things. First, writing about something you're working on is a good way to experience how you might express concepts to someone learning about them for the first time. He also recommends that developers step out of their comfort zone. For example, if you know how to git push to Heroku, perhaps you could try writing your own buildpack next.

    Towards the end of the episode, Mike and Geoffrey discuss the effects of attention, particularly around social media. The more you produce helpful content—whether that's an article, a video, or an open source project—you're bound to attract others. Finding that balance of joy and sanity can be a difficult one.

    25 min
  • 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
    26 min
  • 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
    32 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.