Welcome to another insightful episode of the JavaScript Jabber podcast, hosted by Charles alongside our expert panelists Dan and AJ. Today, they are thrilled to be joined by Avishai Ish-Shalom a seasoned technologist with an eye for challenging conventions in the tech world. In this episode, Avishai takes us through fascinating discussions comparing industrial food products to technological abstractions, including his unique perspective on the “marshmallow effect” and the evolving complexities of virtualization.

They delve into the challenges of backward compatibility in modern tech, using real-world parallels like AWS virtual storage options, and discuss the impact of technologies like Docker and cloud services on our understanding of underlying infrastructures. Charles shares his upgrade journey from an aging Mac laptop to a powerful System76 desktop for AI tasks, reflecting the changing demands on development environments.

Listen in as they explore the nuances of binary vs. textual protocols, the importance of future-proofing legacy systems, and Avishai's compelling arguments in his articles "Don't Paint the Roses" and "The Marshmallow Effect." Plus, they discuss Avishai's career evolution and the intellectual challenges faced by today’s engineers in the rapidly advancing tech landscape. Whether you’re a casual listener or a tech enthusiast, this episode promises to offer valuable insights and thought-provoking discussions. Stay tuned!

Picks

Charles Max Wood [00:00:05]:
Hey. Welcome back to another episode of JavaScript Jabber. This week on our panel, we have Dan Japir.

Dan Shappir [00:00:11]:
Hello from Tel Aviv, which is actually cold even though it's probably pretty warm by your standards.

Charles Max Wood [00:00:18]:
He says cold is below freezing here or at least was this morning. And we also have AJ O'Neil.

AJ O'Neil [00:00:24]:
Yo. Yo. Yo. Coming at you live from the wonderful, wonderful shed.

Avishai Ish Shalom [00:00:29]:
Oh.

Charles Max Wood [00:00:30]:
I'm Charles Max Wood from Top End Devs. I am jealous of your shed. We have a special guest this week, and that is Avishai Ish Shalom. I hope I got close on that. I'm sorry if I didn't.

Avishai Ish Shalom [00:00:40]:
That's okay.

Charles Max Wood [00:00:42]:
So, yeah. I've I've thought very deeply about putting something like that in the back of my house. Anyway, Dan, you invited Avishai here and it seems like you know each other pretty well. So do you want to introduce him and then he can fill in the gaps for us?

Dan Shappir [00:01:01]:
Yeah. Well, I I do. I've known Avishai for a while. I think we worked together at Wix, a long time ago. Correct me if I'm wrong. And I wanted to have Avishai on our show for a while now, and I'm glad that he's finally able to join us. The reason for this is that, similarly to Tomer Gabel, who we had on the show a few

Charles Max Wood [00:01:25]:
weeks ago. Good.

Dan Shappir [00:01:26]:
Yeah. Yes. He was. We had him on the show a few weeks ago. So similar to him, Avishai is one of those people who when I communicate with, often, it forces me to rethink or even reconsider some of my technological assumptions and even core beliefs. Things that I hold to be obviously true, suddenly don't seem so true anymore. Thanks to Avishai. And, you know, it doesn't happen every day, but it does happen.

Dan Shappir [00:01:58]:
And I have to say that, to be honest, this is isn't always a comfortable experience. You know, we as people, as humans, we despite having our viewpoints challenged in such ways. Even as engineers, we tend to be creatures of habit. You know, what we use what we like to do, we continue doing the same thing, and, you know, we we prefer to stay the course as it were. We prefer complacency over disruption even when we, you know, proclaim otherwise. But I think it's really important for us to go through such experiences because that's how we grow. And when you have some in such interactions, you know, you grow or the other party grows or, ideally, you both grow as a result of such engagements. Now I recently learned that a few of our guests that we had on the show apparently did not have a good time, and that's really unfortunate.

Dan Shappir [00:02:58]:
They felt a bit put upon when we asked them questions that require them to justify technical decisions that they made. And when we presented alternatives to solutions they came up with, they felt that, like, you know, we were kind of attacking them. Obviously, we want our guests to have a great time, and I think that most of them definitely do. And I hope, Abishai, that you will have a good time as well. We will see. But more importantly than that, we want our audience to gain actual value from the show. We want our audience to learn something that actually benefits them in their, career as engineers. And sometimes that requires, you know, asking harder questions, challenging, our guests on those decisions that they made.

Dan Shappir [00:03:51]:
And if it does make them feel uncomfortable, well, sorry, but not sorry because it's really a part of what it is to be, you know, on on a podcast such as ours. I guess that there are others where these things don't happen. You know? Fine. I I love a lot of other technical podcasts. You know, we have different emphasis, but this is how we do things. So, you know, if you want to come on our show, you need to be ready to answer some tougher questions. It's just the way that we do do things, and that's what I wanted to say.

Charles Max Wood [00:04:30]:
Yeah. I can give an example. You brought up Tomer, Gabel when he was on the show. And, you know, we had a lot of back and forth on, like, types, strong types, type systems. And, you know, I it was funny because I was thinking about it, and then I watched the talk because, you know, I live a lot of my programming life in the Ruby world. And it was a discussion between, David Heinemeier Hansen and, Tobias or Toby Lutke from from Shopify. And they were having that same discussion. Right? And it was interesting just to see kind of the trade offs that they were talking about, and then I wish that I could go back on that episode and say, so I think you're right about this and not, you know, and and right.

Charles Max Wood [00:05:12]:
And I got better informed about maybe I'm not running into the things that bring that trade off. And I think the kinds of questions and back and forth that you're talking about, Dan, are the things that allow us to clarify that and open it up and go, okay. These are the problems you're trying to solve, not these other ones. Or these are the you know, this is where the trade offs really start to click into place. Because what I find is that it's not always black and white up and down the board. It may just be your experience leads you to make this decision where I'm I'm just not working in a space where that matters. Or maybe I just never considered that I needed to think about it that way and you push me to do better. So I I agree with you.

Charles Max Wood [00:05:51]:
I think I think some of that, you know, back and forth and, hey. It looks like this solves a problem better than that. And, you know, we're gonna give people the tools to go, oh, yes. I need that. I you know? Or, no. I'm not quite to the place where I need that, but then you'll be thinking about it as I get there there. Or maybe, hey. You're talking to another group of people that think about things in a different way than I do, and all of that is constructive.

Dan Shappir [00:06:20]:
Any thoughts, Avishan?

Avishai Ish Shalom [00:06:23]:
Well, I can tell you that when I'm using static types, like, I'm enjoying myself so much, and I'm like, what idiot would use dynamic types? And then when I'm using language that

Dan Shappir [00:06:33]:
It's me. It's me. Dynamic type.

Avishai Ish Shalom [00:06:35]:
Wait. Wait. So why don't I use it in closure? It's my favorite language. I'm enjoying myself so much, and I'm like, what idiot would use static types? So it's it's actually like, once you get your mind into a specific style of programming, it feels very natural to you. It's very easy to forget all the advantages that all style has.

Charles Max Wood [00:06:54]:
So Cool. Well, let's talk about marshmallows. I mean,

Dan Shappir [00:07:01]:
Wait a minute. First of all, Avishai, I said that we work together at Wix. Can can you tell us a little bit about yourself?

Avishai Ish Shalom [00:07:08]:
Yes. I can. So I did a lot of weird stuff, I guess. I started my career as a physicist, not not really in IT. And then at some point, I discovered that I'm more interested in how fast my simulations are running, more than the actual results, so I can switch into into IT. Initially, I went into, systems. I did that for a while, and, then I founded a consulting company, And I worked on a lot of different stuff, part of large large scale architecture and performance stuff and, some training of of engineers. And, at some point, I stumbled into big data.

Avishai Ish Shalom [00:07:49]:
It was, like, the big hadoop hype back in the day. So I spent about 2 years, you know, getting people off Hadoop because they didn't have enough data. You know, the whole your data fits in RAM thing. And after that, I went to work at Wix. I did, I I headed the back end team at Wix. And, from Wix, I went to work for VC. That's quite a good return, I guess. So I was in the in the residence at, Alif VC.

Avishai Ish Shalom [00:08:21]:
It's one of the prominent, VCs in Israel. And, after that, I went to work for CLDB, which is a high performance, Cassandra clone written in c plus plus, Very unique and interesting thing if you wanna talk about that. And since then, I've been an independent researcher. Now nowadays, I'm mostly working on performance problems and training engineers, which is my core passion. I think that now that we have the AI age, we have a very big problem because everything's too easy. So you don't actually learn how stuff works. So the funnel of becoming a senior from from a junior is now gone. If you think about network engineers, for example, how how did you train to be a network engineer back in the day? You had your home router, and you played with it, and you needed to, let's say, you know, define the DSP and the DNS and all that stuff.

Avishai Ish Shalom [00:09:14]:
NAT, if you had, some kind of a home router, and and you learned doing that. Nowadays, you just get Google Mesh and you install it and everything works. So there's no no reason for you to fiddle with it and actually learn networks. So there's no funnel for, network engineers anymore. So it's a problem I'm trying to help solve.

Dan Shappir [00:09:35]:
You know, I'm thinking about all, you know, all the American TV shows where you have, the father lifting up the hood of the car and showing their their their son or daughter how it actually works, how it runs. And I'm thinking about all the new electrical cars. It's pretty much gone.

Avishai Ish Shalom [00:09:56]:
Yeah. I had experience with motorcycles. I I, had one of the last motorcycles that still had, carbo angles, and then the following models, only had the fuel injections.

Charles Max Wood [00:10:07]:
The fuel injection. Yeah.

