OwlTail

Cover image of Devchat.tv Episode Roundup
Business
Education
Careers
How To

Devchat.tv Episode Roundup

Updated 3 days ago

Business
Education
Careers
How To
Read more

Contains all versions of all episodes from Devchat.tv

Read more

Contains all versions of all episodes from Devchat.tv

Best weekly hand curated episodes for learning

Cover image of Devchat.tv Episode Roundup

Devchat.tv Episode Roundup

Latest release on Jan 19, 2021

Best weekly hand curated episodes for learning

The Best Episodes Ranked Using User Listens

Updated by OwlTail 3 days ago

Rank #1: RR 440: Swagger and OpenAPI with Josh Ponelat

Podcast cover
Read more

Today the panel discusses the difference between Swagger and Open API with Josh Ponelat. Josh details the difference between the two. Swagger is a set of protocols around describing restful APIs. Swagger was taken over by a company called SmartBear, who donated the donated the specification to the Open Linux Foundation, and that became the Open API. Swagger is the tooling surrounding these specifications. Open API is a standardized way to describe a restful API in a YAML file. Once you’ve got a YAML file to describe your API, you can use tooling like Swagger to leverage that and take it to the next level. Using the Open API process is useful for situations where you already have an API in place, but want to codify and document it so that it’s controlled. Then going forward, you won’t introduce contradictions and it remains consistent because it’s documented in a YAML file. The process leaves room for enhancement in the future as well.

Josh talks about some of the benefits of standardizing your API and some of the use cases besides tooling. A standardized API can help show developers how to use your API, SDKs, and service stubs by knowing your API is consistent in style. This makes it easier to find breaking changes and more. Josh talks more about Swagger, a finite set of tooling around Open API, most of which are open source. He talks about other tools that test APIs and do linting on YAML files. Some of the companies that use Open API include Google, Amazon, and Microsoft. Josh talks about how Amazon implements Open API.

Josh talks about the book he’s writing, Designing APIs with Swagger and Open API. The book goes over describing APIs today, how to design APIs without writing code first, and how to get the most out of the system. The show concludes with Josh talking about the power of consistency and writing things down on paper. He discusses where implications that the standardization of APIs has on the text industry.

Panelists

  • Dan Shappir

  • Charles Max Wood

Guest

  • Joshua S. Ponelat

Sponsors

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

Picks

Dan Shappir

Charles Max Wood

Josh Ponelat

Dec 03 2019

46mins

Play

Rank #2: RRU 090: How Do I Introduce New Tech at Work?

Podcast cover
Read more

Today the panel is discussing how to introduce new tech at work. They agree that it’s important to get input from all teams on the decision, although it will primarily affect the development team. One should also consider the different ways people make decisions, such as through discussion or quiet thinking, and give everyone time to come to a decision. The panel talks about positive and negative examples of how to introduce new tech at work. Thomas believes that it is important to acknowledge your own biases in decision making and to try to avoid them. The React experts discuss the significance of the team dynamic and the necessity of different roles in decision making or if it is better to have an organic discovery phase. This relates to Thomas’ point about personal biases, and he believes that it is important to put people in roles that are opposite of their personality. When making decisions about new technology, it is also important to note that not all decisions require the same amount of input, and they discuss how to measure how much input is required for a decision.

The discussion turns to methods for introducing testing, and the panelists talk about their experiences. The rule of thumb for introducing testing is to start simple, have an expected behavior, and test the output to see if it matches. Some other aspects of this discussion to consider are that introducing React Hooks could be considered introducing tech, testing is just a new process, introducing new tools, and budget concerns. Charles shares experience convincing his boss to introduce Agile practices which shows the importance of getting management to see the benefits of the new tech or strategy for themselves. The show concludes with the panel acknowledging that other than introducing tech, introducing philosophies on how to organize your code follows the same patterns as introducing technology.

Panelists

  • Thomas Aylott

  • Charles Max Wood

  • Chris Reyes

Sponsors

Links

Picks

Thomas Aylott

Charles Max Wood

Chris Reyes

Dec 03 2019

38mins

Play

Similar Podcasts

DevEd

Adventures in DevOps

React Round Up

Views on Vue

Web Rush

5 minutes of React

JAMstack Radio

Adventures in Angular

The Freelancers' Show

egghead.io developer chats

All Angular Podcasts by Devchat.tv

JavaScript – Software Engineering Daily

JavaScript Jabber

JS Party: JavaScript & Web Dev

React Podcast

Rank #3: VoV 090: Variable Fonts with Mandy Michael

Podcast cover
Read more

In this episode of Views on Vue Charles Max Wood joins Mandy Michael at JAMstack Conf SF, where she gives a talk about responsive typography and variable fonts. Mandy explains what variable fonts are and how they can be used to shrink, stretch and do some very fun and creative thing with them. They discuss how to use them and Mandy explains some of the demos from her talk. 

Charles asks Mandy what some of the things were that she had to cut from her talk. She had to cut a few longer demos, details and performance improvements that can be made with responsive typography. Mandy shares what she is working on now with responsive typography and explains how much fun she has had expressing herself through variable fonts. To see more of Mandy’s demos and to learn more about responsive typography and variable fonts see the links below. 

Panelists

  • Charles Wood

Guest:

  • Mandy Michael

Sponsors

  • Sentry– use the code “devchat” for two months free on Sentry’s small plan

  • CacheFly

Links

Dec 03 2019

20mins

Play

Rank #4: MJS 132: Douglas Crockford

Podcast cover
Read more

Douglas Crockford self-described as the person who discovered that JavaScript has good parts is on this week's My JavaScript Story. Charles and Douglas talk about how Douglas got introduced to programming. and how he specialized in JavaScript.

Douglas realized that there's going to be a convergence of TV and computing very early in his career. So a lot of his career has been bridging those two things, helping the evolution toward digital media. After working for Atari he went to work at Lucasfilm where he stayed for 8 years.

