Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book


Transcript #367: A New Cloud Computing Paradigm at Python Bytes

Return to episode page view on github
Recorded on Tuesday, Jan 16, 2024.

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.

00:05 This is episode 367, recorded January 16, 2024, and I am Brian Okken.

00:11 And I'm Michael Kennedy.

00:12 And I guess we do have a sponsor today, so that's awesome.

00:18 But Michael, do you want to tell us why you're not?

00:23 Yeah, for people who are listening, maybe they hear a slightly different setup for me, for people who might watch the video, well, that right there in the background is lovely and very icy Portland, Oregon.

00:36 And so I'll go ahead and put this on the screen and people can check out if they feel like they can check out the YouTube stream at like one minute, 19 seconds.

00:47 This is the entrance to my house, Brian, and it looks like an apocalypse, just every I would say every block or so.

00:55 There's like a hundred foot tree that's fallen somewhere and it's just taken out the power in so many ways.

01:01 It's like it was now it was 13 now.

01:04 It's 18 degrees Fahrenheit.

01:06 So negative 9 something like that Celsius, no power for five days, not a place for podcasting.

01:11 So I'm hanging out here downtown in a hotel with the family until the power comes back on, hopefully today, fingers crossed.

01:19 Well, hopefully, yeah, hopefully there's actually quite a few people in Portland without power and did experience power outages and pipes bursting and things like that.

01:31 And, you know, for people that are in parts of the country where they get like way colder than us, it might seem like we're just being wusses.

01:39 But what we get here is often very heavy rain, heavy snow or freezing rain.

01:48 And the freezing rain just weighs down trees and bricks, power lines and stuff like that.

01:53 Absolutely.

01:53 And this had up to 100 mile an hour winds with these really old trees.

01:56 And also just the city is not really built for it.

01:59 We don't get it enough that they have infrastructures for it.

02:01 So it's like, oh, it's snowed three inches.

02:03 So just good luck with that.

02:05 We're not going to do anything right.

02:07 No salt, no gravel.

02:08 Just hope that works out.

02:09 So anyway, it's been all right.

02:12 But yeah, different setup, Brian.

02:13 So thanks everyone for the understanding.

02:16 Indeed.

02:17 And also I want to say thanks to Bright Data.

02:21 We'll talk more about them for sponsoring the show.

02:24 But let's talk about something contrarian, I guess you would say, Brian.

02:30 Okay.

02:30 You know, many people I'm sure have heard of 37 Signals, right?

02:35 David Hennemeyer Hansen, he's the guy who created Ruby on Rails, most notably.

02:40 But there's also Basecamp and Heymail and all that kind of stuff, right?

02:44 Yeah.

02:45 So needless to say, they run a ton of SaaS products in the cloud.

02:49 And I came across what I guess was more or less some kind of like conclusion to a bunch of conversations and stuff they've been working on.

02:59 And so I'll work my way backwards just a little bit.

03:01 But it's pretty fascinating.

03:02 And the headline on the post is, "We have left the cloud." Brian, I thought we were all told to go to the cloud.

03:10 I mean, we saw the picture of what happens when the clouds get angry.

03:13 So I understand why you might leave the clouds.

03:15 But more seriously, like clouds are supposed to save us.

03:18 They save us money.

03:19 They give us agility, et cetera, et cetera, right?

03:22 Yeah.

03:23 So hence the contrarian aspect, right?

03:25 Yeah.

03:26 Like I guess it's not like 37 Signals is the same sort of place as like a lot of startups.

03:32 But, you know.

03:33 That's true.

03:34 If you were in, they do make that point.

03:36 Like if you are an early stage startup where the costs are low, by all means cloud it up.

03:42 But as I guess one of the big lessons here is the more that you get like the cloud hooks in the sort of abstract sense into your app, the more it might set you up for a tough time as you get bigger.

03:56 Right?

03:56 So let me get through this and we can talk a bit more about that.

03:59 So let's, so they say we stand to save over $7 million in five years from our cloud exit.

04:09 And so why do they not just say, well, that's 1.2 or 1.

04:13 Whatever it is, 1.1 million per year because of our cloud exit.

04:17 Because what they did is they went and they bought.