Avishai Ish Shalom [00:10:08]:
Yeah. Exactly. And you can't you can't tune it. You can't fix it. So the days of learning yep.

AJ O'Neil [00:10:17]:
I've never heard anyone argue against fuel injection. I've I've never technology,

Avishai Ish Shalom [00:10:23]:
but It's I mean, the trade off is, like, usability. Yeah. It's it's more fuel efficient. It has more performance. It's more reliable, but downside is that you don't get to learn how motorcycles work anymore.

Charles Max Wood [00:10:36]:
Right. You can't get the vehicle injection is controlled by the computer.

Avishai Ish Shalom [00:10:39]:
Yeah. Exactly. There's no no There's

Charles Max Wood [00:10:41]:
no mechanical management of it.

AJ O'Neil [00:10:45]:
That's that's interesting because I so I just got a motorcycle, and I'm actually glad that I got one that, you know, I got an old one, so it was cheap. But I it was just new enough that it was fuel injected and which motorcycles got fuel injected much later than cars did. I mean, a lot of 4 wheelers, I think, are still carbureted. But, yeah, I kinda I kinda felt like I dodged the bullet. I still feel like I'm learning about it, but I didn't I didn't have that sense of understanding the carburetor is is key to understanding the maintenance of the the motorcycle. So that's I I I'm, yeah, I'm really I'm really interested that you said that. I'm I I have to sit on that for a minute. I I wonder what you know that I don't know that makes you feel that way.

AJ O'Neil [00:11:29]:
Obviously, something. But

Avishai Ish Shalom [00:11:30]:
So I'll I'll give you an example. You live in a colder climate. Right? So you need to heat up your motorcycle for a little while before you stop riding it. And the reason for that is because of the carburetor and because you actually need, heat for the fuel to spray in, you know, to the mixture so that you get you actually get it into the engine and it blows up. Whereas with, you know, injection system, you don't need to do that. The computer takes care of it. So the whole, like, even this bit of thinking for pausing for a second, thinking, okay. I need to warm up my car because, you know, colder climate, fuel fuel mixture, all that stuff, that's gone.

Avishai Ish Shalom [00:12:12]:
You're not even aware of it anymore.

AJ O'Neil [00:12:15]:
I so my mine is fuel injected. It's just new enough to be fuel injected, but it does it does definitely behave differently. Like, I can tell you know, I I do get a sense of it. But, yeah, the 4 wheeler, I actually have to I actually have to tune the carburetor of the 4 wheeler so it'll start in the winter and not flood in the summer.

Dan Shappir [00:12:36]:
I I'm still thinking about the fact that you defined yourself as a researcher, and I'm curious what that means and how that translates to real life.

Avishai Ish Shalom [00:12:46]:
So a lot of the stuff that I do right now is, first of all, a lot of reading, but also a lot of observing and experimenting. So some of it is is, like, on how systems work, and and some of it is into models. And I'm I'm saying models specifically because it relates to how people understand systems. You don't actually, understand a system because you you don't actually get to directly experience a system, and you you cannot perceive a system. What you perceive is a model of a system that you build inside of your head. And there are some common models that we all know, and, they play a very important part in how we pass the world around us. So understanding those models or inventing new models and and making them, approachable to people is a very important part of of teaching and also debugging and, architecture and all that stuff that we do. So the research part, some of it is is, you know, just going to the field and seeing what is comprehensible to people and how people pass the world that they see and how they look at the world that they see because you you view the the system through dashboards and graphs and metrics and, and, of course, all the tools that you have.

Avishai Ish Shalom [00:14:03]:
And, some of it is learning psychology and learning, methodology, you know, how people think about stuff, how the brain works, all the cognitive biases that go into play. And some of it is is actually researching the tax stack because that also, informs and kind of, conditions the way that we experience things.

Dan Shappir [00:14:27]:
And you're able to make a living doing that? Cool.

Avishai Ish Shalom [00:14:32]:
Not yet. So, like, I'm doing consulting, mostly on performance stuff. I am giving some workshops, which is starting to get, more and more like, a bigger and bigger part of of, the the work that I do. So at some point, I guess, it will become the main thing that I do. Hopefully, I can make a living just doing that, but we'll see.

Dan Shappir [00:14:54]:
I just wanted to also add that, you know, when you were speaking about the importance of models, it kind of also directly translate to the importance of naming things and naming things properly.

Avishai Ish Shalom [00:15:07]:
Yeah. Because it's just it's not just a name. It's the name and everything, you know, all the associations that it has with it.

Dan Shappir [00:15:15]:
I totally agree. So I I actually brought you here because of an I don't know if I you know, going back to my kind of little speech at the beginning, because of this, argument we had online about binary protocols versus textual protocols. But while preparing, I also read or reread some of the articles that you posted on your excellent websites website. And, so there and there were 2 the latest two posts there kind of caught my eye. One of them is titled, don't paint the roses, and the other is titled the marshmallow effect. And I definitely wanna talk about these as well. So I'll leave it up to you which which one of those 3 you wanna start with.

Avishai Ish Shalom [00:16:05]:
I'm cool with all with all of them, but, let's talk about text and binary protocols for, for a second, because Okay.

Dan Shappir [00:16:12]:
For sure.

Avishai Ish Shalom [00:16:12]:
It's also like, it ties very nicely into the other topics. So, text actually, one of the points I wanna make is that there is no such thing as text protocol.

Dan Shappir [00:16:24]:
It's all binary. You kind of stole the one of the what I wanted to say. I I basically wanted to say that if you go down low enough in the stack, everything is binary. It's at the end of the day, it's bits over the wire. So, obviously, it's it's binary. And, you know, you encrypt things, you compress things. So so, obviously, that turns them into binary data. But I I was more thinking about the the applicative layer.

Dan Shappir [00:16:53]:
So I was making the argument that at the applicative layer, in a lot of cases, not always, but in a lot of cases, there are benefits to text based protocols. For example, protocols that send JSON or XML or, god forbid, or or HTTP over the wire. And per my understanding, you were making the argument that in most cases, a binary protocol is is what you prefer.

Avishai Ish Shalom [00:17:25]:
So that's one of that's part of it. But I think that, the problem with this discussion is that it it's about, you know, the civilization protocol itself, and it ignores the larger context of how we write software, you know, when we have a certain protocol. And I'll give you an example of what I mean. So, JSON, for example, doesn't actually, specify what the size of an integer is, k, or what the actual precision of the float is. And and they kind of fixed it in in the following RFCs, but not all implementations, of course, adhere to it. But the the thing about this is that, if you compare it to a binary protocol, proper binary protocol, it takes much less much more, like, bytes, much more verbose in in how it encodes things. So a specific number, for example, if you basically, you have a 1 byte per digit. So a very large number actually takes a lot of space, which means it has a lot of effect.

Avishai Ish Shalom [00:18:28]:
But it means that when you're writing software, you would not use the same precision because of this. So the protocol actually affects how you write the code. And we have a lot of of of code that is written under the you know, assuming that you're gonna use certain protocol, and because of it, it's written differently. You're not actually using the same position. You're not actually using the same data types. You're not actually writing the same software that you would otherwise. So even if the efficiency of binary protocols would be the same, it's not. You would still prefer to have them because of because it allows you to write better software.

Avishai Ish Shalom [00:19:07]:
And that's, an angle that is not often discussed when you're talking about protocols. And just to clarify this example more, think about, what happens if you want to, do a denial of service attack against, you know, some server that, accept JSON or XML. You actually have to read the entire JSON before you understand that the message is done. So you have to have very large buffers just in case, you know, someone actually decides to send, you know, like, 8 megabytes of of JSON. And, if I send a very large and very deep JSON to you, I can very easily do, like, denial of service attack against parcel. Whereas in binary protocol, most of them have very strict schemas, which allow them to detect no phone messages very, very easily and very early. They don't actually need to have, the the entire buffer. Most of them can also stream.

Avishai Ish Shalom [00:20:04]:
So it makes the web servers much more efficient, much more, much cheaper, but also immune to denial service stacks. And this you you can actually see this effect in in all the text based protocols. So even if the protocols, you know, they had the same payload size and they, you know, network was the same and everything else was the same, Just because we can write better software, I would prefer to have binary protocols.

Dan Shappir [00:20:34]:
So here's the thing. First of all, I can get into the technicalities of of, you know, some of the downsides that you mentioned. But before that, I want to, explain, like, what caused me to say that in many cases, I prefer textual protocols. But first, before that even, I want to say that, obviously, there are scenarios where textual protocols are totally not appropriate. So, for example, nobody would send a video stream as a textual protocol or or even images over the wire. It's probably a bad idea to send them as as textual, protocol. But we do. And I and I'll let you, respond in a second, AJ.

Dan Shappir [00:21:16]:
I just wanted to say that the the the the the two reasons that I wanted to say as as positives for for textual protocol before we get into the possibilities of of, you know, the some of the negatives that you mentioned is one that it's easily humanly readable, which is significant benefit, for me when I have to work with protocols. Second is the fact that in many cases, I don't really care. I care that something is a number rather than exactly how many bits it takes to represent it in the exact, format. And finally is the fact that you can mix textual protocols and binary protocols together, which can get you the benefits of both worlds. And now to you, AJ.

AJ O'Neil [00:22:10]:
So there's there's somewhat of a snuck premise in what you've said, which is that

Dan Shappir [00:22:15]:
Me or or Avishai?

AJ O'Neil [00:22:17]:
Avishai. Sorry. Oh. Avishai. There's there's somewhat of a snuck premise in that you're saying if people are using text protocols, they're less efficient and they're more subject to these issues because, because of the the text protocol itself when I'm going to argue that because of my own experience, and I imagine you've seen this too. If you gave someone a binary protocol and it were to become popular, the binary protocol would have all of the same problems because the issue with the dial the the denial of service, not balance checking, not having, a byte limits or rate limits, Those are engineering issues. They're not protocol issues. They're not the the fault of the data format.

