
Sign up to save your podcasts
Or

![Code[ish]](https://podcast-api-images.s3.amazonaws.com/corona/show/685572/logo_300x300.png)
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 asynchronous 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 episodeArmed 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 episodeAnthony 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.
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 episodeRobert Blumen is a Dev Ops engineer at Salesforce. He's interviewing Alexey Syomichev, a software engineering principle architect at Salesforce, with over 25 years of experience. Their conversation begins with what constitutes an event (an immutable record encoding something that happened to an app). They then move on to describe consumers of those events, whether they're internal to an app or external to other services and business departments. Finally, they discuss ways in which you can store that event, either in a database or a running event log.
Databases and event logs each have their strengths and weaknesses, which Alexey enumerates. Event logs, for example, are easier to write to; but databases are easier to query for information. In general, Alexey believes that it can be important to organize your larger systems around an event log.
The conversation concludes with a discussion on how to use an event log in practical ways. First, you'll need to decide the schema to use when representing an event. State transitions are another reality to consider. If multiple events representing the same action come in, you need to make sure that the event log is atomic. Finally, there's a question of precisely how many events to retain, how far back you store your application's state.
Links from this episodeJohnny Boursiquot is an SRE at Heroku, and joining him on this episode are Ed Muller (one-time Go language owner at Heroku), and Rishabh Wason, an engineer fresh out of university. Ed initiates the conversation by talking about how Heroku rolls out buildpack updates to users that are concurrent with Go releases.
Heroku is a polyglot organization, and Go is being used as one of its four primary languages. It's finding its way into backends, microservices, and services which communicate with each other. Since many engineers at Heroku have experience in multiple languages, it's become essential for Go experts to teach others how to write idiomatic Go code. Part of this is done through the Go Design Guide, a living document that details the pros and cons of various ways to write Go logic. Ed in particular finds that pairing with other engineers on their issues has helped him understand a beginner's mindset, which he can then use to update internal documentation.
Rishab also shares his strategies for how he learned Go, coming at it with prior experience in Java and Python. He provides a list of online resources which helped him. He also talks about some of the discrepancies he found in different code bases--for example, in their different dependency management styles. For him, the way in which he grew his understanding of the language was to ask targeted questions to reviewers in his pull request.
Links from this episodeCasey Faist, Heroku's Python Buildpack Maintainer, sits down with Justin Kestler, the co-founder of LitCharts, and Devyn Gasperini, one of its full stack web developers. They discuss the genesis of the project, and how it's really an evolution of Web 2.0 sites such as SparkNotes. LitCharts differentiates itself by providing modern English translations of well-known literary works, as well as color highlighting and annotating content word by word. Through a clever use of hyperlinks, they can also cite intrareferential and interreferential materials. This has the end result of producing thorough analyses between 8,000 and 10,000 words.
Much of the work developing LitCharts has centered around user experience and user feedback. The LitCharts team strives to not only provide a pleasing experience for the end user, but also a feature-rich interface for the writers providing annotations. Their end goal is to represent works of literature in unique ways, as well as literature that nobody else has covered.
Links from this episodeOwen Ou, an engineer at Heroku, is joined by Tanmai Gopal, the CEO of Hasura. They start their conversation by describing what GraphQL is, and what problems it set out to solve. GraphQL focuses on making data fetching easier, whether that client is a web browser or an API call. GraphQL provides one endpoint that can query all your application's domain logic. If your primary consumer of data is a front end application, then GraphQL is likely a good choice to use.
The conversation continues with help on how to get started using GraphQL, and situations where GraphQL might not be useful. For example, if your data is not in JSON, or is in a binary format, it might not be a good fit. As well, depending on whether your application is a monolith or a set of microservices, how GraphQL incorporated varies, and can be difficult. Tanmai continues with his team's experience of incorporating GraphQL, the challenges they faced, and the improvements they noticed.
Tanmai and Owen conclude by looking to the future of GraphQL. The language is very solid, but the spec is continuing to evolve with community feedback.
Links from this episodeAnupam Dagar is now a final-year undergraduate Computer Science student at Indian Institute of Information Technology, in Allahabad. He tells Joe Kutner, a software architect at Heroku, about how he first came across the GitHub Student Pack as a freshman. He needed a domain name, and one of his senior classmates advised him to take a look at the pack, which provides free tools for any student over the age of 13.
With the Student Developer Pack, Anupam was able to build a project called HoxNox, a portfolio generator. He noticed that a lot of his friends were spending a lot of time perfecting their resumes on paper, so he decided to create a website that took the process digital. With an urge to keep honing his skills, HoxNox was his most ambitious project to date. With companies providing hosting and emailing services through the pack, he was able to build something that became quite successful.
Anupam strongly encourages students to not get bogged down between deciding which language or framework to make use of when starting their projects. The fundamental principles of software engineering are applicable to all of them, including catching errors and writing maintainable code. He found it useful to just start with one new part of the tech stack to work on, before mastering it and moving on to something newer. It's also important to consider yourself as more than just your code. Talking to people and building a healthy community is just as important, perhaps moreso.
Links from this episodeParker Phinney runs Interview Cake, a company with an online curriculum that prepares candidates for programming interviews. He's interviewed by Julián Duque, a developer advocate at Heroku. Interview Cake offers advice on communicating your intent, tips for navigating various decisions, and computer science concepts such as data structures and algorithm efficiency.
Parker explains that he was inspired to create this site after helping a friend with her programming interview over the course of a weekend. He realized that while most coding bootcamps do teach eager students how to program, they don't do as well teaching soft skills, as well as more academic programming concepts. He built up his curriculum by partnering with bootcamps in San Francisco, teaching students directly, and assessing which parts of his lesson plan worked.
Links from this episodeFrom the publisher's feed