04:20 So when they said they left the cloud, they didn't mean just like we're not using Kubernetes or we're not using Lambdas and serverless.

04:28 Like they are, they bought physical hardware.

04:32 Okay?

04:33 So they've got these big pallets.

04:35 And what they did is they bought this Dell 20 Dell R7625 servers, which don't mean a lot to me, maybe do to some people, but it basically takes up like two server racks.

04:49 And that means 4,000 CPUs, 7.7 terabytes of RAM and almost a half a petabyte of high-speed SSD storage.

05:00 And that costs them $600,000 to buy that, which is a lot of money.

05:06 However, they were paying like 1.2 million a year in cloud prices and cloud to AWS basically.

05:16 And so after six months it's paid for in the five years part is they expect this hardware to last them five years.

05:22 And apparently it's super, super fast.

05:24 So it's pretty interesting.

05:27 And I would really recommend people go through and read this, what some of the values were.

05:33 And basically what they did is they said, we're going to buy like a really big server.

05:37 I know it's a bunch of kind of CPUs and stuff, but they kind of clustered into like one compute cluster.

05:44 And then they came up with this thing called, it's kind of like Kubernetes called Camel, which would work for Python.

05:50 But I think originally they're deploying Rails apps on it and basically gives you zero downtime slices of this giant server.

05:58 And the reason this really fascinates me is this whole philosophy here.

06:04 It's also not just, hey, they're leaving the cloud because many people are running to the cloud.

06:11 But it's also they're getting a really huge server, like one huge server rather than a whole bunch of small distributed servers, which also was like a little bit the way that the cloud was initially sold, right?

06:24 We'll get commodity hardware.

06:26 You buy a bunch of little small slices all over the place.

06:29 You can buy more small slices with auto scaling if you need.

06:32 And instead they're like, no, this.

06:34 And sort of along those same lines is I a little while ago interviewed Mark Russinovich, the CTO of Azure at Microsoft.

06:42 Super cool guy, really, really smart, but also CTO of Azure.

06:46 And he talked about how they start out with a bunch of small machines as well, and they're just getting bigger and bigger ones and slicing them up for tenants to be using them.

06:56 So I think this is also a really interesting trend that we're going to see more of is like more big machines rather than a bunch of small machines that then maybe you slice up with Docker or Kubernetes or other things.

07:09 And Brian, we've hardly even talked about this yet.

07:12 But that has changed the way I got to type holding the mic in the wrong hand here for typing.

07:21 That's changed the way that I'm running a lot of our infrastructure.

07:23 So I've been thinking about this for a while and reading this stuff.

07:26 I thought I'd make the first topic of our show.

07:29 But also I had eight servers for all the Talk Python and Python bytes infrastructure, you know, some database server stuff.

07:38 One that ran Python bytes, a bunch of services, a bunch of small machines, right?

07:42 And I'm like, you know, why am I messing with all these small machines?

07:44 So I ended up consolidating like last week all of that into one big, big server, just running a bunch of multi-tier Docker setups over there.

07:55 And it's glorious, right?

07:56 One machine runs great.

07:58 There's a single command I type to upgrade like 13 different web apps all at once.

08:04 That means upgrade their server infrastructure, upgrade their potentially to ship their new dependencies to rebuild them, all of that kind of stuff.

08:12 One command.

08:13 Interesting.

08:14 So yeah, it's really interesting.

08:16 It's really different.

08:17 It let me like quickly and easily throw in some more things.

08:20 And also I think it's better for security, right?

08:22 Like I had like little FastAPI apps that were just like little utility things running that I didn't pay this much attention to as I did the other apps.

08:32 And so, you know, they just didn't, they didn't get their dependencies updated as frequently and their Python versions revved as frequently.

08:40 And if something happened to them, right, it's on technically on the same VM, right?

08:44 That's an issue.

08:45 But now they're all locked up behind like a Docker container.

08:48 So it's a little more isolation as well.

08:50 Anyway, it's this whole, I encourage people to read through.

08:53 I put a bunch of different parts of this story in for the 37 signals we've left the cloud.

09:00 It's worth reading.