AJ O'Neil [00:23:09]:
Likewise, what goes over the network is a bit different depending on the size of message. But we're talking about communication, not binary files. We're not talking about videos. We're talking about communication. Normally, those messages are gonna fit into a TCP packet. And if they're not gonna fit into a TCP packet, taking away 10 to 20% of the brackets and braces and replacing that with, little little, size headers is not actually going to be what makes the difference in, you know, in the long run of when we're exchanging messages back and forth, how do we fit them into a TCP packet? We have to, you know, significant like, if some person's typing a paragraph, they're just typing a paragraph. You know? And and that's gonna fit. If it's you know, so so there's these other things.

AJ O'Neil [00:24:01]:
So I don't think that I I I will agree with you. There's a lot of benefits binary protocols, but I think the examples you you gave are a little bit straw manny.

Avishai Ish Shalom [00:24:10]:
Before I have to do it, by the way.

Dan Shappir [00:24:12]:
Aviso, before you respond to that, I think it might and I and we will definitely let you respond. I I just I thought it might be worthwhile to provide specific examples of what we mean by textual protocol and binary protocols because we're kind of being, you know, talking in theory. So it might be worthwhile to translate it into actual practice. So can we give an example of a binary protocol, and can we give an example of textual protocol, and maybe if we can give an example of a mix?

Avishai Ish Shalom [00:24:41]:
So, a textual protocol, for example, would be, JSON. JSON is a serialization format that, basically JavaScript notation object notation. It's based on JavaScript. It's a valid JavaScript, and it encodes data, strings and then arrays and dictionaries and numbers as, ASCII or UTF 8, characters. Whereas a binary protocol would be something like a protobuf, which, encodes similar data, in this case, with some schema as, bytes. So, a number, for example, would be just, you know, a byte byte representation, which also means that numbers are represented in much more efficient way. The the number, 1, for example, would take, just, you know, 1 byte, but also, you know, 1825 would be also would be a 1 byte. Whereas in JavaScript, so in, JSON, the number 26 is 2 bytes because that's 2 characters.

Avishai Ish Shalom [00:25:47]:
So it's actually like the text representation of a number. But, Ajay, I agree with you, by the way. I think that the the framing this discussion as textual protocols versus binary protocols is wrong because as Dan said, it's all binary over the the wire. Really, the question is the discussion should be, specialized protocols versus general purpose protocols. And we know, like, it's also mathematically proven that general purpose protocols or general purpose things are less efficient across the board, whereas specialized things are obviously more efficient in the specific use case, but maybe less efficient in other use cases. And and this is why, I don't like the the framing of of the discussions, text versus everything else. It's it's text was selected because it's like a universal representation. It makes very few assumptions about what goes over of the protocol, and it's based on, some premise which we inherited, which is that, we are transmitting textual documents.

Avishai Ish Shalom [00:27:00]:
And this, this specific assumption was more or less universal because when it was invented in the seventies, this is basically what we sent over the network. We sent text to documents of sorts. We didn't send images or videos back there.

Dan Shappir [00:27:16]:
And if I can interrupt you for a second, I was about to give 2 more or a few more examples of such protocols. Exactly an example of of a textual protocol is is and and it's exactly the scenario of a document over the wire is sending, the HTML document over HTTP. The HTTP headers are textual, and the HTTP body, which is the HTML document, is also textual. On the other hand, if you're sending an image over HTTP, then, then your so the the header remains textual, but the body becomes binary.

Avishai Ish Shalom [00:27:57]:
And this doesn't strike you as odd?

Dan Shappir [00:28:01]:
Let me tell you a story. I, several years back, I was working on, a software for remote access. Basically, it was running a desktop or a Windows desktop or a Windows application, in a data center on, on on the server or on a VM and accessing it remotely using the browser. So, basically, replicating a Windows desktop interactively inside the browser. And you want this to be really responsive, and, ideally, you want even to be able to support animations. And, you know, even though I'm talking about something like 15 years back, we were able to hit something like, 10 FPS, for for for videos running on the server being streamed in this way over WebSocket to the client to be redrawn by JavaScript. And we were sending commands and images. So a command might be, you know, draw an image, but it might also be draw a line or play some sound or, you know, do some various other things that user interface Windows user interfaces do.

Dan Shappir [00:29:18]:
And we we mixed. So the commands were sent to small JSON packets, and the images and audio and stuff like that, they were sent sent it as binary. And it actually made the protocol, I would almost say beautiful, because we were literally able to drive directly translate those JSON small JSON packets into function call JavaScript function calls with parameters. So, basically, sending commands over the wire directly translated into executing JavaScript commands, where and and the and the binary packets were handled as, you know, opaque binary blobs. You just gave them to the blob object, and you got an image or an audio file or whatever. So I I don't see any problem with that. It's basically if we're going back to the example of HTTP, obviously, the image is not something that I'm going to be sending as textual data, and it has it's kind of meaningless as textual data. But being able to look at the HTTP header instructions easily, you know, without requiring special tools from my perspective has a lot of value.

Avishai Ish Shalom [00:30:34]:
But you do you don't actually look at the HTTP without special tools. You always use some special tool. So when you look at the HTP, you use TCP dump, which is a specialized tool. And by the way, knows how to pass to pass binary. Or using the browser, which knows how to pass binary, or you're using something similar like Wireshark. All of those tools actually pass binary.

AJ O'Neil [00:30:58]:
I use curl

Avishai Ish Shalom [00:31:00]:
Fair enough.

AJ O'Neil [00:31:01]:
And Netcat.

Avishai Ish Shalom [00:31:03]:
Netcat is the only general purpose tool that, in this case. Like, curl is specialized too. I What prevents Netcat from passing binary?

Dan Shappir [00:31:13]:
My issue with binary is that it in many of those cases, it feels like premature optimization, and it leads to even more premature optimizations.

Avishai Ish Shalom [00:31:22]:
Okay.

Dan Shappir [00:31:23]:
And and and the fact and the fact that I really need highly specialized tools versus generally available generalized tools in order to parse it is is detrimental for my experience.

Avishai Ish Shalom [00:31:38]:
So I would say that the little problem and the little discussion here is about tooling, actually. Tooling and, some about tooling. Yeah. It's always about tooling. The entire operating system is a tool, so so does that. But, let me try to reframe the conversation a little bit here. So I view protobuf, for example, as, as not as a binary protocol, but rather as a carrier for a family of user defined protocols. K.

Avishai Ish Shalom [00:32:08]:
Well, as, this is really the problem that I have with with the text and HTML, all that stuff, is that it's it's a very poor system for writing user defined protocols on top of it. Was Probuff is a very good system for doing that because it was designed to do exactly that. So every message, every every, protocol that you write on top of protocol or Probuff, is specialized, but you still get to define how it behaves.

Dan Shappir [00:32:36]:
Can you elaborate a little bit about what protobuf is? Because I think many of our listeners will are not familiar with it.

Avishai Ish Shalom [00:32:43]:
So protobuf is a is a, a portal it's actually 3 three things. It's a serialization, protocol. It's a network star not network stack, but, network protocol and, schemas. And and, this system was designed by Google. 1st, it was designed for internal use, then they open sourced it, and they also open sourced the RPC level that came with it, gRPC. It's a multi platform system, and, it has a lot of fancy features, but that's not really what we're talking about here. And the way that you would use protobuf is that you would write something called a proto file, which defines the schema of messages. And, then the server and the client can agree on what's being sent, and they know how to, you know, pass messages and all that stuff.

Avishai Ish Shalom [00:33:35]:
And proto buff messages can be sent over, like, binary network protocols and, HTTP and, you know, various other protocols. You can even save them to files if you wanted to. So they're kind of universal in this way. And this is the nice thing about this, that you can actually use a carrier that's more efficient or, you know, more, widely supported depending on on the use case.

AJ O'Neil [00:34:03]:
I'm I'm having a real hard time with this. It seems like you're suggesting that the network is one of the great bottlenecks that we need to be concerned with, when I don't see that in my experience. I agree that gRPC could be great for server to server communication and internal infrastructure, But I've also seen a talk that specifically argued against it where I mean, you could see a talk for everything. Right? So that doesn't say much. But the arguments were very compelling that the development time that they saved by having everything internal and external as JSON, being able to debug any service quickly, look in the logs, that that the efficiency that they gained by not worrying as much about one of their most abundant resources was was well worth it. And what I have seen with gRPC is it's a level of complexity that most people can't manage. So I'm not saying that the experts that are working in the in the enterprise in highly tuned scenarios shouldn't be using it. They know what they're doing.

AJ O'Neil [00:35:13]:
They have use cases that I personally don't have. But what I have seen looks like and this could be a misconfiguration, but it looks like a minimum of 2 megabytes of JavaScript to be able to produce a few gRPC messages. Now, obviously, you could you could hand tune it, and you could do that in, you know, bytes. But what I've seen is that the generated tools, like the protobufc, generates an entire infrastructure for protobuf to basically get out that hello world message. So I I am not convinced for web applications that that what you're saying aligns with the experience that I have or or that I know other you know, I'm not seeing it.

Avishai Ish Shalom [00:36:01]:
Yeah. And you're not wrong, by the way. So here's the fundamental problem, and we we said that's a tooling problem.

AJ O'Neil [00:36:08]:
Yeah. Sure.

Avishai Ish Shalom [00:36:08]:
We so JavaScript doesn't actually support JSON. The browser does. So what does browser do to support? Point,

