Matt Klein

Matt Klein

@mattklein123.dev

CTO @bitdrift.io. Software engineer and creator of Envoy Proxy.

1.7K followers96 following154 posts

Matt Klein reposted

πŸŽ™οΈ It's our favorite time of week, it's new episode release day! Hear how @crawshaw.io started Tailscale, why he made his way to the US, what he's up to now as CEO of exe.dev, plus the unexpected result of a recent HP printer purchase 😱 Full episode here: bitdrift.io/podcast/beyo...

bitdrift.iobeyond the noise - David Crawshaw: From Tailscale to exe.dev, and Why AI Agents Need Their Own ComputersDavid Crawshaw joins Matt Klein to discuss founding Tailscale, building exe.dev, and why AI agents need real computers.

Matt Klein reposted

New episode is live with one of my role models, @kelseyhightower.com. This is a great chat about the impact of AI on our industry. Check it out!

bitdrift@bitdrift.io

πŸŽ™οΈNew episode of Beyond the Noise! Matt Klein brings on Kelsey Hightower. Kelsey talks through what AI is doing to developer salaries, what he tells junior engineers wondering if they picked the wrong field, and why open source is the only realistic check on what's being built today: buff.ly/VUD6ktX

Matt Klein reposted

If you've built an Android app in the last decade, you've almost certainly shipped Jesse Wilson's code to your users. πŸŽ™οΈOur newest Beyond the Noise episode with @swank.ca just dropped – tracing the open-source decisions that shaped modern Android! 🎧 Listen today:

bitdrift.iobeyond the noise - Jesse Wilson: From SourceForge to OkHttp, and Why WebAssembly Beats the AI HypeMatt Klein sits down with Jesse Wilson, one of the most influential engineers in the mobile world, to trace the open source dominoes that shaped modern Androidβ€”from pre-GitHub SourceForge projects to…

Yay new @bitdrift.io Beyond the Noise episode with @p-y.wtf. You will not want to miss this one!

bitdrift@bitdrift.io

πŸŽ™οΈ The newest episode of Beyond the Noise just dropped! Listen to @mattklein123.dev and @p-y.wtf chat about his journey from open source to Block, and why AI introducing so many new bugs may actually be a good thing for curious engineers πŸͺ² bitdrift.io/podcast/beyo...

Today @bitdrift.io we are super duper excited to launch when of the coolest features we have ever released: workflow debugging. Our workflows (finite state machines sent dynamically to mobile devices) are extremely powerful but also hard to debug. blog.bitdrift.io/post/announc...

blog.bitdrift.ioAnnouncing workflow debugging - bitdrift Blogbitdrift Capture just got even more powerful: as of today, we’ve added workflow debugging! As we have worked with more and more customers, it has become extremely clear that one of the biggest side-ef...

Do they not match because there is no data or because the match conditions are wrong? Our live debugging experience removes that problem entirely. Check out the embedded video in the blog! πŸš€

Guess what? I started a podcast! I'm not going to lie: I like being a podcast host. πŸ˜‚ Check out the first two episodes on your platform of choice and there is a lot more to come!

bitdrift@bitdrift.io

It’s here! πŸŽ™οΈ Beyond the Noise: Signals, Stories & Spicy Takes - our new podcast hosted by Matt Klein. Get the hottest takes from the people building the future of mobile. 1⃣ Lyft & bitdrift origins 2⃣ Instacart & the future of retail tech Listen now:

Not going to lie that I'm lazy and much less inclined to go to a protest than I was in my 20s, but the "I hate America" BS is getting me off my ass and then some. See you out there tomorrow!

MeidasTouch@meidastouch.com

SCOOP: No Kings organizers tell MeidasTouch that RSVPs for the "No Kings" rallies have more than doubled since Mike Johnson and Republicans started attacking them

View full thread

It is extremely frustrating to deploy a workflow only to have no matches due to a typo or not fully understanding the shape of logs that are actually generated on the device.