09:01 I'll just go through really quick the five values and then this is kind of a long segment.

09:05 So I'll move us on.

09:06 But here are the five values guiding our cloud exit.

09:11 We value independence above all else and being trapped in Amazon cloud is not great.

09:17 We serve the Internet.

09:19 This business owes its entire existence to the societal and economic aberration that is the Internet in a positive way.

09:26 And we don't want to just be locked up behind a few hyperscalers.

09:30 We want to be kind of just on the Internet on our own terms.

09:33 Spend money wisely, even if you have lots of money, you know, they're getting better value for money.

09:40 Leading the way, the cloud has been sold as the answer to SaaS companies weren't so sure and they seek adventure.

09:46 And you bet they do.

09:47 So anyway, it's not leaving data centers.

09:50 They have that in a managed data center.

09:51 They just have it on hardware that they own.

09:53 So anyway, what do you think about all this?

09:56 So a lot of this is, I think it's interesting that it affects you even like that you, but you're not okay.

10:04 When you said you put them all on one machine, you're not, it's you don't have like a server in your basement or something.

10:10 No, no.

10:11 So what I did is I instead of having a bunch of small VMs at DigitalOcean, I bought one big VM.

10:16 Okay.

10:16 What I have right now is like eight gigs, four CPUs, but I'm pretty sure I'm going to switch to like 16 gigs and eight CPUs.

10:23 And even that would be cheaper than what I was doing before.

10:26 And it's still, and the other thing that's interesting, we're in danger of going super long in this, but because all those different apps are sharing, let's say the final destination of eight CPUs, their spikes in performance are not at the same time.

10:40 Like what makes talk Python or Python bytes spike in load is not the same that what makes the courses spike on load.

10:47 Like a new course release or like Black Friday or something like that is very unlikely to intersect with when a podcast is released because I'm busy doing one or the other.

10:56 Right.

10:56 And so they basically has access to all eight cores instead of that one gets two cores, that one gets one core.

11:03 And even though they're sharing, like basically in aggregate, it's the same number because the spikes don't line up, they get more capacity for whatever they're doing.

11:11 It's pretty interesting.

11:12 Yeah.

11:13 Okay.

11:13 It is interesting.

11:15 Back to you.

11:16 Well, let's completely go to a short topic.

11:20 And I'd like to talk about little tiny scripts, or maybe big scripts, but single file applications.

11:28 So single file scripts.

11:30 So I wanted to talk about PEP 723.

11:33 And that is inline script metadata.

11:36 And one of the things that we've noticed recently in this, this is authored, it's interesting author.

11:42 The author is Ofek Lev, I think that's how you say his name.

11:46 He's the dude from Hatch.

11:48 So Hatch is, I guess, in packaging.

11:52 So this is around packaging.

11:53 And the idea is that you've got a script has depend, might have dependencies also, and it also might depend on Python.

12:02 And we can't really tell Python currently that a script needs a dependency or a particular version of Python.

12:10 So this is an attempt to kind of fix that.

12:13 And there's some motivation and stuff at the top that I like, you know, kind of skimmed through a little bit.

12:19 No, I read it.

12:20 But the real, at the end is we're going to put stuff like pyproject.toml, but you can do it in a script.

12:29 And this isn't there yet.

12:31 But there's an example where you just sort of do a pound sign and then like a few slashes and then say script.

12:39 And then after that, you can put a little bit of like toml right in here as a comment.

12:45 And the idea is something like pip--

12:48 This is like the world's craziest docstring sort of thing, right?

12:53 Almost.

12:53 I don't understand.

12:54 So supposedly there's reasons behind this syntax.

12:58 It's the weirdest syntax I've ever seen.

13:00 But maybe it's just--

13:01 It's not quite shebang, but it's kind of shebang-ish.

13:03 Yeah.

13:05 But like in their example, they're saying, okay, well, you've got a little script that just requires, you know, and this is going to be common, I think, actually, requires requests and rich.

13:17 So because it's going to like grab something off the internet and it's going to print some stuff and wants to do it with color and whatever.

13:23 But how do you do that without packaging it?

13:26 And here's one way is to just tell Python that it needs these other things.

13:31 So there's a-- I don't really completely understand this.