Charles asks Douglas what he is working on now, and what his plans are for the future. Douglas is planning to write more books one of which is Math for Programmers.

Host: Charles Max Wood

Joined by Special Guest:  Douglas Crockford

Sponsors

________________________________________________________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon. Get your copy on that date only for $2.99

________________________________________________________________________________________________

Links

Picks

Charles Max Wood:

Nov 19 2019

44mins

Play

Most Popular Podcasts

The Joe Rogan Experience

TED Talks Daily

The Tim Ferriss Show

The Daily

Stuff You Should Know

Oprah's SuperSoul Conversations

Armchair Expert with Dax Shepard

Rank #5: DevEd 037:  Code Ninjas & Community Learning

Podcast cover
Read more

In this episode of the DevEd podcast, David Graham - founder and CEO of Code Ninjas, introduces himself, gives a background of how he got into software development, briefly describes his vision that led to the creation of Code Ninjas and the interesting work that goes on there. The company essentially consists of coding centres for kids in multiple locations throughout the US, with cool learning programs catering to several age groups, its main purpose being teaching hands on software development combined with a lot of fun. 
The panelists share their views about the current state of programming education in schools, if it is adequate, and what can be done to supplement it. They discuss that it is important to teach kids how to think and how to solve problems rather than relying on memory based learning. They mention ways to get students excited about programming, different learning tools and platforms, and similarities and differences in learning patterns between kids and adult learners.They talk on why should everyone care about coding education for kids, even those who do not have them, and how people can help out in getting youth involved in software development. They also discuss if there is anything they wish had existed to aid learning for young individuals also how it would help them in return. In the end, David explains how can people volunteer for Code Ninjas.

Panel

Joined by speacial guest: David Graham

Sponsors

________________________________________________________________________________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon.  Get your copy on that date only for $1.

________________________________________________________________________________________________________________________

Links

Picks

Mike Dane:

David Graham:

Preston Lamb:

Brooke Avery:

Sam Julien:

The DevEd podcast is produced by Thinkster.io and published by DevChat.TV.

Nov 12 2019

51mins

Play

Rank #6: RR 437: Deploying Rails Onto Kubernetes with Khash Sajadi

Podcast cover
Read more

Khash and Kasia work for Cloud 66, a company started in 2012 with a goal to make Rails deployment simple and infrastructure easy to understand for application developers. As the company has moved towards containerization, they have integrated with Kubernetes. Khash talks about what distinguishes Cloud 66 from other platform as a service companies and why the company was started. He begins by talking about the structure of Heroku, how they own the entire stack down to the server, and how they are bound to a data center. Cloud 66 differs because they decided to break that unit economy from a data center to a server, so they don’t own the entire stack. Instead, they deploy what looks like an experience from Heroku onto your own server so you can go anywhere you want to go. They talk to the public API of those cloud providers within the data center that you choose that your account is in, and then provision, deploy, and maintain your application the way that you used to with Heroku, on that data center. 

Khash talks about how Kubernetes fits into the Cloud 66 model. Cloud 66 was started with Rails, but they wanted to make it generic and available on any framework, and decided this was best accomplished through containerization. They originally had their own containerization service, but then moved over to Kubernetes. Their Kubernetes for Rails product makes deployment of a Rails application onto Kubernetes extremely simple. The panel discusses the different ways that people get to containerization, and situations where containerization is not the correct solution. They also discuss situations where a containerization service like Kubernetes is useful.  Containerization can help a lot with distinguishing and establishing boundaries within a team. Kubernetes can help create uniform servers because you can tell it what you want and it will help you get there, including notifying you when things don’t align. Kubernetes is also excellent at dealing with microservices, if you have a need for a repeatable environment, and provisioning the infrastructure for commits. Khash notes that since moving to a unified infrastructure powered by Kubernetes, upgrades in Cloud 66 take significantly less time and talks about how things have been streamlined.

In the past, David has seen some issues with autoscaling in Kubernetes clusters, and Khash talks about how those things have been addressed and how to approach scaling in general. The first two things you need to define with scaling problems is how much is needed and what is ‘normal’ for your product. It is also important to consider if you need to scale up or scale down, as sometimes scaling down can hold more benefits. Khash has noticed that one thing that’s missing in the market is that as Rails developers they’re all about finding the best tools and getting the job done, while this approach is lacking in Kubernetes. He closes the show by talking about how Cloud 66 is trying to address what a Kubernetes deployment means for a Rails stack.

Panelists

  • Andrew Mason

  • David Kimura

With special guests: Khash Sajadi and Kasia Hoffman

Sponsors

 "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon.  Get your copy on that date only for $1.

Links

Follow DevChatTV on Facebook and Twitter

Picks

Andrew Mason:

David Kimura:

Khash Sajadi:

  • Follow Khash on Twitter @khash

Kasia Hoffman:

Nov 12 2019

55mins

Play

Rank #7: TFS 347: Recession-Proofing Your Business

Podcast cover
Read more

In this episode of The Freelancers Show, Reuven Lerner gives some insight into recessions, how they work and how you can prepare for them. He explains that an economy will rise and fall but is always growing. A recession is when instead of growing the economy decreases, there is less business activity, layoffs, etc… 

Reuven explains why some people are talking about an upcoming recession. It is impossible to predict a recession but economists can use various events as signs of possible recessions. He explains how the long expansion, trade wars, and the inverted yield curve all point to an upcoming recession. Recession doesn’t always affect every sector, Reuven shares examples of recessions and the sectors they hit. 

Reuven lists ways to prepare your business for a recession and share examples of how he has been doing this for his own business. First, make sure you cast a wide net for potential clients. Next, specialize in something specific and make sure the world knows your name and what you do. He stresses the importance of starting a mailing list. 

Reuven warns against remaining in one vertical sector. He also warns to be careful about employing anyone full time and shares the pain he suffered during a recession trying to pay everyone’s salaries out of pocket. He advises moving from only working business to business to business to customer and gives tips on how to start that move. Finally in encourages everyone to keep up with economic news.

