The Swyx Mixtape

Code Story: https://codestory.co/podcast/bonus-guillermo-rauch-vercel-next-js/ (10mins in)Podrocket: https://podrocket.logrocket.com/vercel (57mins in)

Listen to The Bikeshed (24mins in) https://www.bikeshed.fm/313TranscriptSo we had a bug that occurred in the application where something was supposed to have happened. And then there was an email that needed to go out to tell the user that this thing had happened. And the bug popped up within AppSignal and said something was nil that shouldn't have been nil.Particularly, we're using a gem called Time For a Boolean, which is by Caleb Hearth. And he's a former thoughtboter and maintains this wonderful gem that instead of having a Boolean for like, is this thing approved, or is it paid? Or is it processed? You use a timestamp. And then this gem gives you nice Boolean-like methods on top of that timestamp. Because it turns out, very often just having the Boolean of like, this was paid, it turns out you really want to know when it was paid. That would be a really useful piece of information. And so, while you're still in Postgres land, it's nice to be able to reach for this and have the affordances of the Boolean-like interface but also have the timestamp where available.So anyway, the email was trying to process but that timestamp...let's pretend that it was paid as the one that matters here so paid at was nil, which was very concerning. Because this was the email that's like, hey, that thing was processed. Or let's say it was processed, actually, because that's closer to what it was. Hey, this thing was processed, and here's an email notification to tell you that. But the process timestamp was nil. I was like, oh no. Oh no. And so when I saw this pop up, I was like, this is very bad. Everything is very bad. Oh goodness.Turns out what had happened was...because I very quickly chased after this, looked in the background job queue, looked in Sidekiq's UI, and the job was gone. So it had been processed. I was like, wait a minute, how? How did this fix itself? Like, that's not the kind of bug that resolves itself, except, in this case, it was. This was an interaction that I'd run into many times before. Sidekiq was immediately processing the job. But the job was being enqueued from within the context of a database transaction. And the database transaction had not been committed yet. But Sidekiq was already off to the races trying to process.So the record that was being worked on, the database record, had local changes within the context of that transaction, but that hadn't been committed. Sidekiq then reads that record from the database, but it's now out of sync because that tiny bit of Sidekiq is apparently very fast off to the races immediately. And so there's just this tiny little bit of time that can occur. And this is also a fun one where this isn't going to happen every time. It's only going to happen sometimes. Like, if the queue had a couple of other things in it, Sidekiq probably would have not gotten to this until the database transaction had fully closed.So the failure mode here is super annoying. But the solution is pretty easy. You just have to make sure that you enqueue outside of the database transaction. But I'm going to be honest, that's difficult to always do right.STEPH: That's a gnarly bug or something to investigate that I don't think I have run into before. Could you talk a little bit more about enqueueing the job outside the database transaction?CHRIS: Sure. And I think I've talked about this on a previous episode a while back because I have run into this one a few times. But I think it is sufficiently rare; like, you need almost a perfect storm because the database transaction is going to close very quickly. Sidekiq needs to be all that much more speedy in picking up the job in order for this to happen.But basically, the idea is within some processing logic that we have in our system; we find a record, we do some work. And then we need to update that record to assign this timestamp or whatever it is. And then we also want to inform the user, so we're going to enqueue a job to send the email notification. But for all of the database work, we are wrapping it in a transaction because we want it to either succeed or fail atomically. So there are three different records that we need to update. We want all of them to be updated or none of them to be updated. So, therefore, we wrap it in a transaction.And the way we had written, this was to also enqueue the job from within the transaction. That wasn't something we were actively intentionally doing because those are different systems. It doesn't really mean anything. But we were still within the block of ApplicationRecord.transaction do. We're now inside of that block. We're doing all of the record updates. And then the last piece of work that we want to think about is enqueueing the job to send the email.The problem is if we're still within that database transaction if it's yet to be committed, then when Sidekiq picks up that job to run it, it will see the prior state of the world. And it's only if the Sidekiq job waits a little bit that then the database transaction will have been committed. The record is now updated and available to be read by Sidekiq in the correct updated state.And so there's this tiny little bit of inconsistency that can happen. It's basically because Sidekiq is going out to Redis, which is a distinct system. It doesn't have any knowledge of the database transaction at play. That's why I sometimes consider using a Postgres-backed background job system because then actually the job can be as part of the database transaction.STEPH: Cool. That's helpful. That makes a lot of sense the way you explained the whole you're actually enqueueing the job from inside that transaction. I'm curious, that prompts another question. In the case where you mentioned you're using a transaction because you want to make sure that if something fails to update so, everything gets updated together, in the event that something does fail to update because you were previously enqueueing that job from the transaction, does that mean that the update could have failed but that email would still have gone out?CHRIS: That does not. And the reason for that is because we're within dry-monad world. And so dry-monad will implicitly capture the ActiveRecord rollback, which I think is an exception that gets raised or somehow...But basically, if that database transaction fails for any reason and ends up getting rolled back, then dry-monads will not continue processing through the rest of the sequential operation. And so, therefore, even if we move the enqueuing of the email outside of the database transaction, the sequential nature of that processing and the dry-monad stuff that we have in play will handle that. And I think that would more generally be true because I think Rails raises an exception on rollback. Not certain there. But I know in our case, we're fine on that. And we have actually explicitly checked7 for that sort of thing.STEPH: So I meant a slightly different question because that makes sense to me everything that you just said where if it's outside of the transaction, then that sequential order won't fire because of that ActiveRecord migration error. But when you have the enqueuing inside of the transaction because then that's going to be inside of the sequential order, maybe before the rollback error gets raised. Does that make sense?CHRIS: Yes. I think what you're asking is basically like, do we make sure to not send the job if the rest of the stuff didn't succeed?STEPH: I'm just wondering from a transaction perspective, actually. If you have a...