13:36 Like what are the back end?

13:38 What's going to happen?

13:39 What is-- I think the different tools will treat this different.

13:43 Because my question is really where are these dependencies going to be installed at?

13:47 Is it-- like if I just say-- I guess it depends on the thing.

13:51 So if you're going to do-- if it hatch, for instance, or pipx might handle this.

13:56 So if I say pipx, you know, run this script and it finds this, it'll probably create a pipx virtual environment area.

14:03 And hatch will do the same thing in a different manner.

14:06 But behind the scenes, grab-- like create a little virtual environment.

14:10 This kind of-- it mostly seems like it's hiding virtual environment and dependency installs from users, but it's probably needed.

14:19 So anyway, what do you think of this?

14:21 I think it's interesting.

14:23 Similar to installed, as Liz is pointing out.

14:27 Sounds very similar to installed that we talked about not too long ago.

14:31 And I think it solves an interesting problem.

14:34 All of these do have that little bit of a bootstrap that has to happen, right?

14:39 For something-- for this to work, it's not built into Python, right?

14:44 And so you've got to have like one library installed that then you can use to run and kick off all the other runs.

14:51 But if you somehow make that happen or get your company to agree, like, we're all going to have this foundation and then it just runs, I think that's pretty excellent.

15:01 So yeah, very cool.

15:03 And I think Ofek is killing it, right?

15:05 He's being really creative and working a lot of different things.

15:09 And this is a PEP, right? So if this was built into Python, then all of a sudden, yeah, we can have it run.

15:17 So, okay, for some reason, I flew right over my head that it's a PEP and not just an extension to Hatch.

15:22 So yeah, this is going to be-- this could be super, super important.

15:28 And it was last updated in December.

15:30 It's accepted now.

15:32 I'm not sure how long it's been accepted, but it's around the packaging.

15:35 So PEPs with packaging are interesting because we don't really have to wait for-- once they're accepted, we don't really have to wait for a release of Python because things like PEP and Hatch and other things don't have the same release cadence as Python.

15:52 So this could be-- like there's a note here that says it's not going to be declared final until at least a couple of tools utilize it.

16:01 So far, there's no tools that utilize it, but their example is possibly PipRun and PipX.

16:08 And probably Hatch as well, considering who wrote it.

16:13 >> Yeah, I would imagine it might show up and might get support from Hatch as well.

16:17 >> Yeah.

16:18 >> Yeah, funny comments out there in the audience, you guys, about being Rust-inspired indeed.

16:23 Brian, you want to know what else is inspiring?

16:26 >> What?

16:27 >> Our sponsor, Bright Data.

16:29 >> Yeah.

16:30 >> Indeed.

16:31 So I just want to say thank you to Bright Data for supporting the show.

16:35 Check them out at pythonbytes.fm/brightdata.

16:39 And there's-- go ahead, yeah?

16:41 >> Do we want to put their stuff on the--?

16:43 >> We do, and somehow I did not quite-- we did quite do it.

16:47 There we go.

16:49 Awesome.

16:50 Yeah, so there's tons and tons of data out on the internet, unimaginable amounts of data, right?

16:56 And we're lucky to live in a time where so much of this is behind structured APIs, and you can go and access it with HTTPS or requests or whatever.

17:04 But the truth is that most of the data is not served up over clean APIs.

17:09 It's just sitting there on a web page as gnarly HTML.

17:13 Maybe it's even worse than that.

17:14 Maybe it's obscured behind some front-end framework like React, where when you actually look at the HTML, it just says, "Pull in the React app." Good luck with that.

17:23 And then something else happens somewhere along the way, right?

17:25 So getting access to that data can be hard.

17:28 What's the answer?

17:29 Well, web scraping, everyone says.

17:31 Yes, true.

17:33 But just like you wouldn't want to set up your production infrastructure in your home office, running web scraping jobs on a single computer, even in a data center, can lead to your program being potentially unreliable with data pinned where whatever source you're accessing thinks you're located, right?

17:51 Maybe there's different data if you're in the EU than if you're in Ohio, but your computer is in Ohio, so there you go.

17:57 Or it gets blocked because of rate limiting or other types of things like that, right?