Panelists

  • Reuven Lerner

Sponsors

Links

Picks

Reuven Lerner:

Nov 12 2019

38mins

Play

Rank #8: VoV 087: There is No Shame in Mental Illness

Podcast cover
Read more

In this episode of Views on Vue panel discusses mental health. They start by sharing what they do in their free time and consider the value of having a balanced life with hobbies and time spent doing non-code related things. They discuss the importance of respecting your mental health and being aware of where you stand. It is possible to stay aware of things going on in the coding community and to be successful without coding in all your free time.

The panel shares strategies and techniques they use to alleviate burn out. Taking breaks and days off. They stress the truth that a mental health day is a sick day. Focusing on the reason you are coding, the people. The panel warns against obligations that trap you in a toxic environment. 

Inspiration is the next topic the panel discusses. Some of the things to keep their fire burning are considered. Ari explains how Views on Vue helps her stay inspired. Listening to other podcasts and connecting to people. They consider the value in building stupid and crazy tutorials. They discuss how relationships affect mental health. 

Diagnoses and labels and how they affect us are considered. The panelists open up and explain how being diagnosed affected their mental health. Ways to support those around us with mental illness are explored. Ben explains three things to remember when dealing with anyone not just those with mental illness; be empathetic, ask questions and do not make assumptions. 

When discussing ways to recognize when a coworker is struggling, Ben introduces red, yellow, green check-ins. He explains that at his work they all share where they are red, yellow or green. This way their team can be aware of their mental state. The panel explains how this activity could benefit them and their teams. 

Panelists

  • Ben Hong

  • Elizabeth Fine

  • Ari Clark

Sponsors  

________________________________________________________________________________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood will be out on November 20th on Amazon.  Get your copy on that date only for $1.

________________________________________________________________________________________________________________________

Links

Picks

Ben Hong:

Elizabeth Fine:

Ari Clark:

Nov 12 2019

1hr 6mins

Play

Rank #9: Sam Julien Interview - Gatsby

Podcast cover
Read more

In this episode of the DevEd podcast, Brooke interviews Sam on Gatsby, and Sam's new course on Thinkster.io. Sam works in Developer Relations at Auth0, is a Google Developer Expert for Angular and Web Technologies, and is very passionate about teaching. Sam starts by explaining in detail what Gatsby is and what it is used for. He talks on the performance benefits of Gatsby, its comparison to React in terms of tooling and usage as well as learning, and if there are any tools or technologies needed as prerequisites to use Gatsby. He elaborates on what made him learn Gatsby, how it helped him advance his programming career, and both his favorite and not so favorite aspects of Gatsby. He then talks at length about his course - Up and Running with Gatsby, reasons he chose this topic specifically, the course design, and compelling reasons why people should go for it. In the end, he shares his thoughts on how Gatsby is getting popular and can help speed up development in enterprise companies and large organizations.

Panel

Sponsors

Links

The DevEd podcast is produced by Thinkster.io and published by DevChat.TV.

Nov 07 2019

44mins

Play

Rank #10: MJS 130: Javan Makhmali

Podcast cover
Read more

This week, My Javascript Story welcomes Javan Makhmali,a Programmer at Basecamp from Ann Arbor, Michigan. Javan attended Community College to study Computer Science but then decided to work as a Freelancer developer. Javan and Charles debate whether having a 4-year college degree is better to become a developer and conclude that it depends on the person. Some people prefer a structured 4 year degree to feel ready for a full time jo and some people do better with bootcamps. Javan mentions he knows several people that switched careers after completing an 8 week bootcamp and that the industry was really flexible to accomodate both options.

Charles and Javan then continue talking about Javan's journey as a developer and particularly his journey with Basecamp. Javan started out working with Ruby on Rails and after a couple of years applied for a job at Basecamp (then known as 37 Signals). Javan then started working with CoffeeScript which helped him understand working with JavaScript.

Charles and Javan talk about the projects Javan is working on currently at Basecamp. Outside of work Javan, is a new parent and enjoys spending time with his daughter. He feels ever since he has become a parent, his work life balance has been better.

Host: Charles Max Wood

Joined by Special Guest:  Javan Makhmali

Links

Sponsors

Picks

Charles Max Wood:

Nov 05 2019

34mins

Play

Rank #11: .NET 012: F# with Phillip Carter

Podcast cover
Read more

In this episode of Adventures in .NET the panel interviews Phillip Carter. Phillip works on the .NET team. His primary focus is F# and F# tooling. Phillip starts off by explaining that F# is a functional programming language, whereas C# is an object-oriented language. Phillip explains how F# is a nice way for those who want to do functional programming to do so with a full ecosystem and quality tools and libraries. 

Phillip explains how F# is used in .NET. Some prefer to use only F# but the major mix and match F# and C#. He shares projects he has done mixing and matching F# and C#, explaining how he did and the other methods used to use both F# and C#. 

The panel discusses the popularity of F# and where it is most well known. Phillip shares the two biggest sites where F# sharp is used are Jet and Walmart e-commerce, their backends are build using an F# microservice. He explains that a lot of financial institutions use F# in their backends as it is good for number crunching. The panel considers the growth of F# since .NET Core 2.0 was released. After .NET Core 2.0 was released F# usage spiked, F# microservices and open source projects became much more common.

The panel asks Phillip about what Blazor means for F#. He explains that in the past, some people are really into Fable. This tool takes F# syntax trees into JavaScript syntax trees. Currently, the web assembly is starting to heat up now that Blazor is here. F# can plug directly into the Blazor runtime making it a pretty viable alternative. 

The panel considers the mental hurdles required when switching from C# to F#. Phillip explains how that switch may be easier for some than for others. Using an example of building a web service, Phillip explains how someone approaches a process or a problem will determine how easily someone can transition from C# to F#. He elaborates, explaining that if a developer is really used to object-oriented programming and it’s patterns it may be more difficult to move to F#.