AJ O'Neil [00:36:17]:
I'm pretty I mean, I is it not part of the ECMAScript standard? I I thought it was adopted. Am I mistaken?

Avishai Ish Shalom [00:36:23]:
No. No. It's it's the it's v 8.

Dan Shappir [00:36:26]:
Okay? No.

Avishai Ish Shalom [00:36:26]:
V 8.

Dan Shappir [00:36:26]:
What Avishai, I think, is saying sorry. What Avishai, I think, is saying is that the code that parses the JSON is not written in JavaScript. It's written in in Rust or or c plus plus or something. Whether it's part of v 8 or or Blink is is kind of irrelevant to the web developer.

Avishai Ish Shalom [00:36:45]:
But but the thing is this. So, first of all, the the to mention the HTTP thing, I find it very odd that the headers, which are the only thing that should be very, very efficient and and, is completely independent of, you know, the the actual payload and whether payload is text or binary is text. And this is actually a very big problem, that Google and, you know, the rest of the people working on h t p three encountered. Actually, they encountered it in h t p 2 when they tried to introduce binary header binary headers because of all the reasons that I mentioned, because it's more efficient, because it protects the the, server and client implementations against the denial of service tax and all that stuff. So, actually, a binary header is something that everybody wants, but for historical reasons, we don't have. And if we designed HTTP today, we would actually do the reverse. We would have binary headers, and everything else could be text or binary. The the reason that we have it in reverse is because of you know, basically his the history of, you know, computing systems and the Internet.

Avishai Ish Shalom [00:37:53]:
And going back to your point about gRPC versus JSON, yes. JSON is universal for, again, for historical reasons, and all the browsers support it. But and this makes it the path of least resistance. So you're not incorrect in saying that, you know, Portobuf Kotlin is harder. And it's true it's harder, but it's harder because, it's not universal in the sense that not all tooling supports it natively.

AJ O'Neil [00:38:18]:
Well yes. Yeah. Because I'm not just saying it's harder.

Avishai Ish Shalom [00:38:23]:
I I also wanna mention that everybody actually writes schemas even for JSON. They don't do it explicitly, but the code actually has a schema for what message is. And Agreed. So it's not that you you get around, you know, this complexity of writing schemas and describing the messages when you do JSON. So to the first

AJ O'Neil [00:38:49]:
point, I'm not saying it's harder. I'm saying that it's it is, in fact, less efficient in one of the key areas that matters. I agree with you. Can we get a binary protocol built into the browser? I like, can we have we like, we have JSON dot stringify, JSON dot parse. Can we get in the browser protobuff dot parse? Sure. Like, that would be cool. We can send

Dan Shappir [00:39:15]:
binary data off of off of WebSockets. WebRTC is a binary protocol. You can send data in in it. So we kinda do. We are restricted in what we can send and and be in the carrier, but, but we to an extent, we we we already do. Well, I mean, the machinery.

AJ O'Neil [00:39:35]:
There there's a lot of machinery to produce binary.

Dan Shappir [00:39:38]:
I do wanna say I do wanna say something about, JSON and and the parsing problem. Now obviously, it's not a solution to denial of service even though you can, you know, build such solutions. But if you're looking at it from a straight on protocol, what somehow eludes a lot of people is that instead of sending a huge JSON that needs to be passed in its entirety before anything, can be done with it, it's usually very straightforward to send much smaller JSON, packets or parts, and then parse each one of them individually. So

AJ O'Neil [00:40:17]:
Well, JSON l does this, and that's a pretty decent solution.

Dan Shappir [00:40:23]:
It might As

Avishai Ish Shalom [00:40:23]:
long as everybody on the system is well behaved.

Dan Shappir [00:40:26]:
Yes. Of course.

AJ O'Neil [00:40:29]:
So okay. The one question I had earlier, CBOR and ASN 1 are binary protocols that are generic protocols. I would think that in every way, they suffer from the same problems as JSON. So protobuf is different. Proto protobuf is PACS trucks. So would you also say that CBOR is, you know, pretty much just as bad as JSON, or or would you put CBOR in the category of protobuf?

Avishai Ish Shalom [00:41:00]:
So I would argue that every, universal general purpose protocol suffers from similar problems. It's it's not really about text or or, or binary. It's it's more about restricting the use cases, which is where schemas tie in. And this is why I like protobuf and similar systems because they allow you to define, you know, the special, cases and, you know, make up your own rules about what they mean and how to use them and how to validate them. And and and, really, this is, like, a big issue in computer systems in general. It's it's not really about, like, civilization. It's it's about systems in general. You you actually see this problem in in many other cases.

Avishai Ish Shalom [00:41:42]:
And going back to the point that you made earlier, this is also a problem of of, you know, deploying stuff in the large scale. Because every time we deploy a protocol, if it's successful, it becomes legacy. And legacy, you know, it's a very important thing, but actually it means that you had something that worked very well. And once something works very well and becomes, you know, widely used, now you have a problem because it's a network system and you replace it. Everybody everybody has to replace it, which is why, you know, it takes such a long time to deploy replacements for h t p 1.1, or, you know, TCP or IP, before and everything else. It's it's all basically the same problem. It's something that was widely successful. Now it kind of hit the limits of what it can do, and, we actually suffer greatly from, the limits of, you know, the current system.

Avishai Ish Shalom [00:42:43]:
You know, you can see this with IPV 4, for example, but also with HTP. There are many reasons why we want to replace HTP. But rolling out a new version or something to replace it, it's actually a very big problem, which goes into backwards compatibility and, you know, actually having everybody install tooling, you know, to make it universal before they can actually use it, and then they'll start sending out the new protocol and and send to use it. So, really, that's the the problem. It's not that I don't think anybody, you know, argues that JSON is somehow good or, like, the the most optimized system or the best system or anything like that. I think everybody pretty much okay. Except AJ, maybe. But I think most people would agree that we can have better systems.

Avishai Ish Shalom [00:43:33]:
It's just a problem of how to work that.

Dan Shappir [00:43:38]:
It kind of reminds me if I if I I I recall a talk by Alan Kaye, whom I admire. He gave this talk something like 20 something years ago when when the web was starting to explode. And turns out that the web was really rubbing him the wrong way for a lot of the reasons that you were mentioning, Avishai. And he he showed a system built, surprise surprise, on small talk that was, sending messages and agents across the wire, and he replicated various web apps, what whatever web apps we had some 20 years ago, with his system. And he did an interesting comparison. He was showing measuring the temperature of the computer running a web based solution versus his solution, showing that his solution was running colder, much much more green, much more environmentally friendly. And his system was amazing. But, you know, looking at it, you know, there there was basically no chance because nobody was going to rip up the rip up the web and replace it with with a custom solution built on on, on small talk.

Dan Shappir [00:44:56]:
Regardless of how amazing LMK is and how great the technologies that he comes up with are.

Avishai Ish Shalom [00:45:02]:
Yeah. Because when you have a successful system, you need to have a very large advantage or a very large limitation of the coin in the coin system to, you know, to to to actually pay, you know, the very steep price of replacing the entire system. And it makes sense. This is why we have legacy. It's not a bad thing. But there are many, many like, the whole only a lot of reasons, a lot of, of the it's becoming more and more obvious that the code stack is is hitting the limits, and we need to start replacing it. You see this with IP before because we basically ran out of the rest of our space. So we have no choice at this point.

Avishai Ish Shalom [00:45:41]:
We have to replace it. Just takes a very long time. You see this with HTTP 1.1, though a lot of problems with it. So now we have HTTP 2 and HTTP 3, and, like, we're rolling it out as we go. And HTTP 3 is based on UDP, not TCP, again, because of the limits of TCP. And, now we are starting to see a movement to to get rid of TCP in data centers, to replace it with UDP based protocols.

Dan Shappir [00:46:06]:
I don't know if I call it the limits of TCP. Rather, various implementation decisions that made total sense in the seventies, and the networks that we had back then don't make sense anymore in today's cellular networks and and whatnot.

Avishai Ish Shalom [00:46:25]:
Exactly. And this is the thing. It's like whenever you make a design choice, there are no right design choices. That doesn't exist. What you have is a design choice that works and works well enough. And, you know that reality is going to change, you know, whether or not the because computers change or technology changes or the users change their mind or whatever. It doesn't matter. It's going to change.

Avishai Ish Shalom [00:46:47]:
At some point, you will have to change the system, and good protocols and good systems adapt. But there's a limit to how much you can adapt. Like, at some point, the basic, assumptions that you made about the system are going to be invalidated. And at that point, you know, the system is going to start hitting limits. And you can live with it for some time, but at some point, you will have to replace it. So when we build systems, you know, back in the day in the seventies, we didn't think about, you know, future proofing it, and we didn't think about sunsetting it and how you replace it with the next generation. Now we're smarter. We only know it's going to happen because, you know, we we have this experience of a system that became very successful, the Internet, and we we actually, got to be old enough to see it hit the limits.

Avishai Ish Shalom [00:47:33]:
So we are now aware of this problem, and we know that the next generation has to be future proofed. But, you know, we learned it the hard way.

Dan Shappir [00:47:42]:
Is it though? We will only know when we get there.

Avishai Ish Shalom [00:47:46]:
I'm pretty sure that we will have to to replace everything again in, like, 30, 40 years, if not sooner.

Dan Shappir [00:47:52]:
By the way, this is, I think we could talk on about this. You know, we can keep on talking about this, but

Avishai Ish Shalom [00:47:58]:
I think this is an actual

Dan Shappir [00:47:59]:
and opportune time to kind of pivot to one of the articles you wrote because it really ties into a lot a lot of what you're saying, which is the article with this amazing name, which is don't paint the roses, which is a reference to, a part in in Alice in Wonderland. Can you can you explain where this came from and kind of how it ties into what we're talking about?