18:01 So if you need to do professional web scraping, check out Bright Data.

18:05 They have an award-winning proxy network with millions of different places to access data from.

18:11 And powerful web scrapers, they have even ready-to-go datasets you can download.

18:17 So they've already curated these datasets, and you can just access them and get updates from them and not even do web scraping, which is awesome.

18:24 So they've got a whole marketplace for that.

18:26 And everyone knows, and we're probably going to come back to it some more, privacy-conscious stuff that I really care about, and they are both CCPA and GDPR compliant.

18:37 They have low-code solutions as well as Python programming models with async I/O and playwrights.

18:42 So if you have serious data needs and those websites that have the data don't offer an API, then you need to check out Bright Data.

18:48 Give them a try at pythonbytes.fm/brightdata, and please use that URL so you know that they heard from us.

18:55 Thank you to Bright Data for supporting the show.

18:57 Links in your podcast player show notes.

19:00 So pretty awesome.

19:02 All right.

19:03 Back to the next thing.

19:05 So this is super exciting, and it came -- I believe this was sent in by Balazs.

19:10 Let me check. Yeah, Balazs sent this over. Thank you, Balazs, for pointing this out.

19:14 So I've had Fedor Fitzner on Python before, and we've talked about FLET.

19:21 And FLET is basically Flutter but with a Python programming API, right?

19:27 Flutter is actually how we built the apps at Talk Python, right, for courses.

19:32 Super cool framework, but you're writing Dart, and Dart is good, but it's not Python, right?

19:39 And so it would be great to be able to write that kind of code.

19:42 Here's an example, by the way, Brian.

19:44 We talked about FastUI, and I said, "Oh, that reminds me of this sort of hierarchical code structure.

19:49 Reminds me of Flutter," right?

19:53 And so here's the same thing, the Flutter UI but in Python code instead of Dart.

19:58 I know the link for this code is in the show notes. You can check it out.

20:01 Right. So the big news is you can now build APKs for Android.

20:06 And for those of you who have not suffered the indignity of the app stores, the way you get something into the Google Play Store is you build what's called an APK, and then you send them that, they process it, and then that's what gets shipped out to run on the phones on Android.

20:22 So this means even though FLET built Flutter apps, you couldn't really deploy it.

20:27 You could kind of get the FLET app and then put your Python code on there, but that's not like your app.

20:32 That's like Jupyter or something like that kind of.

20:35 So this is awesome. This means that people can now build apps that go in the app store, at least for Android, with Flutter and FLET and Python in particular.

20:46 We'll see about iOS. It's on the roadmap. So super exciting.

20:50 Yeah.

20:52 I mean, I would have used FLET if I was sure I could get it to build and ship on the different things.

20:59 I'd much rather have done that than use Flutter or Dart for Flutter.

21:03 But you've got to work with the building blocks you've got, and this one just got better. So exciting.

21:08 Yeah.

21:09 Oh, also really quick, in the show notes, there's a video by this guy called Neural9.

21:15 His channel is called Neural9. Walking through the steps to do all that build.

21:18 So you want to see how it works, you can watch that eight-minute video.

21:21 Cool. Neat.

21:23 So that's for Android apps. For command line, normal command line stuff, I was going to talk about Harlequin.

21:31 So there's a lot of people that use SQL and SQLite for different purposes, of course, for databases.

21:39 But to take a look at your SQLite data, there is an IDE called Harlequin.

21:47 I don't think we've covered it.

21:49 But it's an open source Python project that it looks like it's pretty cool.

21:57 It's got on the – we're showing on the screen the little snippet or screenshot.

22:03 You've got kind of your tables, your data catalog on the left panel.

22:08 You've got a query editor and then some query results at the bottom right.

22:13 And it actually looks pretty slick for quickly going through some data.

22:18 It looks like it has hooks to go into DuckDB and SQLite.

22:24 That's why I brought up SQLite. And I'd probably use it for SQLite.

22:28 I haven't used DuckDB.

22:29 For people who don't know, DuckDB is also in process very much like SQLite, but it's Columnar instead of row-based.

22:36 So they're kind of in the same category, I guess.