The panel shares some of its views on F#, wondering if it isn’t easier to learn for those who are new to programming. Phillip considers their views and explaining that even though they can’t prove it they have also seen this possibility. At the Ignite conference, they are coming out with a preview Jupiter Notebook tooling, putting C# and F# on top and integrating it into the Jupiter ecosystem. Phillip admits they have been wondering if they might not be able to reach the non or secondary programmers more easily with F#. F# may be more familiar to those who only have a simple background in Python they picked up in college. He explains how overwhelming C# can be to someone who has never seen anything like it before.  

Phillip compares the syntax of C# and F#, explaining that they are very different. F# is more similar to Python than to C#. F# is white space significant and uses type inferences. He explains how these differences might trip up someone who is familiar with C#. C# and F# have a few similarities like you can still dot into something just like in C#.  

The panel wonders what kind of cooperation is seen between the F# and C# teams at Microsoft. Phillip explains that they work very closely and sharing a few examples. He worked on nullable reference types in C# 8.0. He explains that they have a mindset, they are all Microsoft in the end and what C# and F# to interoperate as best they can. 

F# is currently on version 4.7, which was released with C# 8.0. He shares some of the changes made to F# with this latest version. Including, core library fixes, performance fixes and the cleaning up of little syntactical quirks. He explains that is a culmination of a lot of minor changes to improve the language. Phillip shares what’s coming in F# 5.0 which will hopefully be released with the .NET 5.0 release. 

The episode ends as Phillip shares some resources for getting started with F#. He encourages everyone to give it a try. He promises that even if you decide its not for you, it will help you see your code in new ways. 

Panelists

  • Shawn Clabough

  • Wade Gausden

  • Wai Liu

Guest

  • Phillip Carter

Sponsors

Links

Picks

Wai Liu:

Wade Gausden:

Phillip Carter:

Shawn Clabough:

Oct 29 2019

50mins

Play

Rank #12: MJS 129: Filipa Lacerda

Podcast cover
Read more

Charles Max Wood talks to Filipa Lacerda in this week's My JavaScript Story. Filipa has been working as a front end engineer since 2011 and she currently works at GitLab.

Filipa originally wanted to study Economy but when she got to university she decided to major in Communications thinking it would be a lot more about communication and not as much about coding. At first she really didn't like the coding aspect of it but then as time went by she actually started to enjoy coding.

When she first started working she started out on the User Experience side, but then she wanted to switch to building stuff with code because she wanted to see results really fast and enjoyed that aspect of coding.

Charles asks why she stuck with that degree instead of switching it and Filipa explains that at first because she didn't want to go back and re - take the exams and also decided that this degree offered many job opportunities in many different industries and now she can't imagine herself doing anything else.

Filipa then talks about why she is working with Vue and all the different kind of projects she has done using Vue as well as what working for GitLab looks like on a day to day basis.

Host: Charles Max Wood

Joined by Special Guest:  Filipa Lacerda

Links

Sponsors

  • Sentry use the code “devchat” for 2 months free on Sentry small plan

  • Adventures in .NET

  • Elixir Mix

  • CacheFly

Picks

Filipa Lacerda:

Charles Max Wood:

Oct 29 2019

25mins

Play

Rank #13: iPS 276: Automating Painful Things with David House

Podcast cover
Read more

In this episode of The iPhreaks Show the panel interviews David House about Continous Integration and Continuous Delivery. David is an iOS developer currently living in Georgia. He has been working in iOS development since the iOS SDK was int beta.  Right now he is working for a health care company, Kaiser Permanente.

David starts by sharing how he became interested in this topic. Kaiser Permanente is a large enterprise and has large enterprise applications. Their iOS app has almost a million users along with employees who use the app as well. This led him to find a way to scale an app for a large app while also maintain quality and security. 

The panel asks David to breakdown the terms Continuous Integration and Continuous Delivery. David explains that neither of these terms was meant for mobile so they now have a different meaning. Originally, Continuous Integration meant you were integrating developer changes in an automated fashion. Continuous Delivery meant you were shipping out code in an automated fashion. Now CI/CD just means you can automate things and run them continuous through your workflow, not just integration and delivery. 

The panel wonders how automated systems have effected that end of the workday ritual of checking your daily build. David explains how automated pull request has made this ritual obsolete. He explains the shift left approach which is the idea is to shorten the time frame between submitting your build and receiving feedback. With the rise of the pull request, this timeframe has been significantly reduced, essentially giving you continuous feedback.

Pull requests can be a pain at first but David explains how getting into a habit of using them can say developers a lot of pain and worry. 

David shares a life hack that also translates well to programming. The more you regulate the boring and the tedious the more room in your brain you have for interesting and new ideas. He equates this to automation. By automating the parts of your job that are tedious and painful, you free up time and brain space for the more interesting parts of your job. He uses the example of the pain and time it took to get an app into the app store, after automating that he had more time to do the cool parts of his job that he enjoys. The panel discusses how this can benefit the solo developer and not just a developer that is part of a team.

The panel considers how automation affects the way developers learn, does help developers avoid learning to do something for themselves. Unfortunately, David believes that true. He recommends learning how to do the things your automated systems do, it may just save your butt when your system fails. He advises thinking of automated systems as a minion. It is there to do the tedious and painful jobs you don’t want to do yourself but you should still know what your minion is doing. 

The panel considers the various CI tools. David has used many different tools including Jenkins, Travis, CircleCI, Bitrise and the beta for Github actions. He explains that Bitrise is a great option, it is very visual and good for beginners. Github action will be good once it is released, the best part will be the community. Both Github action and Bitrise are opensource. Jenkins has been around forever, therefore, it has good roots and is powerful. However, Jenkins is not for everyone. David explains that there should be more tools to fill the spectrum of needs. 