Listen to the Lex Fridman podcast (1h 20mins in) https://www.youtube.com/watch?v=U5OD8MjYnOM

Listen to the Changelog: https://changelog.com/podcast/459 (15mins in)TranscriptYou said something interesting about the preciousness of our development environments… And I’m with you that we’ve commoditized the servers, but we definitely have not commoditized dev, because it’s so intricate, it’s so set up… Sometimes it’s like “There be dragons. Please don’t touch my laptop, because it works right now, but I’m not sure if it’s gonna work tomorrow.” I do hate that. I think it’s almost a different skillset, of maintaining that. There’s overlap between development and the maintenance of a development environment in terms of things that you need to learn… But it’s almost a different task altogether. So I don’t like that about it, but it’s still very true that our development environments are precious to us, and they’re tweaked, and configured, and customized, and all the things. So I’m sure there’s probably lots of resistance to this…[00:11:59.29] We talk about our setup - we have probably tens of thousands of lines of code, and very few dependencies in our stack, but GitHub is 14 years old, and there’s a million plus commits, and I’m sure the dependency list is very long… What kind of effort was this? Tell us the story of bringing it along.CORY WILKERSONIt is. These are all very, very true points. You know, the last thing I wanted to do was kind of be the vessel that went out to GitHub and said “I wanna change your development environment”, because these things are so precious. Like, I’m an engineer, too. I think my environment is very much precious. And here I was, kind of the face in GitHub of saying “Well, we think we have a better way. Come join us over here.”And I started off on this journey as a skeptic. I think I shared some of this, too… I didn’t think this would be a fruitful journey necessarily. I was just gonna go do my level best as an employee, see if I could make it happen, build moment etc. and see if I could find something out there. Now, on the other side of this journey, I feel like I’m completely on the other end now, where I’m just like “This is the future. This is the way that we will absolutely build software…”But going back to the core of the story, it was literally just me out there, calling on my friends to begin with, inside of GitHub. I’d been there for five years, and the first few years were just me tapping into relationships, saying “Hey, can you give this thing a shot? Can you try this out? I wanna get your feedback and feelings about where this is at.” And no one could yet use it on our core repository. We call it github/github - the organization is GitHub, the repository is GitHub. We didn’t have this thing standing up in a Codespace yet, but we had other repositories that were compatible with Codespaces.So I’d go out and ask favors of friends, and just be like “Can you try this out and give me some feedback?” And generally, the feedback I would get back was – first it was resistance, like “Why would I do this? It’s productivity lost; tax on productivity. I don’t trust HTTP. There’s gonna be lag”, that kind of feedback. But then people would try it and they’d come back and be like “Huh. That was maybe better than I thought.”At the same time, as I hacked in this space too, I was starting to get some of that “Well, there’s something here.” The big a-ha moment for me was connecting VS Code into my Codespace out in the cloud and still retaining that local development experience. So it felt to me like it was still very local. The magic is the synchronization that’s happening between the local environment and the cloud. It feels totally transparent.But that aside, it started with just a very small number of users. So we would go back to leadership in GitHub and talk about progress we were making… And the early days, the story was “I have five people that have responded positively to Codespaces.” So not much of a story, but starting to kind of make a little bit of progress. And then maybe it was ten people.Then, the next iteration on this was like “Well, let’s go find a team. Let’s get a full team on Codespaces. How can we get a single team - 6 to 8 people - committed to using Codespaces, and stick in this thing?” At this point we’d had this other effort running on the side to get github/github, the core github.com repository, compatible with Codespaces. And we’d gotten it to a point – we detail how we did this in the blog post - where performance was mostly acceptable. So now we could go shop this with a team that worked primarily on GitHub.com and see what their experience was. And we’re making progress there. So we’re ramping in – I think y’all have talked to Kyle Daigle in the past. Kyle was the leader of that effort that got this team spun up inside of Codespaces on GitHub core. And again, it was somewhat retentive. People were sticking, and going like “Wow, this is not what I thought. It’s better than maybe what I thought.”[00:15:59.11] But I think the real breakthrough moment came when we stopped calling this dogfooding. You hear this term all the time, dogfood… I think it actually originated – I looked up on Wikipedia; I think the term originated inside of Microsoft a number of years ago.ADAM STACOVIAKIs that right?CORY WILKERSONBut GitHubbers, my colleagues don’t respond well to that term. Dogfooding doesn’t inspire anyone to go do anything. Just like “Eat the dogfood? Who feels good about that?” And so what we did was we launched what we called the GitHub Computer Club, and I would love to dedicate a full episode on this. It’s a really interesting concept, and something I hope to bring out to the industry. But we asked people to join the GitHub Computer Club. And in doing so, they took this commitment or oath. I wrote up this script, “I do solemnly swear to never – no shadow compute, not desktop compute. I’ll ...