22:39 Yeah. Okay. Yeah, I haven't used it.

22:42 But definitely SQLite, use that a lot.

22:45 So this is kind of fun. I like command line tools. This looks neat.

22:50 I wanted to – it's kind of a short topic. Just, hey, this is a command line interface for SQLite or DuckDB.

22:57 And that's fun. It looks like it runs on Linux, Mac, and Windows, which is cool.

23:03 But I was also – one of the things I've noticed is in like, for instance, a lot of Django tutorials, Django starts with SQLite.

23:14 And you – I mean, by default, it does that. And I think that you can – and then you can specify other databases.

23:20 But I noticed today a discussion on Mastodon that I wanted to bring up, kind of SQLite-related.

23:26 Jeff Chirplet posted a post by somebody else, Anze.

23:32 But, okay, Jeff's comment is, "This is a nice write-up about using SQLite in production with pitfalls and open questions.

23:40 I cringe whenever I see some Django Python luminary recommending people use SQLite in production.

23:47 I don't care how good you are. You won't get it right, even if you think you did." Anyway, so interesting commentary there.

23:55 So Anze's post was, "I wrote a blog post about using SQLite in production and dealing with DB as closed errors.

24:04 Happy to hear your thoughts." So the article is called, "Django, SQLite, and Databases Locked Error," and it walks through those.

24:13 And the – kind of the reality is Django doesn't, I guess, lock the database when it reads correctly.

24:20 The transactions are weird.

24:22 And a lot of the discussion around this really is if you're using – if you're using SQLite for a database that's mostly read-only, most people are just reading stuff, it'll probably work fine. And it might work great.

24:36 And it might be way less hassle than doing Postgres or something else.

24:40 But if there are a lot of transactions that are writing to it, if you have multiple writers, then you've got issues.

24:48 So just thought this was an interesting discussion. I wanted to bring it up.

24:53 >> Yeah, it is interesting. I think it really depends on the type of app you got.

24:58 Is it an analytics thing that's writing like crazy, or is it basically like the database here blog?

25:03 Right where it's really just you make an entry once a week if you're a good blogger.

25:09 You know what I mean? That kind of thing. And then it's all reads? Probably fine.

25:13 Right, so somewhere in the middle, I guess, like you can sort of turn that bar or watch that gauge turn from green to red as it gets closer to like a full analytics system. But yeah, it's pretty interesting.

25:25 >> Yeah, interesting discussion.

25:27 >> Indeed.

25:28 >> All right. What you got? Oh, we're done?

25:30 >> We're done. We're done. But we're not done because I have many extras. Do you have extras?

25:34 >> I've got just a couple extras. So since I've got my screen up, I'll run through a couple extras.

25:40 I started Python People podcast last summer and then kind of ran out of time trying to get the pytest course done.

25:51 And so now I'm coming back and cleaning up some things.

25:54 So there's a few recent episodes that finally came out. So like I stopped in October and then picked it up in January.

26:01 So we've got Will Vincent and Julian Sequeira and Pamela Fox episodes out now. So check those out.

26:07 >> Oh, excellent. Yeah, those are all great people. And many of them have been on this show as well.

26:13 So very cool. Nice to see these go in there. They provide a really interesting look, like really out of bounds looks into what people are doing.

26:21 You and Paul talked a lot about lacrosse, right, and empowering women and not the next pep.

26:30 And that was really interesting. So keep it going.

26:33 >> Some of the fun bits are to try to talk to kind of dig deeper into stuff that I normally don't ask about.

26:41 Like, for instance, Julian Sequeira. Julian's a really pretty positive person.

26:47 So I poked at that a bit and tried to ask him, like, really, how did you get this mindset?

26:51 I mean, clearly bad stuff must happen to you. And so we talk about his, you know, how does he get through it and keep maintaining a positive mindset. So it's good.

27:01 Anyway, what are your extras for us?

27:04 >> Let's see if I can find them here. OK, page find. Yes, that's the first one, page find.

27:09 So Brian, you and I, we both Hugo, right? >> Yeah.

27:13 >> Hugo is awesome. Go Hugo for people who don't know. Go Hugo.io. That's right.