The panel considers security in automated systems. David explains that it is hard to tell which automated systems are more secure. They consider ways to determine how secure an automated system is. Open source is one way, you can look for holes in the system by checking out the source code. Also, some systems have a reputation for security. 

The panel considers the lack of educational resources and good documentation for CIs. David shares how frustrating it can be to try and find a fix for a failed build in a CI. He shares some of his hopes for the future of CI including, rich feedback, documentation, and resources for learning automated systems.

The episode ends with a discussion of Xcode bots. Peter Witham shares his experience using them. David explains that even though they have great user experience it is still really limited in what it can do. The panel finishes with some final advice for automating painful things.

Panelists

  • Andrew Madsen

  • Peter Witham

Guest

  • David House

Sponsors

Links

Picks

Andrew Madsen:

Peter Witham:

 David House:

Oct 22 2019

53mins

Play

Rank #14: JSJ 401: Hasura with Tanmai Gopal

Podcast cover
Read more

Tanmai is one of the founders at Hasura. Hasura gives you instant graphQL APIs on top of a Postgres database. The eventual idea is to make data access secure and easy. Tanmai explains the challenges of doing this in the cloud. He talks about some of the difficulties with the tooling around using GraphQL and its bias towards working well with a monolith. Since GraphQL is basically a shared type system that describes your API, that means all your types need to be in the same code base. This is at odds with the folks who want to do microservices and serverless functions, because since their API is split across multiple services they have different types, and forcing these types to work together defeats the purpose of using microservices. Also, storing state across requests doesn’t work well with serverless and cloud native stuff. In short, learning to live without state is one of the general challenges with going serverless. 

This is where Hasura comes into play, and Tanmai explains how it works. Hasura is metadata driven, and each instance of the server can leverage multiple calls and exhibit a high amount of concurrency. It’s designed to be a little more CPU bound than memory bound, which means that configuring auto scaling on it is very easy and allows you to utilize the elasticity of cloud native applications. Tanmai clarifies his usage of the word ‘cloud native’, by which he means microservices. He explains that when you have a metadata based engine, this metadata has a language that allows you to bring to bring in types from multiple upstream microservices, and create a coherent graphQL API on top of that. Hasura is a middle man between the microservices and the consumer that converts multiple types into a single coherent graphQL API.

Next, Tanmai explains how Hasura handles data fetching and a high volume of requests. They also invented PostgresQL, RLS-like semantics within Hasura. He explains the process for merging your microservices into a single graphQL interface. Back on data fetching, Tanmai explains that when the product is an app, preventing an overabundance of queries becomes easier because during one of the staging processes that they have, they extract all of the queries that the app is actually making, and in the production version it only allows the queries that it has seen before. Hasura is focused on both the public interface and private use cases, though private is slightly better supported. 

Tanmai talks about the customizations available with Hasura. Hasura supports two layers. One is an aliasing layer that lets you rename tables, columns, etc as exposed by PostgresQL. The other is a computer column, so that you can add computer columns so you can extend the type that you get from a data model, and then you can point that to something that you derive. 

The panelist discusses the common conception of why it is a bad idea to expose the data models to the frontend folks directly. They discuss the trend of ‘dumbing down’ available tooling to appeal to junior developers, at the cost of making the backend more complicated. They talk about some of the issues that come from this, and the importance of tooling to solve this concern. 

Finally, Tanmai talks about the reasons to use Hasura over other products. There are 2 technologies that help with integrating arbitrary data sources. First is authorization grammar, their version of RLS that can extend to any system of types and relationships, The second is the data wrapper, part of the compiler that compiles from the graphQL metadata AST to the actual SQL AST. That is a generic interface, so anyone can come in and plug in a Haskell module that has that interface and implement a backend compiler for a native query language. This allows us to plug in other sources and stitch microservices together. The show concludes with Tanmai talking about their choice to use Haskell to make Hasura. 

Panelists

  • AJ O’Neal

  • Dan Shapir

  • Steve Edwards

  • Charles Max Wood

With special guest: Tanmai Gopal

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

AJ O’Neal:

Dan Shapir:

Steve Edwards:

Charles Max Wood:

Tanmai Gopal: 

Oct 17 2019

1hr 10mins

Play

Rank #15: iPS 275: Finding Quality Packages using SwiftPM Library with Dave Verwer

Podcast cover
Read more

In this episode of The iPhreaks Show the panel interviews Dave Verwer about his new SwiftPM Library. Dave is an iOS developer from the UK, he’s been working with iOS since the beginning. He is mostly known for his weekly email newsletter, iOS Dev Weekly, which is released every Friday afternoon.

SwiftPM Library is a site that aims to make it easy for people to find quality packages that support the Swift Package Manager to integrate into their project. It is a repository of all the packages he can find and anyone can contribute packages to it. 

The CocoaPods Quality Index was his inspiration for this library. The CocoaPods Quality Index gives a quality score based on a few metrics, Dave wanted to do this but specifically for packages that support SwiftPM. The panel considers what this means for SwiftPM, which unlike most package managers it does not have a library of packages to use. 

Dave sees two outcomes for the SwiftPM Library, either it becomes the go-to place for people to discover new packages or Github package registry will come along and kill it. The Github package registry is a multiplatform, multilanguage tool for registering packages. Daves explains the features that SwiftPM Library has that gives it a fighting chance against the Github package registry. 

First, the SwiftPM Library was built with speed in mind. The Github package registry piggybacks on Github search which therefore will take longer. Also, Github is likely to list its packages in a way that he take those packages and include them in his library as well, so Github will not have more Swift supporting packages than the SwiftPM Library. 

Another thing that sets apart SwiftPM Library is that it is all about Swift. The Github package registry also supports other languages like Ruby and Java. It is doubtful that Github will have very many Swift specific features and metadata on their site, where at the SwiftPM Library Dave already has many of those in place. 