Watch on video: https://www.youtube.com/watch?v=mlsTlFW7BSoThe following is my conversation with Lee Robinson, Head of Developer Relations at Vercel which recently launched Next.js 12, the most popular framework in the most popular programming language in the world.The conversation can be broken into two parts. The first covering the new features in Next.js, primarily Next.js Middleware and Edge Handlers with zero Cold Starts thanks to Cloudflare Workers, the Next.js Live realtime collaboration feature, and how they are rewriting everything in Rust. The last third covers our respective views on Developer Relations, both doing the job and hiring for it.Along the way we touch on Cloudflare vs Vercel, Remix vs Next.js, Static export vs Dynamic rendering, Webpack vs SWC, OpenTelemetry and Observability, WASM and awesome people we know in the industry.Timestamps: [00:00:00] Cold Open [00:01:39] Next.js 12 [00:03:52] Next.js Middleware[00:06:08] Edge Functions[00:07:23] React Server Components[00:11:06] Netlify Edge Handlers[00:12:48] Cloudflare & Vercel[00:15:37] Self-hosting Next.js Middleware[00:17:36] Static vs Dynamic Tradeoffs[00:19:18] Remix vs Next.js[00:22:32] next export[00:25:13] Webpack 4 to 5[00:26:06] Next.js Live[00:30:50] Rust Rewrite[00:34:36] OpenTelemetry and Observability[00:37:14] Webpack vs swc and WASM[00:40:41] Vercel Conference Strategy[00:44:38] DevRel at Vercel[00:52:50] Vercel and Svelte[00:57:48] Dev Marketing and Content Mix

Watch: https://www.youtube.com/watch?v=ut1hZKeYkZU