27:20 Super, super cool way to build static websites, not just blogs, but static websites that are really, really powerful.

27:27 And I learned about this one from Mark Little. He also does a ton of stuff with Hugo.

27:34 He said, hey, you should check out page find. So what is this? I have no idea.

27:39 So page find, this is not just a Hugo thing, but for all static sites, it's a fully static search library.

27:47 So for static sites, whether this is Flask, Freeze or Hugo or Pelican or whatever, this is like a post build step thing that runs and it indexes all of your HTML or the parts that you tell it to index.

28:01 Or tell it to, you know, you can basically say don't include this part or whatever.

28:05 And it's no configuration. It has rich filtering. It has custom sorting attributes.

28:11 And the way it structures, it's what it does basically is JavaScript and it has an index that then the JavaScript reads in.

28:19 But the index is broken into a bunch of pieces.

28:21 So the front end stuff can like pull just little bits of it and not pull all the results back basically. Right.

28:26 So I added this over to my website where you're over here like Brian, we could see what I said about AI and check that out.

28:34 Isn't that awesome? So it finds all the different things that we could be talking about.

28:38 But it also like in my markdown, I have like H1, H2, H3.

28:44 And it will actually subdivide the results into sections like what is in this section demarked by H2 on this one page.

28:53 Oh, that's pretty cool.

28:54 That's really cool. Right. And it also does things like, I don't know if I can see any examples here, but if you type Y-O, it'll do like you, yourself, etc.

29:05 So it's not even just like exact word matching. It's like a really smart search engine.

29:09 And all it takes is just running a script for like a couple of seconds after you build your static site and then dropping the output into like a known location. Is that cool or what?

29:19 That's very cool. It's one of the issues I've had when switching to a static site is not knowing how to deal with the search part.

29:26 Yeah. So I was psyched when Mark sent this over. I'm like, yes, this is going in.

29:29 Yeah. The other part that I'm trying to figure out is how to get a decent contact form.

29:35 So that's still to be determined.

29:38 Yeah. I don't think page find is going to help with that, but this is cool. This is really cool.

29:41 So I'll add it to my stuff too. Neat.

29:44 It's incredibly fast. Like search for AI and I'm on like hotel Wi-Fi and it's nearly instant. Right.

29:50 So that is super, super cool. There's a lot of sites, even static sites. So like searching, searching, you'll see the little spinner.

29:58 You're like, what is it doing? Like, why is this search slow? No, it should be instant. Right.

30:02 And that's very much in line with like plugging something like this into Hugo means like it's still instant.

30:08 All right. I got a few more. Let's blaze them.

30:10 Okay. This is not to encourage people like more of a just interesting. Hey, careful.

30:16 We've got Pipey and PIP, the JavaScript world has NPM.

30:21 There's an article called when everything becomes too much, the NPM package chaos of 2024.

30:28 An NPM user named Patrick JS launched a troll campaign with a package called everything that depended on every NPM package there.

30:40 So when you install it, it tries to install the millions of NPM packages.

30:46 It destroyed it like because people were installing it and it was just taking too much resources and so on.

30:54 So the follies of package management, how's that? Yeah. Nice.

30:58 I'll get a little out of order here. So Matthew Fiker wanted us and we're happy to do so announce that the SciPy conference is coming.

31:08 And we'll be in beautiful Tacoma, Washington this year. So if you're interested, check that out and put a link to that.

31:16 And the last thing is I wrote an essay called unsolicited advice from Mozilla and Firefox about four things.

31:24 I think three things I think they did wrong and four things I think they could do to like absolutely both change the way that the place of Firefox in the market.

31:35 And alleviate their insane dependency on Google.

31:41 Like not anti Google. I do stuff with Google. I love YouTube, things like that necessarily.

31:46 But I don't think they're congruent with Firefox's focus on privacy very much.

31:53 And also 95% of your company's revenue from one deal with one company that's kind of at a whim could just change their mind.

32:01 That's not a great place to be. I'd like to see Firefox doing well. So I thought a lot about it and wrote about it, including they should just lie about their user agent.

32:08 Right. Like when a website says this site runs best on Chrome and using this crappy old browser we don't know about.