The panel asks Dave about SwiftPM and how it compares to CocoaPods and Carthage. He explains that SwiftPM is very similar to using Cocoapods, however, you can create a library using X code and also include other libraries as dependencies. He gives a brief walkthrough of how to replace CocoaPods with SwiftPM in a project. 

SwiftPM has a couple of limitations that the SwiftPM team is currently working on. Right now in SwiftPM, it does not support resources, such as zip files and images, in packages. Another major limitation of SwiftPM is that you cannot switch between languages in a Swift package. The panel considers these limitations and shares how they affect whether or not they choose SwiftPM. 

Once these problems are solved, Dave hopes that everyone will transition to SwiftPM. SwiftPM is managed by Apple, therefore, is a cleaner and better option even though the transition may be painful. The panel shares the things they like about SwiftPM, including how easy it is to use. It becomes so easy to update packages and dependencies after the transition.

Back to the SwiftPM Library, the panel asks Dave more about it works. Dave explains how the quality index works, giving each package a score based on a few quality metrics. The value of a quality index comes from the need to be careful when adding a dependency. The search results on his site are based on the quality score of each package. 

The metrics Dave is currently using to measure are: Does it support the latest version of Swift? How many versions of the package have been released? How many stars does it have on its Github repository? Does the license file exist and is it an open source license that is unencumbered?

The panel takes a look at what the search results look like. Dave includes everything a developer would need to know in order to choose the best package for their project. The search results highlight the license source. It includes how many libraries and executables are included in the package. The search results show what version of swift and other platforms are supported. Not only does it show you the master branch but also the latest stable version and the latest beta of the package when possible.

Dave walks the listeners through how to contribute packages to the library. Dave explains his philosophy when it comes to running the site, his role is not a gatekeeper. He doesn’t want to decide which packages to include and which to exclude. His hope is that the quality indexing will sort the good from the bad. Anyone can add to the library and anyone can request a removal from the library. Any problems with packages should be deferred back to there maintainers. 

Panelists

  • Jaim Zuber

  • Abbey Jackson

  • Gui Rambo

  • Andrew Madsen

Guest

  • Dave Verwer

Sponsors  

Links

Picks

Dave Verwer:

Jaim Zuber:

Andrew Madsen:

Gui Rambo:

Abbey Jackson:

Oct 15 2019

57mins

Play

Rank #16: JSJ 399: Debugging with Async/Await with Valeri Karpov

Podcast cover
Read more

Valeri Karpov is a maintainer on Mongoose, has started a few companies, and works for a company called Booster Fuels. Today’s topic debugging with Async/Await. The panel talks about some of the challenges of debugging with Async. AJ, however, has never encountered the same problems, so he shares his debugging method. 

Valeri differentiates between .catch vs try...catch, and talks about why he prefers .catch. There are two ways to handle all errors in an async function without leading to an unhandled promise rejection. The first is to wrap the entire body of the async function in a try...catch, has some limitations. Calling an async function always returns a promise, so the other approach is calling .catch on the promise to handle any errors that occur in that function body. One of the key differences is if you return a promise within an async function, and that return promise is wrapped in a try...catch, the catch block won’t get called if that promise is rejected, whereas if you call .catch on the promise that the function returns, you’ll actually catch that error. There are rare instances where this can get tricky and unintuitive, such as where you have to call new promise and have resolve and reject, and you can get unexpected behavior.

The panel discusses Valeri’s current favorite JS interview question, which is,  “Given a stream, implement a function called ‘stream to promise’ that, given a stream, returns a promise that resolves to the concatenation of all the data chunks emitted by the stream, or rejects if the stream emits an error event.” It’s really simple to get this qustion right, and really simple to get it wrong, and the difference can be catastrophic. AJ cautions listeners to never use the data event except in the cases Val was talking about, only use the readable event.

The conversation turns to the function of a readable event. Since data always pushes data, when you get a readable event, it’s up to you to call read inside the function handler, and then you get back a chunk of data, call read again and again until the read returns null. When you use readable, you are in control and you avoid piling functions into RAM. In addition, the right function will return true or false to let you know if the buffer is full or not. This is a way to mix imperative style into a stream.

The next discussion topics are the differences between imperative style and reactive style and how a waits and promises work in a normal four loop. A wait suspends the execution of a function until the promise is resolved. Does a wait actually stop the loop or is it just transpiling like a promise and it doesn’t stop the loop. AJ wrote a module called Batch Async to be not as greedy as promise.all but not as limited as other options.

The JavaScript panelists talk about different async iterators they’ve used, such as Babel. They discuss the merits of Babel, especially since baseline Android phones (which a significant portion of the population of the world uses) run UC Browser that doesn’t support Babel, and so a significant chunk of the population of the world. On the other hand, if you want to target a large audience, you need to use Babel.

Since frameworks in general don’t handle async very well, the panel discusses ways to mitigate this. They talk about different frameworks like Vue, React, and Express and how they support async functions. They discuss why there is no way for you to actually cancel an async option in an actual case, how complex canceling is, and what you are really trying to solve for in the cancellation process. 

Canceling something is a complex problem. Valeri talks about his one case where he had a specific bug that required non-generic engineering to solve, and cancelling actually solved something. When AJ has come across cancellation issues, it’s very specific to that use case. The rest of the panelists talk about their experiences with having to cancel something. 

Finally, they talk about their experience with async generator functions. A generator is a function that lets you enter into the function later. This makes sense for very large or long running data sets, but when you have a bounded items, don’t complicate your code this way. When an async generator function yields, you explicitly need to call next in order for it to pick up again. If you don’t call ‘next’, it’s essentially cancelled. Remember that object.keys and object.values are your friends. 

Panelists

  • Christopher Buecheler

  • AJ O’Neal

  • Charles Max Wood

With special guest: Valeri Karpov

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

AJ O’Neal:

Christopher Buecheler:

Charles Max Wood:

Valeri Karpov:

Oct 10 2019

1hr 3mins

Play