Watch: https://www.youtube.com/watch?v=sqOgyNfHl1UIf— by RUDYARD KIPLINGIf you can keep your head when all about you       Are losing theirs and blaming it on you,   If you can trust yourself when all men doubt you,    But make allowance for their doubting too;   If you can wait and not be tired by waiting,    Or being lied about, don’t deal in lies,Or being hated, don’t give way to hating,    And yet don’t look too good, nor talk too wise:If you can dream—and not make dreams your master;       If you can think—and not make thoughts your aim;   If you can meet with Triumph and Disaster    And treat those two impostors just the same;   If you can bear to hear the truth you’ve spoken    Twisted by knaves to make a trap for fools,Or watch the things you gave your life to, broken,    And stoop and build ’em up with worn-out tools:If you can make one heap of all your winnings    And risk it on one turn of pitch-and-toss,And lose, and start again at your beginnings    And never breathe a word about your loss;If you can force your heart and nerve and sinew    To serve your turn long after they are gone,   And so hold on when there is nothing in you    Except the Will which says to them: ‘Hold on!’If you can talk with crowds and keep your virtue,       Or walk with Kings—nor lose the common touch,If neither foes nor loving friends can hurt you,    If all men count with you, but none too much;If you can fill the unforgiving minute    With sixty seconds’ worth of distance run,   Yours is the Earth and everything that’s in it,       And—which is more—you’ll be a Man, my son!

