my private podcast channel
Find Joel Spolsky on Twitter here.
Jeff Atwood is on Twitter here.
Geoff Dalgas is on Twitter here.
Follow Jarrod Dixon on Twitter here.
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
PlanetScale is built on Vitess, the open-source database clustering system that runs at colossal scale hosting YouTube, Slack, and GitHub.
A familiar theme: Big cloud companies aren’t set up for independent developers. Sam and Ceora discuss how serverless can get projects—even businesses—up and running quickly.
Choosing the stack for a new business? Tools like Netlify can scale with your product, so you don’t have to change your architecture as you evolve.
Staging environments should be a thing of the past. That’s why PlanetScale enables database branching.
And finally, a question from Law Stack Exchange: Can satellite images be copyrighted?
This “Trojan source” bug (get it?) could threaten the security of all code.
In its annual report on its user community, GitHub found that developers appreciate automation, reusing code, and remote work. (No surprises there.)
Ceora explains how automation and code reuse are game changers for independent developers and how this logic is spreading to big tech companies, too.
GitHub’s first Chief Security Officer has the company focused on keeping your repo secure.
GDPR makes you legally responsible for data someone else shares with you. That’s just one of the reasons it’s not a good idea to solicit personal information through a form and then read those secrets on TikTok.
Ethan's book, Once a Bitcoin Miner: Scandal and Turmoil in the Cryptocurrency Wild West, is available now.
The metaverse isn’t just inevitable; it’s already here (and it has a booming real estate market).
As we move more of our lives online onto platforms controlled by increasingly powerful digital giants, Ethan explains the democratizing power of cryptocurrency and blockchain.
On the other hand, China’s new digital currency (government-issued but crypto-inspired) raises questions about privacy and surveillance. And why did China declare all cryptocurrency transactions illegal?
Is crypto the new oil—an environmental disaster burning all this energy in the face of climate change? Bitcoin was using as much energy as Finland or Pakistan
.
The conversation was inspired by Epic's decision to make it's Kid's Web Service's parent verification free to all developers.
Ben has been grappling with these questions since 2013, when he wrote about allowing screen time into his young son's life.
One thing that old article does remind us; how incredibly indestructible the original iPad was. A true tank of a tablet!
Thanks to our lifeboat badge winner of the week, javimuu, for explaining: How to get a Thumbail / Preview image from Server Video Url in Swift 3.0
We kick things off by weighing the merits of two gender-neutral regional pronouns: the familiar y’all and the under appreciated yinz. Now that’s covered...
The global population of developers will hit 45 million by 2030, up from 26.9 million in 2021 (EDC). What platforms will they want to build on?
Did Kubernetes solve all your problems? Did it create new ones?
It seems there’s always an XKCD relevant to our conversation. Today, it’s How standards proliferate.
Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters.
When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline.
At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging.
Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown.
It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS.
The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more.
Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters.
When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline.
At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging.
Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown.
It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS.
The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more.
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Maxwell, a solution architect at xMatters, took a winding road to get to where he is. After a computer engineering education, he held jobs as field support engineer, product manager, SRE, and finally his current role as a solutions architect, where he serves as something of an SRE for SREs, helping them solve incident management problems with the help of xMatters.
When he moved to the SRE role, Maxwell wanted to get back to doing technical work. It was a lateral move within his company, which was migrating an on-prem solution into the cloud. It’s a journey that plenty of companies are making now: breaking an application into microservices, running processes in containers, and using Kubernetes to orchestrate the whole thing. Non-production environments would go down and waste SRE time, making it harder to address problems in the production pipeline.
At the heart of their issues was the incident response process. They had several bottlenecks that prevented them from delivering value to their customers quickly. Incidents would send emails to the relevant engineers, sometimes 20 on a single email, which made it easy for any one engineer to ignore the problem—someone else has got this. They had a bad silo problem, where escalating to the right person across groups became an issue of its own. And of course, most of this was manual. Their MTTR—mean time to resolve—was lagging.
Maxwell moved over to xMatters because they managed to solve these problems through clever automation. Their product automates the scheduling and notification process so that the right person knows about the incident as soon as possible. At the core of this process was a different MTTR—mean time to respond. Once an engineer started working to resolve a problem, it was all down to runbooks and skill. But the lag between the initial incident and that start was the real slowdown.
It’s not just the response from the first SRE on call. It’s the other escalations down the line—to data engineers, for example—that can eat away time. They’ve worked hard to make escalation configuration easy. It not only handles who's responsible for specific services and metrics, but who’s in the escalation chain from there. When the incident hits, the notifications go out through a series of configured channels; maybe it tries a chat program first, then email, then SMS.
The on-call process is often a source of dread, but automating the escalation process can take some of the sting out of it. Check out the episode to learn more.
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
You can learn more about Roll, which describes itself as blockchain infrastructure for social money, here.
If you want to follow them on social, check out @tryrollhq as well as their personal socials: @bradley_miles_ and @sidkal.
If you are interested in this kind of tech, check out previous conversations on Web3 and our chat with Chris Dixon on blockchain.
Our lifeboat badge winner of the week is Notnooop, who explained how you can :Make An Emoji Enabling App