Enter the workflow debugger. This is the culmination of a ton of work, tying together our various systems into a unified real-time debugging experience driven directly from the browser. Just watch the video. Your 🧠 will explode. Shipping shortly. πŸš€

is the difficulty of understanding whether workflows (the finite state machines we send to clients) are actually going to match the expected event sequence once deployed.

Starting today, Capture has you covered for ALL of your mobile obs needs, from the 0.01% of crashing sessions, to the 99.99% of sessions that are crash free but not converting due to app bugs, performance issues, and who knows what else.

If you are struggling to solve your non-crashing app issues with a legacy solution that was never built to scale to 100% of sessions, just the 0.01% of crashing sessions, Capture is a one-stop shop and has got you covered. Let's talk! πŸš€

Yet, up until recently, crash reporting *was* the lingua franca of mobile obs, even though in mature apps over 99.99% of sessions are crash free! This is because, frankly, mobile obs is ridiculously hard, and without local storage and real-time control I would argue impossible to do well.

Capture's lack of built-in crash reporting has meant that though customers love the product, it requires an additional solution to provide crash reporting capabilities. And let's be real, no one likes multiple tools.

Today we are thrilled to launch built-in app crash reporting capabilities inside @bitdriftio Capture! πŸš€ You can read more about it in the linked blog, but a short 🧡 on why this launch makes existing mobile observability tools obsolete. 🌢️ blog.bitdrift.io/post/announc...

blog.bitdrift.ioAnnouncing crash reporting: why have breadcrumbs when you can have the whole loaf? - bitdrift BlogToday we are immensely excited to announce the biggest addition to bitdrift Capture in the history of the product: first party crash reporting! At the risk of extreme hyperbole, we believe that the ad...

When we launched Capture 1.5 years ago, we fundamentally changed mobile observability by coupling local storage with real-time control. As we like to say, get 1000x the data when you need it and none when you don't!

This is an important reminder that the red/blue state maps that everyone likes to show are a ridiculous simplification of the people that live all throughout the US. Boise is a fantastic city. Come and visit!

This post is unavailable.

Do you know what this teaser is? It's first party crash reporting support in @bitdrift.io Capture. Do you know what that means? Legacy mobile observability tools are about to be obsolete. So, so excited to ship this. Watch this space! πŸš€

All too often beautiful UI is an afterthought in infrastructure tooling. This is a miscalculation as users of these tools are drawn to exceptional design just as much as users of consumer products.

This video shows some recent work on @bitdrift.io Capture to implement an adaptive sidebar which removes clutter when viewing data and when working on small screens. Observability tools can be both transformational AND eye catching. πŸ˜‰

Great post on Android internals. Check it out!

bitdrift@bitdrift.io

JankStats + bitdrift = 😍 Read our new post on the challenges of monitoring app responsiveness and how we tackled them by integrating JankStats: blog.bitdrift.io/post/jank-st...

View full thread

As a result, "tail sampling" is still expensive, and the total trace duration is usually short. None of these downsides apply with @bitdrift.io Capture's real-time control and local storage. Sessions can be hours or days long, and the capture decision is based on dynamic state machine execution.

With this solution you will be able to capture sessions and performance tracing based on arbitrary matching criteria, and update that criteria in real-time, getting you the traces you need to iteratively debug performance issues all without a single code deploy. Can't wait to ship this! πŸš€

Traditional tracing requires some type of sampling to control volume and cost. "Head sampling" is the simplest and just decides at the beginning of the trace whether to capture it or not. Thus sampling does not have any trace specific context.

"Tail sampling" is more sophisticated and decides at the end of the trace whether to capture (based on observing an error or some other indicator). Without real-time control and local storage, this requires sending *all* data to some intermediate buffer where it can be held to make a decision.

I can't overstate how ridiculously cool and powerful this is. You do not need to know what durations you want to measure ahead of time. You can simply log, and then figure this out after the fact.