Charles Max Wood [00:48:23]:
The song from the Disney movie keeps playing in my head every time we

Avishai Ish Shalom [00:48:27]:
Yeah. It's a great scene, by the way.

Charles Max Wood [00:48:29]:
Anyway. Yeah.

Avishai Ish Shalom [00:48:31]:
So there was scene in Alice in Wonderland, this diversion from, I think the forties, right, or the fifties?

Charles Max Wood [00:48:37]:
Yeah. So by

Avishai Ish Shalom [00:48:38]:
the way, they painted. They actually painted all the frames by in, by hand. And the in the scene, you see, the crowd soldiers, you know, painting the rose bushes. They're painting them red because they accidentally, planted the the white, roses, and the queen wants them to be red. So they just paint all the roses. And the problem with this is that, you know, at some point, the the queen comes, and she discovers that the rose bushes were painted, and she, you know, goes off of their heads. And, all the cards lose their heads, which is very unfortunate to them. And,

Dan Shappir [00:49:21]:
Would never happen in a modern Disney movie.

Charles Max Wood [00:49:25]:
That's true.

Avishai Ish Shalom [00:49:27]:
So the thing is that we actually have a lot of painted golden bushes around us in reality. It's like something that we try to force into a form, even though the the call of it, like, the the essence of it is very different. And this is, you know, a lot to do with the industrial mindset of the designer mindset versus the organic mindset or the agriculture mindset. If you are trying to grow something, something that is organic, you can't actually control what it will grow into. You you can, you know, kind of try to, to direct it.

Dan Shappir [00:50:08]:
You can influence it.

Avishai Ish Shalom [00:50:10]:
You can direct it. You know, you can you have, like, for example, bonsai is a very good example where you trim the the roots to make it and then the tree to make it in certain shape and certain size. So you can constrain it somewhat and direct the growth, but you can't actually change the essence of it. A bonsai tree will always look like a tree no matter what you do to it. And the industrial mindset is is a designer mindset where you design something and you can actually force it to be that thing. And if it doesn't work that way, you can just destroy it and start over. So, the problem we have in modern society is that we are an industrial society. And when we get to organic situations, we try to handle them into a certain form, even though, you know, it's organic.

Avishai Ish Shalom [00:50:59]:
And a very good example of this is, you know, organization building. Organizations are organic. You can't just decide that, you know, they're going to be in a certain way. But, you know, if you've been in corporate and and you've lived through, you know, one of those organizational restructuring programs, you know what I'm talking about.

Dan Shappir [00:51:21]:
And it kind of has to do with with what we were talking about before about legacy systems and legacy protocols where, certainly, you can say that a lot of the web has evolved more than it was designed. I think there's an excellent quote that I love in the HTTP spec, which basically says, we recognize that a lot of what is written here is kind of doesn't make sense and is even nonsensical. But it's that's the because it evolved more than it was designed, and a lot of of, the street teams were working on it and working without, proper synchronization and stuff like that. So it kind of grew organically rather than being designed to certainly not top down. A

Avishai Ish Shalom [00:52:05]:
lot of RFCs actually describe the factor protocols, which will later codify the NRCs rather than having them, you know, designing the protocols, documenting them in NRCs, and then implementing them. It was actually backwards.

Dan Shappir [00:52:19]:
Well, if you think about what RFC stands for, it's a request for what is it?

Avishai Ish Shalom [00:52:26]:
Comment.

Dan Shappir [00:52:26]:
For comment. It's basically it's not here's the spec. It's basically, I've got an idea what do you think about it. And and, you know, this request becomes codified as as the actual specification.

Avishai Ish Shalom [00:52:41]:
Yeah. So it turns out that, basically, the web is a is a network of consensus. It's not so much a design network as it is in a organic network that evolved, and we we somehow got to a consensus about how it should work. A few years back, you had an incident where CloudFlare actually did something according to the RFC, according to the spec, but everybody else was using it differently. And this created basically an outage in in part of the services. And after they discovered it, they fixed it in the sense that they now conform to everybody else, which means that they violate the spec. So this is basically how they enter the pools. We put the consensus.

Avishai Ish Shalom [00:53:22]:
It doesn't work by specification.

Dan Shappir [00:53:25]:
Anyone who's ever wondered why user agents look the way that they do.

Avishai Ish Shalom [00:53:31]:
Mhmm.

Dan Shappir [00:53:33]:
I remember when, Microsoft released a new version of, what was it, a certain version of, what's their browser's name, Edge, and they broke, Office 365 on Edge because, they actually used the proper user agent, but that confused their detection protocol. So they had to put in a wrong user agent yet again just in order to get things to work right.

AJ O'Neil [00:54:06]:
The wheel of time keeps coming around and around.

Dan Shappir [00:54:12]:
But how do you deal with it? I mean, you know, at the end of the day, we are very often forced to paint the roses because we need to deliver something on time, within budget, and and we don't have the time to grow a new solution and make it conform to whatever we already have?

Avishai Ish Shalom [00:54:33]:
So it's it's it's a mindset, actually. First of all, it's it's a conversation you wanna have with, you know, the product manager and the business people because, it's it's optimizing for the long range, really. So even if you are forced to paint all of those bushes, you want to have some kind of an escape hatch. You want to be prepared to the eventuality where, you know, someone will find out this is actually paintable. You because once someone discovers this, there will be consequences and they will not be nice. You know, it can be off of your head at some point. So if if you adopt this mindset of organic growth and you understand that as a designer, you're actually looking for experimentation, You're looking for, few future proofing. You're looking for escape hatch hatches.

Avishai Ish Shalom [00:55:28]:
You're looking for, minimalistic design. So a good design is one that doesn't make decisions and doesn't have to.

Dan Shappir [00:55:37]:
You can give concrete examples going either way.

Avishai Ish Shalom [00:55:42]:
For what?

Dan Shappir [00:55:43]:
Can you give concrete, examples of either where, painting the the roses ended in disaster or, or convert or conversely was

Avishai Ish Shalom [00:55:56]:
done successfully. Yeah. So I can give actually a lot of examples of this. So, okay, let me let me tell you a story, actually, if we won't go into that specific work. So you know how we could talk about DevOps, for example. DevOps is a very good example. DevOps is a classic painted walls bush because, it started out as something organic. You know, we had this movement that, you know, said, look, we have this problem within operations and then developers that don't understand each other.

Avishai Ish Shalom [00:56:40]:
It was like structural problem in organizations, the structural problem in the software stack where we have parts that don't, you know, connect to each other. And then we, you know, we started trying to solve this problem. And then someone says, okay. You know what? Let's invent a new profession. We can call it DevOps. Let's invent DevOps tooling. Let's invent the DevOps team, the DevOps engineer, blah blah blah. And now we have a paintball bush because we try to design solutions that are growing organically.

Avishai Ish Shalom [00:57:14]:
And it got them so bad that now people talk about DevOps, you know, not interacting with ops or devs. So we have the, like, DevOps Amen. Problem. You you can call it. And you have tools that are trying to solve the problem where DevOps tools don't communicate well with DevTools or OpsTools, which is, like, completely ridiculous.

AJ O'Neil [00:57:40]:
Yeah. It is. It's like

Avishai Ish Shalom [00:57:43]:
it it's it's it's it's

AJ O'Neil [00:57:46]:
like it was a buzzword that was created to sell AWS certificates, and you end up with all these people who create these layers of infrastructure that don't help the developers. Developers now have to wait, you know, 15 minutes for their deploys to get through. Yeah. Oh, this is Yeah. I'll shut up now because this is one of my

Charles Max Wood [00:58:05]:
Yeah. But but Avishai's point, it was originally this movement to bridge the gap between, like, infrastructure and code and make it manageable so that you could communicate about this stuff and the way you communicated about the stuff and the way you set up your your your people and your processes, and that's what it got co opted into. Right? That's Yeah.

AJ O'Neil [00:58:27]:
Yes. Yes. Yes. Sorry. I I think, the Phoenix project still used it in the sense in which it was intended. The book this the the it's called the is it the Phoenix project is the name

Avishai Ish Shalom [00:58:40]:
of the

Dan Shappir [00:58:40]:
book Yeah.

Avishai Ish Shalom [00:58:41]:
I think.

AJ O'Neil [00:58:42]:
That that one talks about DevOps in in the actual terms of what DevOps is supposed to be, like, partnering with the development team and the operation team to pro to understand both sides and provide tools that facilitate quicker and more efficient yeah.

Charles Max Wood [00:59:00]:
Yeah. Agile development.

Dan Shappir [00:59:02]:
That's the

Avishai Ish Shalom [00:59:02]:
same thing happen. Yeah. Phil Nando is a very good example.

Dan Shappir [00:59:07]:
Another interesting example I'm seeing and running into is the whole concept of shift left in development where you say instead of having dedicated QA and automation teams, we let the developers do the automation and be responsible for the testing, which is great on the one hand, but on the other hand, results in situation where nobody owns or is responsible for the automations. And then when something breaks, nobody knows how to fix it.

Avishai Ish Shalom [00:59:36]:
And it's also very weird because, you know, if you have a process and you shift everything left, you know, you still end up with something in the right. You know? You shift all the dominoes left, you still have a a series of dominoes. Like, something's gonna be on the other side.

Dan Shappir [00:59:54]:
Yeah. Yeah. Before we're done, I really want to touch on the other post as well. We are running we're starting to run towards the end, but I'd really like to to spend a few words on that. And that's another post with a great name, and it's called the marshmallow effect.