Full podcast: https://tim.blog/2015/12/14/derek-sivers-on-developing-confidence-finding-happiness-and-saying-no-to-millions/ (1h30min in)Transcript: https://tim.blog/wp-content/uploads/2018/08/125-derek-sivers.pdf (page 34 on)So, I’ve got to tell you, so we haven’t really talked about this yet,but this is so up your alley, up your listeners’ alley, people who areinto books will appreciate this. So, a lot of my friends – actually, Idon’t think any of my friends are as into reading as I am. Okay, acouple are, but most aren’t.And so, whenever I tell them about some amazing book I’ve read,the gist I get from my friends is, just tell me what to do.Tim Ferriss: Give me the index card, yeah.Derek Sivers: It’s like, yeah, like they don’t wanna read the book. So, my friendJeff, he’s a smart guy, he’s a lawyer, he’s smart. But, he just looksat me with these tired eyes, and is just like, I’m not gonna read thebook, dude. You can stop pushing it on me, it’s never gonnahappen. He said, just tell me what to do, he said, I trust you. I likeyou, you know me, so tell me what to do.And, I realized that, if you trust the source, you don’t need thearguments. That so much of a book is arguing its point, but often,you don’t need the argument. If you trust the source, you can justget the point. So, after reading, taking detailed notes on 220 books,on my site, I realized that distilling wisdom into directives is sovaluable, but it’s so rarely done.In fact, the only time I can think of that it was done was MichaelPollan, with his three books in a row, about food, each one gettingshorter and shorter. I think the first one was, was it Omnivore’sDilemma?Tim Ferriss: Omnivore’s Dilemma. Yeah.Which was big, so I know you’re the kind of guy that would –Tim Ferriss: It’s a great book, but also, I mean, there are, like 70 pages on cornproduction in the US, and most people just drop out. Even I waslike, God, my eyes are glazing over here. But, I know there’s somegreat stuff coming, so I’ll just slog through it. But yes, a very greatbook, but a very big book.Derek Sivers: And then, he did another one a year later, that basically took thebest stuff from Omnivore’s Dilemma, and made it into a shorter,kinda more pop market kinda 2 to 300-page book. I forget thename of that one. And –Tim Ferriss: Could it have been In Defense of Food, maybe?Derek Sivers: Yes, that sounds right, thank you.So, even that one, I remember someone telling me I should read it,and I remember looking at it and going, I don’t know if I wannaread 300 pages about food. But then, about a year later, he put outa teeny, tiny, little book called Food Rules. I think that’s what it’scalled. And, it’s like, you basically can read the whole thing whilejust standing in the bookstore. It’s, he took the energy and theeffort to compress everything he’s learned into very succinctdirectives. And, that’s what it is. Sentences that tell you what to do.Do this, do that.Or, don’t do that. If your grandmother wouldn’t recognize it asfood, don’t eat it. And, his tagline for that book, the popular phrasewas, “Eat food, mostly plants, not too much.”Tim Ferriss: Right.Derek Sivers: And, I so admired that. I got inspired by the effort it takes to distillthe blah, blah, blah, blah blah, down into the specific sentences forthe people that just aren’t going to read that 900-page book, right?Probably all of that same information is in the 900-page book, butwe have to be honest for a minute and admit that not everyone isgoing to read the 900-page book. So, as I’m reading these 300-page books, 220 of them, very often there’ll be this, like, brilliant,amazing, important point on, like, page 290, and I feel almost alittle sad that almost nobody’s gonna read that. I wish that theselittle, tiny points were extracted, without all the surroundingargument.So, especially – okay, I’ll admit, this was also sparked by the ideaof when I had a kid, and I thought, I might not be alive when he’smy age, or even when he’s 19, I might die before he gets older.How can I compress everything that I’ve learned, that I think heshould know, into a real, succinct format, that he will definitelyread? And, of course, then I thought, other people will read, too.So, I got onto this idea, of the Do This Project.Which is, instead of talking around a subject, just giving directives,saying, do this, do that, don’t do this, don’t do that. Which is kindafunny, because it feels very presumptuous, right? Like, who am Ito tell others what to do? But then, I think, well, who am I not to?Right, it’s useful, so get over myself. Kinda like you asked aboutme onstage when I was 18, what was the biggest lesson learned?Like, this isn’t about me, people aren’t here about me, they’re herefor their own gain.Oh, you asked about my advice to TED speakers. That’s my mainadvice to TED speakers. It’s like, people aren’t here to see you, oryour life story. People come to TED, or watch TED videos, tolearn something. So, just speak only about what is surprising, andskip everything else.where can people find the directives?Derek Sivers: Only in this podcast. No, it’s true. I haven’t done anything with itpublicly. At first, I thought I was gonna make this into a big,keynote speech I was doing at a conference. The WorldDomination Summit Conference, in Portland.I spent four months of fulltime work, from 7:00AM to midnight,for four – seven days a week, for four months in a row, justrereading all 220 book notes, extracting, or trying to turn all of thisadvice or this knowledge, this wisdom, trying to turn it intodirectives. Because a lot of it, almost never is in the directiveformat already. People talk around a subject, they talk aboutfindings and research. But, it takes some real effort, kind of likethe old philosophers, the – you’ve read the stoicism book? TheGuide to The Good Life?Tim Ferriss: Yes, I have. I have that up on my living room wall, as well.Derek Sivers: And, in that book, right in the intro, he says, if you were to ask anykind of modern person who calls themselves a philosopher, whatshould I do with my life?He said, sit down and get comfortable, because they will tell you,well, it depends on what you mean by what, and it depends whatyou mean by do, and really, it depends what you mean by life. Or, really, maybe it depends on what you mean by my life. So, peopletalk around the point a lot, but back in 600 BC, if you would’veasked one of these philosophers, what should I do with my life,they would sit down and tell you exactly what to do with your life.Do this, don’t do that, pursue this, don’t pursue that.So, I was really inspired by that intro too. So, the idea was, now,how can I go back, through all of these amazing books I’ve read,and compress them into specific directives? So, it took me fourmonths of work to come up with the following like, 18 sentences.Do you wanna hear them?Tim Ferriss: I do wanna hear them. I’m super-excited about this.Derek Sivers: So, this was going to be a 35-minute long keynote speech, and itturned out to be a horrible, 35-minute long talk. But, it’sentertaining for about three minutes. So, here’s the three-minuteversion. Okay, first, I had fun categorizing them. So, this is thecategory called “How to Be Useful to Others.” Ready?Tim Ferriss: I’m ready.Derek S...

Watch Naval on the JRE: https://www.youtube.com/watch?v=3qHkcs3kG44Tiago's quote: https://twitter.com/swyx/status/1410739112261214209