Rank #17: RRU 082: Progressive SSR with Dinesh Pandiyan

Podcast cover
Read more

Dinesh Pandiyan is a developer from India. He started as a backend engineer and then moved to frontend. Currently he is working for ThinkMill in Sidney, Australia. Today Dinesh and the panel are talking about devtools and progressive SSR.

Dinesh got started with React Redux. The panelists talk about their experiences using primarily Redux for projects. Dinesh talks about his transition from backend to frontend and how it’s a totally different world. On the backend he was working in Java and it ran on a server, but on the frontend, code runs in a browser and the browser is very different for each user. Frontend development is tricky because you don’t know where your code is going to run.

One of the trickiest parts of frontend development is debugging something in production. Unless you have good logging tools, you won’t know what’s going on. Debugging this stuff when it’s running on client browsers is hard, but when you’re in development mode your own browser you’ve got handy tools. 

They talk about some of the tools in React, and agree that console.log is the greatest debugging tool of all time. Dinesh talks about some of the most surprising features about React dev tools. You can benchmark your preferences and identify weaklings in your project, which are things that slow down your application or things that might slow it down. On an application level, you have to build a mental model of how the data flows from the top, where things change, etc, and dev tools can help you build that pretty easily. They talk about how things had to be done before great React tools. In fact, Dinesh chose React just for the devtools. They talk about how the dev tools for React compare to Java. The most important thing is that you have a good debugger that can stop where you want it to. 

They transition to talking about the differences between SSR and progressive SSR For SSR (Server Side Rendering), rendering happens on the server and you send it to the client. CSSR (Client Server Side Rendering) is when all the rendering happens on the client’s side. PSSR (Progressive Server Side Rendering) is where you render small chunks on the server and then send it to the client bit by bit. They talk about how this has been occurring from the beginning of the internet. This concept is similar to microfrontends. 

Dinesh gives advice on how to implement PSSR. He says that when you surver render, it loads on differently. Your framework has to do one complete pass of the histiema, so this means you cannot send things to the client until the whole histema is designated. To beat this they’ve been doing a mix of SSR and CSR, with the header, body, and non critical content rendering on the client side. PSSR bridges the gap between SSR and CSSR.

How do we make it real and how do we use it?

The panel discusses ways to make PSSR a reality. Dinesh has been experimenting with it with extra services, and he gives his method for doing it, emphasizing the importance of where you divide your code is very important, it has to be in sequence. CSS Grid solves this problem, so you could render things out of order and the browser puts it in the right spot. They talk about other ways to get around it. Lucas shares some of the difficulties he’s encountered with streaming and rendering. They talk about the new feature for the Phoenix framework for Elixir, Live View Now. For this feature, you don’t need client side frameworks to generate dynamic content and it enables two way streaming. However, it does not scale well for extremely large apps. They talk about some of the tradeoffs for using this feature. They conclude by discussing the gap between website optimization and device performance. 

Panelists

  • Thomas Aylott

  • Dave Ceddia

  • Lucas Reis

With special guest: Dinesh Pandiyan

Sponsors

Links

Follow DevChatTV on Facebook and Twitter

Picks

Lucas Reis:

Thomas Aylott:

Dinesh Pandiyan:

David Ceddia: 

Oct 08 2019

50mins

Play

Rank #18: VoV 082: Developer Tooling and Dev Setup for Working With Vue

Podcast cover
Read more

On this episode of Views on Vue the panelists discuss their preferences for their development environments and tools. They begin with their preferences for text editor, font, and theme in their Vue development environments. All three currently use Visual Studio Code as their main text editor. Ari Clark switched to VS Code from Atom because she prefers the support that it has for Vue and Ben Hong switched from Sublime. Ben prefers the night owl theme and the operator mono font. On the other hand, Ari prefers the one dark pro theme for its syntax highlighting and prefers dank mono as her font.

The Views on Vue panelists then go on to discuss their preferences on using the terminal. They weigh the pros and cons of using the integrated terminal and when they turn to other shells. The other potential shells that the Vue panelists discuss are Bash, Zsh, and Fish. The panelists focus on the speed and performance of the shells, and make an important note that not all shell commands are valid on other shells and the user will have to be familiar with the shell they are using. The Vue experts discuss whether they use the command line interface (CLI) or VS Code version control to manage their git version control. The panelists then weigh the pros and cons of different terminal shells they like to use. The panelists also briefly discuss how open they are to changing their development environment setup. 

The topic then shifts to extensions for VS Code. The Views on Vue podcasters mention their preferences for a bracket colorizer, extension packs, code snippets and other tools. They talk specifically about the following extensions: Vue VS Code Extension Pack and Vue VS Code Snippets by Sarah Drasner, and Vetur created by Pine Wu, the latter of which the panelists identify as a quintessential extension for writing Vue. They discuss the merits of code snippet extensions as reusable code and creating them in VS Code.  They also discuss some of the different types of snippets that exist and how to use them.

The Views on Vue panelists discuss ways to enforce best practices in addition to code snippets. They talk about using code generators like Hygen to automatically fill out the template for specific types of files. They share that creating unit tests helps to ensure best practices and that the code works as intended, as well as the differences between unit tests and end to end tests. They go over the strengths of an end to end testing tool called cypress. Tools like Husky or Yorkie allow you to add pre commit hooks to the package.json file that will automatically manage all the linting for a project. 

Finally the panelists share their preferences browser tooling for Vue projects in addition to browser developer tools and their browsers of choice. Ari says that she prefers the previous version (version 4) of Vue devtools than the current version (version 5) and her reasons why. Chris Fritz shares that he likes Vimium for setting up quick navigation and Ben shares that he likes to use Keyboard Maestro.

Panelists

  • Ben Hong 

  • Ari Clark 

  • Chris Fritz

Sponsors

Links

Picks

Ari Clark

Ben Hong

Chris Fritz

Children of Ruin

Oct 08 2019

1hr 2mins

Play