Avishai Ish Shalom [01:00:13]:
Oh, yeah. So the marshmallow effect basically is, stuff that has the, you know, the original name, but, doesn't actually have any of the original ingredients. So most people don't know, but marshmallow was originally made from a marshmallow plant, marshmallow root. And, obviously, you know, nowadays, marshmallow is made from, cold, soy, syrup, and, and and sugar, basically. And it doesn't actually have the taste yeah. I don't think it doesn't actually have the taste of of extra marshmallows. Some places in Europe, you can still get the little stuff. Like, it's very hard that you can still get it.

Avishai Ish Shalom [01:00:52]:
But those, in the food industry, it's actually very common. A lot of the stuff that the industrial stuff we eat today, like, still has the same names as the originals from a 100 years ago, but doesn't actually but it's not the same thing. Doesn't even taste the same.

Dan Shappir [01:01:05]:
I I remember growing up because

Avishai Ish Shalom [01:01:07]:
they never ate it.

Dan Shappir [01:01:08]:
I remember growing up in in the in the, what was it? Like, in the eighties, in in the States, there was this, lemon lemonade called, old fashioned country lemonade or something like that, which had 0 lemons in it. And and, yeah, I remember how shocked I was by that.

Charles Max Wood [01:01:28]:
For some you were gonna say that you used to drink cocaine in your Coca Cola.

Dan Shappir [01:01:33]:
Yeah. Yeah. I didn't get to Or wonder bread.

Avishai Ish Shalom [01:01:37]:
Wonder bread. To another wood one. In this one, we have something called sahla, which is like a Turkish drink, which was made from sahla plant, but, obviously, now it's not. And, like, yeah, I still remember the original saffa, but people who, like, you know, grow up now, they they never actually tasted the saffa. They think that what they're drinking now is saffa. It's not. But you also see this in in technology, and I think the cloud is a very good example. You know, people talk about, like, disks.

Avishai Ish Shalom [01:02:09]:
EBS is not a disk. It's fine. It looks like yeah. I mean, it looks like a disk. It has, you know, some fake blocks and stuff, but it's it's not actually a disk. It's not magnetic or SSD or anything like it. It's just the name that the AWS puts on to tell you that this has certain IOPS and certain speed in building But

Dan Shappir [01:02:27]:
that's kind of intentional with with virtualization. The whole concept of virtualization, virtual memory going back to virtual memory is the fact that, you know, virtual memory is not memory. It's files on a disk. But it's it's it's one thing that's intentionally created to look like another for Verizon.

Avishai Ish Shalom [01:02:46]:
Well, it's it's backwards compatibility, but that creates a lot of interesting problems because first of all, it impacts, how people think about the system. So, I'll give you an example. People often debate whether they should use s 3 or EBS or EFS, which is like NFS, and then they're like, oh, but this so, you know, have these features or the the app speed or whatever, and and it's so long because, actually, s 3 and EBS are you know, they're actually the same machines doing storage. EFS is basically, like, the same, with the ZBS except the protocol that you use to communicate with it. And so the real question is not, you know, if it's like disks or or something else. It's like how many IOPS they're getting, and and do you like this protocol that you're using to to talk to this, source server? That's what you should be, you know, talking about, really. But people have because they don't understand that this is actually all the same storage just presented in a different way. And you have a similar problem with VPC because, you know, it's, again, backwards compatibility, which you don't actually need in the cloud.

Avishai Ish Shalom [01:03:54]:
You know? I I had this conversation with one of my clients where they, you know, consulted me about, network design. Like, okay. So how many subnets do we need to do, and do we need to put all the, you know, this application on the same subnet? And I was like, but, you know, it's not like just because you have the same subnet doesn't actually mean everything in the subnet is physically close. It's not good to have no better latency or anything like it. You know? It's all public network, the entire zone. You know? It's like it doesn't matter if you if you use, like, one subnet, 20 subnets. It's still going to be the same same, you know, under underlying structure that you have no idea about.

Dan Shappir [01:04:34]:
So if I'm if I'm understanding you correctly, what you're saying or even lamenting is the fact that we create these sorts of virtualization layers that are kind of lies, and we do that to, ease transitions, let's say, between systems. But at the end, we end up lying to ourselves because we're carrying over mindset and, you know, certain assumptions of how things work when they don't actually work that way at all anymore.

Avishai Ish Shalom [01:05:02]:
Yes. And here's what's interesting because, I'm from the generation that actually use data centers. I install data centers, and I I worked in data centers, and I know that stuff very well because I actually interacted with physical machines. But now you have a generation that started their careers in the cloud with virtualization. And now they're basically eating marshmallows, and they never actually tasted the real stuff.

Charles Max Wood [01:05:28]:
You're making me feel old. My first, full time tech job or not full time. It was part time. But I was a when I was a student at BYU, I was working in the data center, and the server was a server. It was a machine. Right? Some of those machines were like they take up a whole freaking cabinet. And then, right, by the time I left, now we had servers that were we had these servers with blade servers in them. Right? And so it was a this it was a box that had a bunch of computers in it, but then we had VMware installed on those.

Charles Max Wood [01:06:03]:
And so then a server was this virtual thing that lived on this. Right? But you still knew which server your server ran on. Right? And yeah. Anyway, it's it's been really

Avishai Ish Shalom [01:06:16]:
And then talking about VMware evolved.

Dan Shappir [01:06:19]:
And then VMware introduced VMotion, which allowed them to move those VMs between machines without Yeah. Just seemingly without downtime. Mhmm. And then we got to the cloud to the actual cloud where you literally have no idea where your Lambdas are running.

Avishai Ish Shalom [01:06:35]:
Right. And, also, I have very interesting discussions between people about, you know, the same, like, containers are more efficient, VMs are more efficient, and it's, like, very little discussion because it's all the same stuff.

AJ O'Neil [01:06:45]:
Yeah. And we we've got this problem. Like, Docker is recreating the very problem that it was intended to solve. So, for example, the Blue Sky self hosted installer requires that you run on Ubuntu so that it can install all the things that need to be installed to install and configure Docker so that when you install the packages

Avishai Ish Shalom [01:07:11]:
Oh, that's hilarious.

AJ O'Neil [01:07:12]:
In the container in a predictable way. It's like, well, why didn't you just say Blue Sky only runs on Ubuntu, or you need to follow you need to install these 10 packages on your own. Right? But now but now it's like I have to so in my container, I have to have nesting so that I can run Debian, so that I can run the Docker, so that I could run Debian. Like

Avishai Ish Shalom [01:07:36]:
Yeah. So we moved from it runs on my machine, so it runs on my container. But, basically,

AJ O'Neil [01:07:41]:
it's a Yeah. Yeah. Yeah. Yeah. We can't ship your machine to to the client, but we ship a clone. And still nobody knows what's going like, that this is the thing I always say. So I that but that you know, the problem with Docker is not Docker. Docker is a great technology.

AJ O'Neil [01:07:55]:
It's a technology. The doc the problem with Docker is that it just moved the goalpost to no one understands why my machine works. We'll ship a clone of the machine to no one understands why the Dockerfile works, will ship oh, well, and then you don't even get it because it's hosted on Docker Hub. So you don't even get to see the Dockerfile. So you don't even know how to recreate the container at all. So we're actually worse off because at least before, you could kind of, like, look at the history on the machine. Now you get a container where all the history is stripped out and you don't know how it got there.

Charles Max Wood [01:08:27]:
Well, they do have the layers and things like that. But what's fascinating about it is that, and it should work anywhere, but, yeah, you know, it it does make assumptions about how your Docker's set up on your machine.

Dan Shappir [01:08:39]:
I don't know. Twist,

AJ O'Neil [01:08:41]:
then it's a go binary and it didn't need any of it anyway.

Dan Shappir [01:08:44]:
Yeah. I'm ashamed I'm ashamed to say that I've managed to have a pretty good tech engineering career without, you know, truly understanding the finer details of Docker.

Avishai Ish Shalom [01:08:54]:
But it's

AJ O'Neil [01:08:54]:
just a Linux process group.

Avishai Ish Shalom [01:08:56]:
Yeah.

AJ O'Neil [01:08:56]:
It it it's just a process group. It's it's just like forking from a process, but with more kernel level security.

Dan Shappir [01:09:02]:
Oh, that that

Avishai Ish Shalom [01:09:03]:
that part of the I wanna make a shameless plug. Like, about a decade ago, Nati, Cohen, and myself, had a workshop called the Rabble Docker or Docker from Scratch, where you write your own Docker clone in Python, and you basically implement Docker using, you know, Linux system calls, like like, clone fork and, like, all of the file system and the namespaces and cgroups and all that stuff. So it actually gives you a pretty good idea of how Docker works under the hood. It's all open source. It's in GitHub. You can put links to it later if you want.

Dan Shappir [01:09:39]:
Yeah. I would love it. Cool. Nati is great. He even though he he's moved over to the dark side, I think he's working at AWS now. Okay.

Avishai Ish Shalom [01:09:47]:
And

Dan Shappir [01:09:47]:
we should probably have him on the show as well. Also, Karen, his wife is pretty amazing as well. Anyway, I'm digressing.

Avishai Ish Shalom [01:09:57]:
Yeah. I I just wanted to say about, Docker. It's a very good example of, like, how the discussion kind of trailed off, like, in the community because we had this tool. Because really the problem is that Docker is not container. It's it's reproducible bills.

Charles Max Wood [01:10:13]:
Mhmm. Yep. Which when you think about it, yeah, then then you start you start like, my brain started going to other places. Right? These are the other tools that I've used to solve similar problems.

Avishai Ish Shalom [01:10:28]:
Mhmm.

Dan Shappir [01:10:28]:
Yeah. Yeah.