32:14 You know why you never see that on Vivaldi or Brave? Because their user agent is identical to Chrome.

32:19 So when you get to the website like, oh, this is my favorite one. Perfect. We're good to go.

32:23 Right. How many people leave Firefox because when they get to a site, it says this doesn't work well. You need to go get this other browser.

32:29 It would stop saying that if Firefox just said, hey, we're Chrome. Things like that.

32:34 And sure, it would hurt a little. It would hurt their pride. But people leave Firefox because the website will refuse to run.

32:42 And it probably would work. But if it's going to refuse to work, then it's not going to work. Things like that.

32:49 So anyway, this is I think is a really fun article. I had a lot of fun thinking about it. So people can check that out.

32:53 And I think I don't dwell on this too much, but there are a lot of internal site stuff. So a lot of people do internal tools at companies.

33:03 And they'll do that. It should use Chrome. And somebody will try it with Firefox and they'll be like, oh, it doesn't work.

33:11 And it probably does. It just blocks it for the heck of it.

33:16 Exactly. And no one's going to update that site. Right. It's just, yeah.

33:20 Another thing that's just maybe interesting to put on people's radar is another thing a friend of mine co-founded, Wayne's, is this thing called Island.

33:30 Which is like a enterprise browser meant just for giving enterprises super interesting control over things like that you were just talking about.

33:38 So this is actually super interesting. One of the things I think Firefox could do, but also it's just really interesting.

33:42 Island.io. People can check that out. Sounds weird. Like why would you ever want that?

33:46 And then you watch the video or listen to it and you're like, actually, that's awesome. So.

33:50 Okay.

33:51 Like installed. All right. Shall we joke?

33:55 Yeah, let's do a joke.

33:56 All right. Well, this is a Linux joke. It's more than a Python joke, honestly.

34:01 So, Brian, have you ever got a bike lock? One of those really combination lock for anything. But in this case, it's a bike lock, right?

34:07 Okay.

34:08 So here's a little character says, my new bicycle lock. Hmm. To keep my new bicycle secure.

34:13 It has three digits. Let's see. So that's a thousand combinations of what we could have.

34:18 And then they start to rule out where the ridiculous ones, right? Like one, two, three and stuff like, hmm.

34:23 Nine, nine, eight, maybe. I am not silly enough to use six, six, six or seven, seven, seven to give full access to everyone.

34:31 Change mod seven, seven, seven. Which gives it full access to the read/write access to whatever you change modded.

34:38 That is funny.

34:40 Yeah, it's pretty good. I mean, obviously you wouldn't use seven, seven, seven.

34:45 I may be the wrong target market for this because it's sort of funny, but also I'm thinking, did bike locks really have three combinations, three numbers or were there four?

34:55 You're being way too practical. Like four, six or something like that.

35:00 I had a smartphone smart lock once and it was awesome. You would hold your phone up to it and it would unlock.

35:05 I got it from my electric bike before my niece decided electric biking wasn't for me.

35:10 And one time I was out biking with a friend and I parked it in the summer in the sun and like the electronics bit of it got direct sunlight and it's a black because it's a lock, right?

35:21 Got super hot, like so hot you couldn't hardly touch it, but also so hot that like the electronics wouldn't run and I couldn't unlock it.

35:27 I had to like put it in the shade for an hour before I could go home. I was so frustrated.

35:30 I covered it with my shirt or something and just sat there until it cooled off so I could go home.

35:34 Oh, that's, that's bad. And then also I've seen, like the, the combinations really kind of doesn't matter. It's how thick the rest of the lock is because I've seen people just come up with these, like a battery powered just cutters and just cut the lock off.

35:49 but yeah, exactly. It's probably not the combination, but if you do have one, don't use seven, seven, seven, because clearly that's gonna, I don't know, it'll just fall right off if you do that.

36:00 Just go with one, two, three, four. So yeah, exactly.

36:04 Anyway, well, thanks a lot. I hope you get power back at your house soon.

36:09 Thanks. I hope so too. probably the, the power people said probably today, but never know. You never know.

36:16 All right. Well, good to be here with you later. Bye.

36:19 Yeah. Bye everyone. Bye.

Back to show page