Rank #19: VoV 080: Awesome Conf with Rahul Kadyan

Podcast cover
Read more

In this episode of Views on Vue the panel interviews core team member Rahul Kadyan. They discuss his various contributions to the vue ecosystem and his recent conference, Awesome Conf. The panel starts by asking Rahul about rollup-plugin-vue. Rollup is a bundle like webpack. When Rahul got his start in Vue he wanted to use rollup so he created rollup-plugin-vue. This caught the eye of the core team and he received an invite to join the core team. 

Rahul spends most of his time in Vue working with compilers, the panel asks him about template compilation. He explains when template compilation happens and how knowing how it works can help you create better templates. Rahul shares all the awesome things that can be done with templates.

The topic moves to stand alone and runtime only builds in Vue. Rahul explains how each of these builds. The panel considers possible use cases for both builds. The stand alone build being larger is good for only about 10% of cases. The runtime only build works well in cases where you already have a build process. On top of Vue being smaller, it can also make your website run faster.   

Rahul recently gave a talk about single file components or SFC in Vue. He explains the easiest ways to use SFC and what it is capable of. The panel compares SFC to an ordinary JavaScript file. Rahul lists the benefits of using and SFC over a regular JavaScript file, one being you get the best out of the box render function in Vue. 

The panel asks about the work Rahul is doing at work, building a design language system. He explains the difference between a design system and a design language system.  A design language system defines what every interaction will look like, it has a larger scope than a regular design system. He explains how useful it is and what they use it for. 

Some of his other contributions to the Vue ecosystem include the vs code language plugin he is currently working on. In this project, he is exploring ways to find all your global components so that way he can provide completions for all the components. Also in this plugin, he is exploring using a compiler to get all the information about each component.  He is hoping to include editing capabilities which gets the panel really excited. 

Rahul has a repo called vue-lazy-hydration, which allows you to hydrate components as you need them while doing server-side rendering. He explains what he means by hydration and how by using async hydration the long delay that normally comes with server-side rendering is no longer a problem. He is currently creating demos for the repo. 

The first Awesome Conf was held recently and Rahul shares his experience setting it up. Awesome Conf is different than other conferences in that the speakers were actually the attendees. Rahul explains how all this came about. At first, they were going for a normal conference but didn’t get enough speakers, so they reached out to the attendees and told them they would have to provide the talks. They provided topics for the attendees to choose from and chose 15 talks from the ones submitted. With such a small conference they let everyone bring a plus one. The conference was a success and everyone had a great time. 

Rahul is looking forward to doing another Awesome Conf this time for design. He is still working out the details but he wants a diverse group that can really learn from each other. The panel considers what they would do if they were asked to speak. They share their fears of speaking and Rahul shares some of the advice he gave to the speakers as he helped them prepare for their talks. 

To finish the episode, Chris Fritz asks Rahul why he chooses to work with compilation. Rahul shares his story about getting into computer science and eventually compilation. He explains why he loves working in compilation and how it helps him as a front end developer.   

Panelists

  • Chris Fritz

  • Elizabeth Fine

  • Ari Clark

Guest

  • Rahul Kadyan

Sponsors  

Links

Picks

Chris Fritz:

Elizabeth Fine:

Ari Clark:

Rahul Kadyan:

Sep 24 2019

58mins

Play

Rank #20: .NET 006: Async and C# 8 with Filip Ekberg

Podcast cover
Read more

Episode Summary

In this week’s episode of Adventures in .NET the panel interviews Filip Ekberg, Microsoft MVP, about using async, await, and the new features in C# 8. They begin by discussing the evolution of running tasks and multithreading in async. Filip describes the evolution beginning with background workers, through task parallel libraries finally to async and await. The panel considers how managing tasks has been made almost too easy.  

Filip explains that there has been a drive to make everything asynchronous but explains that this approach doesn’t always make sense. The panel asks Filip when a developer should use async and await. If an application has a UI, Filip encourages the use of async and await and he outlines the benefits. He also explains that if someone wants to be a full-stack developer they need to understand async and await on both the serverside and clientside. 

The panel wonders what the most common async and await mistakes are in .NET. Filip shares a couple of the most common mistakes he sees. The first is deadlocking an application because of the inappropriate methods such as .result and .wait on tasks. The second is marking methods as async without running the await keyword. He explains what these mistakes do to your application and gives advice on avoiding these mistakes. 

The panel expresses past frustrations in making all methods especially tops methods when in ASP.NET. Filip gives the panel advice on making it asynchronous top to bottom and ways to handle those aggravating top methods. He also explains how to use the await keyword and state machines effectively.

Debugging in async is the next topic the panel considers. Filip explains why debugging is so tricky in asynchronous applications. He gives a few tips, his biggest piece of advice is to update Visual Studio and you should get more help in debugging than from older versions. 

The panel moves on to discuss C# 8. Filip explains that C# is his language, he loves it! He shares three new changes to the language features in C# 8. They made changes to how tuples work, pattern matching and null reference types. 

Tuples are the first change the panel considers. Filip explains what tuples are and what they do. Tuples allow you to represent a type without actually using that type. The panel considers how tuples have changed in C# 8, they are still position based but are more flexible in calling them. 

Next, the panel discusses null reference types. The control null reference types allow over nulls is considered. Filip shares some recommendations for using null reference types. The panel considers what might happen if someone were to use null reference types in an existing application. The wonder if it would have any benefit or if it would break the whole application. 

The final feature they discuss is pattern matching. Filip explains the benefit of using the new pattern matching with the new tuples feature in C# 8. The new pattern matching can be used to find tupple patterns, position patterns, and property patterns. 


Panelists

  • Shawn Clabough

  • Charles Max Wood

  • Caleb Wells

Guest

  • Filip Ekberg

Sponsors  

Links

Picks

Charles Max Wood:

Caleb Wells:

Filip Ekberg:

Shawn Clabough:

Sep 17 2019

48mins

Play