Charles Max Wood [01:10:32]:
Alright. Well, is there anything else that we wanna kind of kick around, diff different marshmallows to kick around or conversations to paint red before we

Dan Shappir [01:10:42]:
Now now you really want you you got me to really want to try out real marshmallows.

Charles Max Wood [01:10:48]:
I know. I'm curious too now.

Avishai Ish Shalom [01:10:52]:
Yeah. Yeah. It's it's not too fun, but to find them is very interesting.

Dan Shappir [01:10:57]:
The funny thing is when you find one of the original things and then you modern ketchup, for example, has nothing to do with the original ketchup.

Avishai Ish Shalom [01:11:11]:
Do you know the story about ketchup in Israel? Right?

Dan Shappir [01:11:14]:
Yeah. Yes. I do. But you can tell it. It's a really weird one that shows how bureaucracies work and how business interest in bureaucracies can go hand in hand.

Avishai Ish Shalom [01:11:24]:
Yeah. You tell it.

Dan Shappir [01:11:25]:
So, basically, in Israel, we have a local brand of of ketchup. And then a certain point in time, they started to somebody started to import Heinz ketchup. And so and that was it was starting to eat into their market share. So what they did is they changed the legislature on what can be legally termed as being ketchup. In such a way, that Heinz ketchup could no longer be called ketchup in Israel. So instead, it's called sweetened tomato sauce or something, and and they got to keep the the term ketchup for themselves. But it didn't really help them anyway because people just bought Heinz regardless of of what it was what it said below the the the Heinz moniker.

Charles Max Wood [01:12:17]:
Oh, that's so funny. Points for creativity, though.

Dan Shappir [01:12:23]:
Yeah. Getting to the point where Heinz ketchup can't be called ketchup.

Charles Max Wood [01:12:28]:
Yeah. Well, I found a a thread on Reddit, but yeah. Oh, alright. Well, I'm gonna push this into pics. AJ, do you wanna start us off with pics?

AJ O'Neil [01:12:43]:
Goodness. I don't know. Sorry. I I actually, today, don't have anything top of mind. I I'm gonna need a minute myself.

Charles Max Wood [01:12:52]:
Alright. Dan?

Dan Shappir [01:12:54]:
Okay. So I actually have a a pick I'm really happy about, and it's this new TV show called the penguin. It's about this, Batman character, by one of the Batman's villains. And what can I say? It's it's just an amazing show. And and so far, by the way, Batman makes zero appearances. There's no mention of superpowers or anything like that. They do make occasional references to the latest Batman movie, but it's really subtle. Colin Farrell is absolutely amazing as, the pig win.

Dan Shappir [01:13:36]:
He's totally unrecognizable. The the the makeup, the prosthetics, I understand he even shaved his head for the role in a in a certain way. But his acting is just it's James Gandolfini level, really. It's he's he's giving the the performance of his life, I think. Highly, highly recommended. So that would be my my first pick. Everybody else there, by the way, the is the acting is good all around, but he's he's just he just stands out. I I really hope they're they're able to maintain, the this quality all the way through.

Dan Shappir [01:14:12]:
I'm kind of halfway through the 1st season.

Avishai Ish Shalom [01:14:14]:
I think it's the only season so far, and I really hope it doesn't get canceled or anything like that.

Dan Shappir [01:14:21]:
So that would be my first pick. 2nd pick is, I I I created an account on on Blue Sky. So if you, for some reason, have left x and are on Blue Sky, then you can follow me now there as well. Even part of a pack, there's a web performance pack, and I'm on there. And it's it's very much like x. You know? It's if anything, it's kind of like what x kind of used to be, in a lot of ways. The the algorithm feels less intrusive, which is a plus. The weird thing to me, especially as in kind of an an outsider to US politics, is the interesting fact that there's kind of a political divide between those people who stayed on on x versus those people who went over to Blue Sky.

Dan Shappir [01:15:11]:
They're they're kind of saying that they went over to Blue Sky because they were thick of the politics and wanted more pure technical stuff, but the politics really still pine through. It's just a certain aspect of politics. And and I'm not criticizing either ones, you know, but I'm just it's just a shame that that people really you've gotten to the point where they can't talk with each other to the extent that they feel that they need to be on different social networks. But I'm still on both, and you can find me either place. It's kind of annoying to have to post things twice. I I think there are tools that should make it easier for me, and I'll probably need to adopt 1. But right now, I'm still kind of posting on at both places. And those are my picks for today.

Charles Max Wood [01:16:01]:
Awesome. AJ, did you wanna jump in, or should I go?

AJ O'Neil [01:16:06]:
Oh, I'll just come up with something. I I think I mentioned before that I'd played portal a few weekends ago and got all the way through it for the first time. And, actually, most of the quotes that I remember were from portal 2, not portal. So that's still to come. But if you haven't played portal and you want a game, you can just sit down and play in a matter of a few hours. The companion cube bundle is available on, Nintendo right now until December. We're not even gonna release by the anyway, check deku deals dot com. Keep your eye on deku deals dot com and and find out when games you love, go on sale and get them there.

AJ O'Neil [01:16:46]:
But portal is it's definitely worth it. If you haven't if you haven't played it and you just know the references, the cake is a lie, that sort of stuff. Yeah. It's a little bit morbid to play with a 5 year old. Like, the first ten levels are fine, and then all of a sudden there's blood on the wall. And my daughter's like, why is the blood on the wall? That's all.

Dan Shappir [01:17:09]:
How does she recognize blood? Can't you just tell her it's ketchup?

Charles Max Wood [01:17:14]:
Or tomato seasoning?

Dan Shappir [01:17:15]:
They They were eating hamburgers, and, they

AJ O'Neil [01:17:17]:
were I don't I don't lie to my kids, and I don't baby down explanations when my 3 year old It's

Dan Shappir [01:17:25]:
it's red pixels.

Avishai Ish Shalom [01:17:27]:
Yeah.

AJ O'Neil [01:17:28]:
But okay. Fair. But it's representing. It it is it is not representing ketchup, but it's representing black.

Dan Shappir [01:17:35]:
I It's it's it's white roses painted red.

AJ O'Neil [01:17:39]:
Well, with with my kids

Charles Max Wood [01:17:41]:
White roses

Avishai Ish Shalom [01:17:41]:
painted red.

AJ O'Neil [01:17:42]:
Even my 3 year old, when he asks a question, I will answer his question like an adult. And sometimes he will then ask, well, what does this word mean or what does that word mean? And our daughter, you know, she asked, what does this word mean? What does that word mean? I am waiting for her to ask, where do babies come from? It's it's gotta come soon. But that one's gonna be a very I don't I don't know how to that one, I'm not gonna say it like I would to an adult, I don't think. But,

Dan Shappir [01:18:09]:
I'll say I'll I'll tell you this story from my childhood when I was, like, 7 or something years old, somebody used the word prostitute around me. So I went home and I asked my mother, mom, what does the word prostitute mean? And she being having the similar mindset to yours said, it's a woman who sleeps with men for money. And I couldn't figure out for the life of me why somebody would pay someone to sleep with them because it's so uncomfortable to have to share a bed with somebody. You know, you don't have much space. And, yeah, I just couldn't figure it out. Anyway Well, when I

AJ O'Neil [01:18:48]:
was 5, I asked my dad, and my dad told me in as as least graphic terms as he could. And I just thought that sounds so weird and gross. But then when I was about 13, I was like, got it. Alright.

Charles Max Wood [01:19:06]:
I'm gonna throw in some picks. I always do a board game pick. I don't think I I'm trying to remember if I picked this game last week or not. Maybe I'll just pick a different one. So, not this last Saturday, but the Saturday before, I was helping teach games at the game board game convention. Right? So I have 5 or 6 games to be taught. I've already picked challengers on here, because I picked that. I played that game at Salt Con in March, and that was one of the games we taught.

Charles Max Wood [01:19:37]:
And there's another version of the game called, Challenger's Beach Cup, which is the same rules with different cards that have different abilities. So I I feel a little bit funny just picking either of those because you guys can go pick them up, and and it's it's plenty fun. It's, you know, the tournament war flag thing. You can go listen to the previous pick. So I'm hoping I didn't pick this last week, and if I did, I apologize. But probably one of my favorite games that we taught this time is called, gnome hollow. You guys aren't looking at me like I picked this last week, so I'm gonna go with it. So, effectively, it's, you're playing a game where you're placing, hexagonal pieces on the board, you know, so you push them together, and they create a path.

Charles Max Wood [01:20:30]:
And if the path creates a circle or a complete circuit because a lot of them aren't circles. Right? They they curve at the front angles. We have to get them all to align. You can't create anywhere it it dead ends on another piece. So if you put it down, it has to continue any paths that it crosses. But you make these circuits, and then as you create the circles, what happens is, you move markers on your board that's in front of you down, and you get a reward for it. Now the threes and the fours, you don't get rewards for. The fives, you get rewards.

Charles Max Wood [01:21:04]:
Sixes, you get rewards. And the sevens, you get rewards. And 2 of the spots on the sevens, one of 2 of those rewards are you get to move another marker down, and then you get something else with it. The game ends when all of your markers move down or when you run out of tiles. And then you add up your points, and whatever points you have, you win. So, you get points for each marker you've moved down. Right? And it's just you know, you get all all of them down. It's worth 25 points.

Charles Max Wood [01:21:35]:
As you complete circles, you discover wildflowers, and you automatically get one of those wildflowers, and you get a wild token that you can use anytime on your turn. And then what some of the rewards are, you get the wildflowers that other people discovered. And those tally up, you you get so many unique ones. Right? And so if you however many flowers you get your points for that. And then as you complete the circles, you get the mushrooms that are on the circles. Or there are other ways to get mushrooms, but you get those mushrooms, and then you can go to the market and sell them back, and you get points in return. And that's essentially the game. There are a few other nuances, but it is really, a fun game.