Read: https://blog.coinbase.com/announcing-coinbase-fact-check-decentralizing-truth-in-the-age-of-misinformation-757d2392d61aWatch: https://www.youtube.com/watch?v=eoZG89pDzzY (33mins in)Coinbase Fact check: https://blog.coinbase.com/factcheck/homeAnnouncing Coinbase Fact Check: Decentralizing truth in the age of misinformationEvery tech company should go direct to their audience, and become a media company.Whether traditional, social, or corporate media, we’re all just typing words on the internet.As Coinbase and the cryptoeconomy grow, we’ve seen more interest from the media, government, and the general public in our business and in crypto overall. This increased awareness has been great. Unfortunately, we also see misinformation published frequently as well, whether in traditional media, social media, or by public figures.This doesn’t always come from negative intentions. Our business, and crypto, can be difficult to understand, and often people are rushed to post first impressions online, making mistakes in the process. At other times, misinformation comes from people pushing their own agenda, or from those who have a conflict of interest.This is not unique to our business or industry of course. Every company experiences this to some degree, and it can be incredibly frustrating.So how should companies respond to misinformation?The choicesOption 1: turn the other cheekThe most common advice you’ll hear from PR firms and boards is to work behind the scenes to correct misinformation, but never engage in public fights. This might mean working with journalists to fact check a story, or to send internal emails to employees when misinformation is spreading on social media.Pejoratively, one could call this the pacifist’s approach. Yes, you’re taking regular beatings from a bully, but don’t fight back. Just focus on building a great product and helping the industry grow, and everything will work out in the long run.On the surface, this approach makes a lot of sense. Why pick a fight with someone who buys ink by the barrel, or with internet trolls who have too much time on their hands. After all, most of your customers probably never see the misinformation, and it can just draw more attention to respond publicly. Companies should never lose focus on the primary objective: building great products.On the other hand, it can be very damaging to a company’s brand to let misinformation spread unchecked, and working through third parties to share your side of the story rarely is effective. You might, at best, get a short quote in a narrative that someone else controls.If you look at companies like Facebook, they suffered enormous brand damage when traditional media coverage of them went south (although their business metrics seem to be unaffected). Accurate or not, traditional media has a conflict of interest when covering this topic, as they are in the process of being disrupted by tech. Yet to a large degree, Facebook turned the other cheek and didn’t respond or point out this conflict.Option 2: fightThe opposite end of the spectrum is to actively fight back. Any time someone posts false information about your company, it’s war. Come out swinging and never back down.This is a legitimate strategy that some companies have engaged in. Amazon’s recent responses to Andrew Yang or Elizabeth Warren are in this direction, along with FedEx’s CEO aggressively pushing back on a story they found inaccurate. And Peter Thiel’s takedown of Gawker may be the canonical example.The advantage of this approach is that you are standing up for yourself. The downside is that warfare can be time-consuming, taking your energy away from building. You need to be prepared to go all the way, and it needs to be in line with your brand. There is an old quote which says “never wrestle with a pig, you both get dirty and the pig likes it”.Option 3: publish the truthI believe there is a reasonable middle ground between these first two options, which is to simply publish the truth, in a thoughtful and respectful way, and build a direct relationship with your audience. Companies no longer need to go through biased intermediaries to communicate with their customers and stakeholders. They often have equal or greater reach via their blog, podcast, YouTube channel, or through their own product. In many cases, the only organization that knows what really happened is the company itself.Tesla is a great example of this middle ground approach, in their Most Peculiar Test Drive blog post. Other examples include Apple debunking the claims of a cover piece or our own post correcting facts in the New York Times. These examples take a reasonable middle ground of trying to just share the facts.This “fact check” approach is not about antagonizing or embarrassing others, but simply sharing what happened through your own channels. It also means sharing the good along with the bad, with radical transparency. Companies are often reticent to share negative facts, in their inherent desire to look good, and therefore also have a conflict. To become a source of truth, companies will increasingly need to be comfortable sharing facts which paint them in a negative light as well. There is nothing like sharing mistakes, to build trust.Every company is becoming a media companyTraditional media has been a powerful source of accountability for centuries. In more recent years, social media has as well, as any individual can share what is actually happening. The power of both these institutions is staggering, and they serve an important function. But traditional media and social media each come with a healthy dose of misinformation, and I believe people’s trust in these institutions has been in decline in recent years.Companies are now emerging as a third source of truth, and can create accountability when misinformation is spread via other channels.Amazon and Netflix built their own studios, Hubspot acquired the Hustle, a16z is