Charles Max Wood [01:22:16]:
It takes about 45 minutes to play, and, BoardGameGeek, weights it at let's see. It's coming up. 2.20. So casual gamers is pretty approachable. You know, it's it's really just visualizing how your tiles get you the size of the the the circle you want. And you move gnomes around to claim circles or to, you know, get mushrooms or go to market. That that's the other piece to it. You have 2 gnomes,

AJ O'Neil [01:22:49]:
that you you you can move each turn.

Charles Max Wood [01:22:51]:
So, that's, I mean, that's it. That's the game. It's it was, like I said, really fun. When I was teaching people, it'd take an hour, but, honestly, with 3 or 4 people, we were still, you know once people knew how to play, it was, like, 45 minutes. Because the turn order is real quick. You you put down 2 tiles, you collect any rewards, you move your gnome. Do whatever is involved in moving the gnome, next person's turn. So, anyway, so, yeah, so I enjoyed that.

Charles Max Wood [01:23:22]:
It's one that I kinda wanna buy, so I'm gonna go ahead and pick that. The other thing that I'm gonna pick here so I am actually on my new computer. The my laptop it's funny we're talking about Docker, the the Docker engine on the Mac. When I was running it, one of my clients' apps on it, it just got to the point where it just wasn't it worked, but it was super slow. And, so I determined that I needed, you know, the the the laptop 6 years old. And it just, yeah, it just wasn't keeping up. And no matter what I did to try and clear stuff off or not run as many things, it just didn't quite hack it. So, I looked around, a new Mac at the level that I wanted because I'm starting to do AI stuff, and I want to I want it to be able to run that stuff, and and then it really bogged down.

Charles Max Wood [01:24:22]:
The laptop did. I'm like, okay. So so the machine at the level I wanted, a new Mac was gonna cost me, like, $9.

Dan Shappir [01:24:29]:
So you want you wanted something like an M4 or something?

Charles Max Wood [01:24:34]:
Yeah. Something. So what I wound up doing was I looked around and I thought, okay. Well, a lot of folks in the Rails community are talking about these Linux machines that they're picking up. So, the laptop brand that a lot of people are going with is framework laptops, and they run Ubuntu or whatever whatever you want, really. And then, for the desktops, they they've been going with system 76. And so that's who I'm gonna pick is system 76. I got a desktop from them.

Charles Max Wood [01:25:02]:
It cost me about $3.

Dan Shappir [01:25:07]:
That's still hefty.

Charles Max Wood [01:25:09]:
Yeah. But it, I I can't remember all the specs on it, but it's it's it's a pretty serious machine. And it You got more

AJ O'Neil [01:25:19]:
than just 1 terabyte of storage for that 3 grand, unlike on Apple. Right.

Charles Max Wood [01:25:25]:
So I got the the Thilio model.

Dan Shappir [01:25:32]:
What CPU does it have, by the way?

Charles Max Wood [01:25:34]:
I'm I'm looking it up right now. So it has I can probably just pull up my order.

Dan Shappir [01:25:43]:
Probably some AMD or something.

Charles Max Wood [01:25:45]:
Yeah. It does have an AMD. Let's see. I got the Thilio Mira Elite as a 24 core 14th gen Intel I9.

Dan Shappir [01:25:57]:
Oh, Intel. Cool. Interesting.

Charles Max Wood [01:26:00]:
Has a 128 gigs of RAM, 4 terabytes of storage, AMD Radeon RX 79100 GRE. Yeah. So I I've been pretty happy, running stuff on it, and it you don't void the warranty if you have to repair it or add cards to it or anything.

Dan Shappir [01:26:26]:
It's not Apple.

Charles Max Wood [01:26:27]:
Nope. It's not Apple. And it cost me about $7 less than what it cost me to get a comparable Apple machine that did, you know, that had mostly similar specs.

Dan Shappir [01:26:38]:
And you're running Ubuntu on it?

Charles Max Wood [01:26:40]:
I'm running Ubuntu on it. Interesting. I wanted to run the Omacube setup, which is what DHH runs, but I would have had to reinstall Ubuntu, and I'm lazy, and I didn't wanna do that. So I'm not doing that. But, I also switched my development environment back to EMAX, and I've been pretty happy doing that. So, anyway, it's it's been super

Dan Shappir [01:27:05]:
That's cool.

Charles Max Wood [01:27:06]:
Oh, yeah. I I love me some e max. I had the e max key bindings running on Versus code, so it really wasn't too much of a switch. The biggest switch is remembering to hit control instead of command.

Dan Shappir [01:27:18]:
And running writing scripts in this.

Charles Max Wood [01:27:22]:
Yeah. Well so that's that's my 3rd pick. So, I part of getting into AI, I kind of, on a lark, started asking chat GPT to help me write code. Right? And before, what I would do is I would ask it, hey. Like, when I I was trying to write an audio player. Right? And and so I would ask it to help me. Okay. How do I you know, what's the web, audio API for, you know, if I click a button to have it play the audio? Because you can just put the audio tag in, tell it to show controls, and you get an audio player.

Charles Max Wood [01:27:59]:
But it's not a very nice audio player. Right? It doesn't have all the features that I wanted. And so, you know, I I started asking, how do I get this? How do I get that? And then on a lark, I said, can you write me an audio player? I'm using Stimulus JS. And it wrote it for me, and then it was like, okay. I want this feature and this feature and this feature, and it added them in. And then I asked it, what features is it missing? And it told me a whole bunch of features I could ask for. And so I asked it for those, then I copied and pasted the whole thing into my app. And wouldn't you know it? It just worked.

Dan Shappir [01:28:29]:
So, you know, as a spoiler, we're gonna have uncle Bob as a guest on the show in the in the near future. Maybe we should also get Richard Stallman if he ask him if he's willing to come on the show.

Charles Max Wood [01:28:41]:
I'm open to that. I think it'd be great. Yeah. The the other thing that, I've been doing with, Chat GPT is just sometimes I just need a little bit of direction here or there with stuff, and it's it's been great there too. So I'm gonna pick, ChatGPT as well. I I might be a little late to the game there, but it has been this amazing, tool. It's helped me with layout stuff. One thing that I'm working through right now for my client is they have a report essentially that's generated every every time a new transaction's added to their ledger, and it takes forever to run.

Charles Max Wood [01:29:21]:
And so I've been playing with it on how do I run this, how do I run this report just in PostgreSQL? And so, I mean, it's been a lot of there's a lot of refining. Right? It's like, okay. I need it to do this now, and I need it to do this, you know, I need it to operate in this way, and it's it's been pretty awesome. I mean, I've had to tweak a few things, but it's been, yeah, it's been wild. So if it's not a tool you're using, I understand that Claude is another tool that you can use. We just recorded an episode on Ruby Rogues where we were talking about how to do a lot of this stuff. And a lot of the things that we talked about are applicable to JavaScript as well, just on how how the tools work and what some of the tools are. Some of them are Ruby specific, but a lot of them really aren't.

Charles Max Wood [01:30:13]:
So, anyway, yeah, I'm really, really happy with all that. And, I am working on the, AI Dev Boot Camp. That's gonna be at aidevbootcamp.com. I'm redeploy I'm reworking a ton of stuff on top end devs and getting that deployed, And so you'll be able to sign up as soon as I get that deployed is essentially what we're looking at. So, right around Black Friday or Cyber Monday, and I kinda have a number of people that I want in the first cohort. And so I think I'm gonna offer a Black Friday deal that's gonna be just considerably less than what I'm gonna charge for it in the long run just so that I know, hey. I've got about 20 people in that are going through the boot camp starting in January. So keep an eye out.

Charles Max Wood [01:31:02]:
If you want to, you can just email me, chuck@topendevs.com, and I can just tell you when it's up or, you know, however you wanna do that. But, yeah, just just some way awesome stuff there. Alright. Avishai, what are your picks?

Avishai Ish Shalom [01:31:20]:
I'm gonna go with, I recently discovered Malimo. Malimo is, like, the next generation, replacement for, Jupyter Notebook. So it's like a kind of a interactive, Python environment that is also graphical. So we basically, evaluate cells, or can combine markdown and graphics and then and Python output and stuff like that. It's very handy to build widgets or calculators. Most of what I build with it, I built, like, QN theory calculators and, like, various system design things that, basically, you can put, like, the bars and inputs and then, like, just runs the Python thing. So it's very easy for doing interactive, interactive stuff, especially that involves, like, graphing and, and mathematics, like, other stuff. Previously, I used Versus Code and Jupyter Notebook for this, but now I'm always like it's really cool.

Avishai Ish Shalom [01:32:19]:
So check it out.

Charles Max Wood [01:32:21]:
Nice. Yeah. A lot of people do an interesting stuff in AI with Jupyter Notebooks, so that sounds interesting. Alright. Avishai, if people wanna find you on the Internet. I see that your handle's on your video, but for the people who aren't getting this on video, how do they find you?

Avishai Ish Shalom [01:32:38]:
So, Nukenberg on Twitter. That's nukenbelg. Mostly there. Also, I have a YouTube channel, which is not very active, but, it does contain, like, a playlist of a lot of talks that I've given over years. Or you can just Google Avishai Shalom or YouTube or, you know, Google, and you can find that stuff.

Charles Max Wood [01:33:00]:
Awesome. Alright. Well, let's go ahead

AJ O'Neil [01:33:03]:
and wrap it up. Until next time, folks. Max out.