Speaker 1: Hey, welcome back to another episode of JavaScript Jabber.
Speaker 2: This week, on our panel, we have Dan.
Speaker 3: Shapier, Hello from Tel Aviv, which is actually cold, even
Speaker 3: though it's probably pretty warm by your standards.
Speaker 2: He says cold.
Speaker 1: It is below freezing here, or at least was this morning.
Speaker 1: And we also have a j O'Neill.
Speaker 4: Yo ya yo coming at you live from the wonderful,
Speaker 4: wonderful shed.
Speaker 2: I'm Charles Maxwood from Top End Devs. I am jealous
Speaker 2: of your shed.
Speaker 1: We have a special guest this week, and that is
Speaker 1: Avishai is Shalom.
Speaker 2: I hope I got close on that. I'm sorry if
Speaker 2: I didn't. So yeah, I've thought very deeply about putting
Speaker 2: something like that in the back of my house.
Speaker 1: Anyway, Dan, you invited Avishai here, and it seems like
Speaker 1: you know each other pretty well. So do you want
Speaker 1: to introduce him and then he can fill in the
Speaker 1: gaps for us?
Speaker 3: Yeah, well I do. I've known a Vishai for a while.
Speaker 3: I think we work together at Wicks a long time ago.
Speaker 3: Correct me if I'm wrong. And I've wanted to have
Speaker 3: a visha on or show for a while now, and
Speaker 3: I'm glad that he's finally able to join us. The
Speaker 3: reason for this is that, similarly to Tomer Gabel, we
Speaker 3: had on the show a few weeks so good. Yeah,
Speaker 3: yes he was, We had him on the show a
Speaker 3: few weeks ago, so similar to him, Avishai is one
Speaker 3: of those people who when I communicate with often it
Speaker 3: forces me to rethink or even reconsider some of my
Speaker 3: technological assumptions and even core beliefs. Things that I hold
Speaker 3: to be obviously true suddenly don't seem so true anymore
Speaker 3: thanks to Avishai. And you know, it doesn't happen every day,
Speaker 3: but it does happen, and I have to say that
Speaker 3: to be honest, this isn't always a comfortable experience. You know,
Speaker 3: we as people, as humans, we dislike having our viewpoints
Speaker 3: challenged in such ways. Even as engineers, we tend to
Speaker 3: be creatures of habit. You know, what we use, what
Speaker 3: we like to do, we continue doing the same thing,
Speaker 3: and you know, we prefer to stay the course as
Speaker 3: it were. We prefer complacency over disruption, even when we,
Speaker 3: you know, proclaim otherwise. But I think it's really important
Speaker 3: for us to go through such experiences because that's how
Speaker 3: we grow. And when you have some such interactions, you know,
Speaker 3: you grow or the other party grows, or ideally you
Speaker 3: both grow as a result of such engagements. Now, I
Speaker 3: recently learned that a few of our guests that we
Speaker 3: had on the show apparently did not have a good time,
Speaker 3: and that's really unfortunate. They felt a bit put upon
Speaker 3: when we ask them questions that require them to justify
Speaker 3: technical decisions that they made, and when we presented alternatives
Speaker 3: to solutions they came up with, they felt that, like,
Speaker 3: you know, we were kind of attacking them. Obviously, we
Speaker 3: want our guests to have a great time, and I
Speaker 3: think that most of them definitely do, and I hope
Speaker 3: Avisha that you will have a good time as well,
Speaker 3: we will say, but more importantly than that, we want
Speaker 3: our audience to gain actual value from the show. We
Speaker 3: want our audience to learn something that actually benefits them
Speaker 3: in their career as engineers. And sometimes that requires, you know,
Speaker 3: asking harder questions, challenging our guests on those decisions that
Speaker 3: they've made, and if it does make them feel uncomfortable,
Speaker 3: well sorry, but not sorry, because it's really a part
Speaker 3: of what it is to, you know, on a podcast
Speaker 3: such as ours. I guess that there are others where
Speaker 3: these things don't happen. You know, fine, I love a
Speaker 3: lot of other technical podcasts. You know, we have different emphasies,
Speaker 3: but this is how we do things. So you know,
Speaker 3: if you want to come on our show, you need
Speaker 3: to be ready to answer some tougher questions. It's just
Speaker 3: the way that we do do things. And that's what
Speaker 3: I wanted to say.
Speaker 1: Yeah, I can give an example. You brought up Tomer
Speaker 1: Gabble when he was on the show, and you know,
Speaker 1: we had a lot of back and forth on like types,
Speaker 1: strong types, type systems, and you know, it was funny
Speaker 1: because I was thinking about it.
Speaker 2: And then I watched the talk because you know.
Speaker 1: I live a lot of my programming life in the
Speaker 1: Ruby world, and it was a discussion between David Heinemeier
Speaker 1: Hansen and Tobias or Toby Luki from from Shopify, and
Speaker 1: they were having that same discussion, right, and it was
Speaker 1: interesting just to see kind of the trade offs that
Speaker 1: they were talking about.
Speaker 2: And then I wish that I could go back on
Speaker 2: that episode and say, so I.
Speaker 1: Think you're right about this and not you know, and right,
Speaker 1: and I got better informed about maybe I'm not running
Speaker 1: into the things that bring that trade off. And I
Speaker 1: think the kinds of questions and back and forth that
Speaker 1: you're talking about, Dan are the things that allow us
Speaker 1: to clarify that and open it up and go, Okay,
Speaker 1: these are the problems you're trying to solve, not these
Speaker 1: other ones, or these are the you know, this is
Speaker 1: where the trade offs really start to click into place,
Speaker 1: because what I find is that it's not always black
Speaker 1: and white up and down the board. It may just
Speaker 1: be your experience leads you to make this decision where
Speaker 1: I'm just not working in a space where that matters,
Speaker 1: or maybe I just never considered that I needed to
Speaker 1: think about it that way, and you push me to
Speaker 1: do better.
Speaker 2: So I agree with you.
Speaker 1: I think I think some of that you know, back
Speaker 1: and forth, and hey, it looks like this solves a
Speaker 1: problem better than that. And you know, we're going to
Speaker 1: give people the tools to go, oh, yes I need that,
Speaker 1: I you know, or no, I'm not quite to the
Speaker 1: place where I need that. But then you be thinking
Speaker 1: about it as I get there or there, or maybe hey,
Speaker 1: you're talking to another group of people that think about
Speaker 1: things in a different way than I do.
Speaker 2: And all of that is constructive.
Speaker 3: Any thoughts of you shine.
Speaker 5: But I can tell you that when I'm using static types,
Speaker 5: like I'm enjoying myself so much, and I'm like, what
Speaker 5: idiot would use dynamic types? And then when I'm using
Speaker 5: language that it's me. It's me right way. So when
Speaker 5: I'm using a closure it's my favorite language, I'm enjoying
Speaker 5: myself so much, and I'm like, what idiot would use
Speaker 5: static types? So it's actually like, once you get your
Speaker 5: mind into a specific style of programming, it feels very
Speaker 5: natural to you. It's very easy to forget all the
Speaker 5: advantages at Allstein has so.
Speaker 2: Cool.
Speaker 1: Well let's talk about marshmallows.
Speaker 3: Wait a minute. First of all of Isshai, I said
Speaker 3: that we worked together at Wicks. Can can you tell
Speaker 3: us a little bit about yourself?
Speaker 5: Yes? I can. So I did a lot of wild stuff,
Speaker 5: I guess. I started my career as a physicist, not
Speaker 5: not really in it, and then at some point I
Speaker 5: discovered that I'm more interested in how fast my A
Speaker 5: simulations are running more than the actual results. So I
Speaker 5: kind of switched into into it. Initially, I went into systems.
Speaker 5: I did that for a while, and then I founded
Speaker 5: the consulting company and I worked on a lot of
Speaker 5: different stuff, a part of lost large scale architecture and
Speaker 5: performance stuff and some training of engineers, and at some
Speaker 5: point I stumbled into big data. It was like the
Speaker 5: big doup hype back in the day. So I spent
Speaker 5: about two years, you know, getting people off a dupe
Speaker 5: because they didn't have enough data, you know, the whole
Speaker 5: data fits in rum thing. And after that I went
Speaker 5: to work at Wicks. I did. I had the back
Speaker 5: end team at Wicks and from Wiks I went to
Speaker 5: work for a VC. That's quite a co change, I guess. Uh.
Speaker 5: So I was in in the residents at the Alish VC.
Speaker 5: It's one of the prominent vcs in as well. And
Speaker 5: after that they went to work for CLDB, which is
Speaker 5: a high performance Cassandra clone written C plus plus. Very
Speaker 5: unique and interesting thing if you want to talk about that.
Speaker 5: And since then I've been an independent of social Now
Speaker 5: nowadays I'm mostly working on performance problems and training engineers,
Speaker 5: which is my con passion. I think that now that
Speaker 5: we have the ai AH, we have a very big
Speaker 5: problem because everything's too easy, so you don't actually learn
Speaker 5: how stuff works. So the funnel of becoming a senior
Speaker 5: from from a junior is now gone. If you think
Speaker 5: about network engineers, for example, how did you train to
Speaker 5: be a network engineer? Back in the day, you had
Speaker 5: your home auto and you played with it, and you
Speaker 5: needed to let's say, you know, define the DHP and
Speaker 5: the DNS and what stuff and nat if you had
Speaker 5: some kind of home auto and you learned doing that. Nowadays,
Speaker 5: you just get Google Mesh and you install it and
Speaker 5: everything works. So there's no reason if you'd fiddle with
Speaker 5: it and actually learned networks. So there's no funnel for
Speaker 5: network engineers anymore. So it's a problem I'm trying to
Speaker 5: help solve.
Speaker 3: You know. I'm thinking about all, you know, all the
Speaker 3: American TV shows where you have the father lifting up
Speaker 3: the hood of the car and showing their son or
Speaker 3: daughter how it actually works, how it runs. And I'm
Speaker 3: thinking about all the new electrical cars that's pretty much gone.
Speaker 5: Yeah, I had experienced and motorcycles. I had one of
Speaker 5: the last motorcycles that still had colpools. And then the
Speaker 5: fulling models already have the fuel injections. Fuel injection, yeah, yeah, exactly.
Speaker 5: And you can't you can't tune it, you can't fix it.
Speaker 3: So the day.
Speaker 4: Yeah, I've never heard anyone argue against fuel injection.
Speaker 5: I've never but I mean the trade off. Yeah, it's
Speaker 5: it's more fuel efficient, it has no performance, it's no reliable.
Speaker 5: But the downside is that you don't get to learn
Speaker 5: how motorcycles work anymore. You can.
Speaker 2: Controlled by the computer.
Speaker 5: Yeah, exactly, there's no no.
Speaker 2: Mechanical management of it.
Speaker 4: That's that's interesting because I so, I just got a motorcycle,
Speaker 4: and I'm actually glad that I got one that you know,
Speaker 4: I got an old one, so it was cheap, but
Speaker 4: it was just new enough that it was fuel injected,
Speaker 4: and which motorcycles got fuel injected much later than car did.
Speaker 4: I mean a lot of four wheelers I think are
Speaker 4: still carbureted. But yeah, I kind of I kind of
Speaker 4: felt like I dodged the bullet. I still feel like
Speaker 4: I'm learning about it, but I didn't. I didn't have
Speaker 4: that sense of understanding the carburetor is is key to
Speaker 4: understanding the maintenance of the motorcycle. Set's I'm yeah, I'm really,
Speaker 4: I'm really interested that you said that. I'm I have
Speaker 4: to sit on that for a minute. I wonder what
Speaker 4: you know that I don't know that makes you feel
Speaker 4: that way obviously something.
Speaker 5: So I'll give you an example. You live in a
Speaker 5: colder climate, right, so you need to heat up your
Speaker 5: motorcycle for a little while before you start gliding it.
Speaker 5: And the reason for that is because of the cowboy
Speaker 5: tool and because you actually need heat for the fuel
Speaker 5: to spray in, you know, to the mixture. So did
Speaker 5: you get you actually get it into the engine and
Speaker 5: it blows up? Was with you know, the injection system?
Speaker 5: You don't need to do that. The computer text out
Speaker 5: of it. So whole like even this bit of thinking
Speaker 5: for pausing for a second thinking, Okay, I need to
Speaker 5: warm up my car because you know call the climate
Speaker 5: fuel mixture that stuff that's gone. You're not even aware
Speaker 5: of it anymore.
Speaker 4: I so my mine is fuel injected. It's just new
Speaker 4: enough to be fuel injected. But it does it does
Speaker 4: definitely behave differently like I can tell. Yeah, I do
Speaker 4: get a sense of it. But yeah, the four wheeler,
Speaker 4: I actually have to actually have to tune the carburetor
Speaker 4: of the four wheeler so it'll start in the winter
Speaker 4: and not flood in the summer.
Speaker 3: I'm still thinking about the fact that you define yourself
Speaker 3: as a researcher, and I'm curious what that means and
Speaker 3: how that translates to real life.
Speaker 5: So a lot of the stuff they do right now
Speaker 5: is first of all, a lot of reading, but also
Speaker 5: a lot of observing and experimenting. So some of it
Speaker 5: is like on how systems work, and some of it
Speaker 5: is into models. And I'm saying models specifically because it
Speaker 5: relates to how people understand systems. You don't actually understand
Speaker 5: a system because you don't actually get to direct experience
Speaker 5: the system, and you cannot perceive a system. What you
Speaker 5: perceive is a model of the system that you build
Speaker 5: inside of your head. And there are some common models
Speaker 5: that we all know and they play a very important
Speaker 5: part in how we pass the world around us. So
Speaker 5: understanding those models, or inventing new models and making them
Speaker 5: approachable to people is a very important part of teaching
Speaker 5: and also debugging and architecture and all that stuff that
Speaker 5: we do. So the research part, some of it is
Speaker 5: just going through the field and seeing what is comprehensible
Speaker 5: to people and how people pass the world that they
Speaker 5: see and how they look at the world that they see.
Speaker 5: Because you've viewed the system through dashboards and graphs and
Speaker 5: metrics and of course all the tools that you have,
Speaker 5: and some of it is learning psychology and learning ecology
Speaker 5: and you know, how people think about stuff, how the
Speaker 5: brain works, all the cognitive biases that go into play.
Speaker 5: And some of it is actually researching the tech stack
Speaker 5: because that also informs and kind of conditions the way
Speaker 5: that we experience things.
Speaker 3: And you're able to make a living doing that. Cool.
Speaker 5: Not yet, So I'm doing consulting mostly the performance stuff.
Speaker 5: I am giving some workshops, which is starting to get
Speaker 5: more and more like a bigger and bigger part of
Speaker 5: the work that I do. So at some point, I
Speaker 5: guess it will become the main thing that I do.
Speaker 5: Hopefully I can make a living just doing that, but
Speaker 5: we'll see.
Speaker 3: I just wanted to also add that, you know, when
Speaker 3: you were speaking about the importance of models, it kind
Speaker 3: of also directly translates to the importance of naming things
Speaker 3: and naming things properly.
Speaker 5: Yeah, because it's just it's not just the name, it's
Speaker 5: the name and everything, you know, all the associations that
Speaker 5: it tells with it.
Speaker 3: I totally agree. So I actually brought you here because
Speaker 3: of an I don't know if you know, going back
Speaker 3: to my kind of little speech at the beginning because
Speaker 3: of this argument we had online about binary protocols versus
Speaker 3: sexual protocols. But while preparing I also read or reread
Speaker 3: some of the articles that you posted on your excellent
Speaker 3: website website, uh and so, and there were two the
Speaker 3: latest two posts. They're kind of caught my eye. One
Speaker 3: of them is titled Don't Paint the Roses and the
Speaker 3: other is titled the Marshmallow Effect. And I definitely want
Speaker 3: to talk about these as well. So I'll leave it
Speaker 3: up to you which which one of those three you
Speaker 3: want to start with.
Speaker 5: I'm cool with those all of them, but let's talk
Speaker 5: about text and binary protocols for a second.
Speaker 3: Okay for sure.
Speaker 5: It's also like it ties very nicely into the other topics.
Speaker 5: So actually, one of the points that I want make
Speaker 5: is that there is no such thing as a text protocol.
Speaker 3: You kind of stole the one of what I wanted
Speaker 3: to say. I basically wanted to say that if you
Speaker 3: go down low enough in the stack, everything is binary.
Speaker 3: It's at the end of the day, it's bits over
Speaker 3: the wire, so obviously it's it's binary. And you know,
Speaker 3: you encrypt things, you compress things, so so obviously that
Speaker 3: turns them into binary data. But I was more thinking
Speaker 3: about the applicative layer. So I was making the argument
Speaker 3: that at the applicative layer, in a lot of cases,
Speaker 3: not always, but in a lot of cases, there are
Speaker 3: benefits to text based protocols, for example, protocols that send
Speaker 3: JSON or XML or god forbid or or HTTP over
Speaker 3: the wire. And from my understanding, you were making the
Speaker 3: argument that in most cases, a binary protocol is what
Speaker 3: you prefer.
Speaker 5: So that's one that's part of it. But I think
Speaker 5: that the problem with this discussion is that it's about,
Speaker 5: you know, the civilization and the protocol itself, and it
Speaker 5: ignoes the larger context of how we write software, you know,
Speaker 5: when we have a sort of protocol. And I'll give
Speaker 5: you an example of what I mean. So Jason, for example,
Speaker 5: doesn't actually specify what the size of an integer is, okay,
Speaker 5: or what the actual precision of the float is. And
Speaker 5: and they kind of fixed it in the following out
Speaker 5: of seas, but not all implements, of course, adhere to it.
Speaker 5: But the thing about this is that if you convert
Speaker 5: to a binyl protocol corpor binyl protocol, it takes much
Speaker 5: less and much more like bytes, much more verbals in
Speaker 5: how it in codes things. So a specific number, for example,
Speaker 5: if you basically you have one byte per digit, so
Speaker 5: very large number actually takes a lot of space, which
Speaker 5: means it has a lot of facts. But it means
Speaker 5: that when you're writing software you would not use the
Speaker 5: same precision because of this. So the protocol actually affects
Speaker 5: how you write the code. And we have a lot
Speaker 5: of code that is written under the you know, assuming
Speaker 5: that you're going to use certain protocol, and because of it,
Speaker 5: it's written differently. You're not actually using the same position,
Speaker 5: you're not actually using the same data types, you're not
Speaker 5: actually actually writing the same software that you would otherwise.
Speaker 5: So even if the efficiency of binary protocols would be
Speaker 5: the same, and it's not, you would so profell to
Speaker 5: have them because of because it allows you to write
Speaker 5: better software. And that's an angle that is not often
Speaker 5: discussed when you're talking about protocols. And just to clarify
Speaker 5: this example more, think about what happens if you want
Speaker 5: to do a denial of service attack against you know,
Speaker 5: some server that accept Jason XML, you actually have to
Speaker 5: lead the entire Jason before you understand that the message
Speaker 5: is done. So you have to have very large buffles
Speaker 5: just in case, you know, someone actually decides to send
Speaker 5: you know, like eight megabytes of Jason. And if I
Speaker 5: send a very large and very deep Jason to you,
Speaker 5: I can very easily do like denial of service attack
Speaker 5: against parser. Well as in YO protocol, most of them
Speaker 5: have very strict schemas which allow them to detect no
Speaker 5: phone messages very very easily and very early. They don't
Speaker 5: actually need to have the entire buffal. Most of them
Speaker 5: can also stream, so it makes the website of those
Speaker 5: much more efficient, much more, much cheaper, but also immune
Speaker 5: to the now service tax. And this guy, you can
Speaker 5: actually say this effect in all the text based protocols.
Speaker 5: So even if the protocols, you know, they have the
Speaker 5: same payload size and they you know, network was the
Speaker 5: same and everything else was the same, just because we
Speaker 5: can write better software, I would prefer to have banier protocols.
Speaker 3: So here's the thing. First of all, I can get
Speaker 3: into the technicalities of you know, some of the downsides
Speaker 3: that you mentioned, but before that, I want to explain,
Speaker 3: like what caused me to say that in many cases
Speaker 3: I prefer textual protocols. But first, before that, even I
Speaker 3: want to say that obviously there are scenarios where textual
Speaker 3: protocols are totally not appropriate yet. So for example, nobody
Speaker 3: would send a video stream as the textual protocol, or
Speaker 3: even images over the wire. It's probably a bad idea
Speaker 3: to send them as textual protocol. And I'll let you
Speaker 3: respond in a second age. I just wanted to say
Speaker 3: that the two reasons that I wanted to say as
Speaker 3: positives for textual protocol before we get into the possibilities
Speaker 3: of you know, some of the negatives that you mentioned
Speaker 3: is one that it's easily humanly readable, which is significant
Speaker 3: benefit for me when I have to work with protocols.
Speaker 3: Second is the fact that in many cases I don't
Speaker 3: really care. I care that something is a number rather
Speaker 3: than exactly how many bits it takes to represent it
Speaker 3: in the exact format. And finally is the fact that
Speaker 3: you can make text show protocols and binary protocols together,
Speaker 3: which can get you the benefit of both worlds.
Speaker 4: And now to you aging, So there's there's somewhat of
Speaker 4: a snuck premise in what you've said, which is that
Speaker 4: me or or a h ah, sorry, there's there's somewhat
Speaker 4: of a snuck premise in that you're saying if people
Speaker 4: are using text protocols, they're less efficient and they're more
Speaker 4: subject to these issues because because of the text protocol itself.
Speaker 4: When I'm going to argue that, because of my own experience,
Speaker 4: and I imagine you've seen this too, if you gave
Speaker 4: someone a binary protocol and it were to become popular,
Speaker 4: the binary protocol would have all of the same problems
Speaker 4: because the issue with the dialogue, to the denial of service,
Speaker 4: not bounds checking, not having a bite limits, to rate limits,
Speaker 4: those are engineering issues. They're not protocol issues. They're not
Speaker 4: the fault of the data format. Likewise, what goes over
Speaker 4: the network is a bit different depending on the size
Speaker 4: of message. But we're talking about communication, not binary files.
Speaker 4: We're not talking about videos. We're talking about communication. Normally,
Speaker 4: those messages are going to fit into a TCP packet,
Speaker 4: and if they're not going to fit into a TCP packet,
Speaker 4: taking away ten to twenty percent of the brackets embraces
Speaker 4: and replacing that with little, little size headers is not
Speaker 4: actually going to be what makes the difference in you know,
Speaker 4: in the long run of when we're exchanging messages back
Speaker 4: and forth. How do we fit them into a TCP packet.
Speaker 4: We have to you know, significant like if a person's
Speaker 4: typing a paragraph, they're just typing a paragraph, you know
Speaker 4: that's going to fit if it's so, there's these other things.
Speaker 4: So I don't think that I will agree with you.
Speaker 4: There's a lot of benefits to binary protocols, but I
Speaker 4: think the examples you you gave are a little bit straw.
Speaker 5: Many before.
Speaker 3: Avisia, before you respond to that, I think it might
Speaker 3: and we will definitely let you respond. I just I
Speaker 3: thought it might be worthwhile to provide specific examples of
Speaker 3: what we mean by textual protocol and binary protocols because
Speaker 3: we're kind of being, you know, talking in theory, so
Speaker 3: it might be worthwhile to translate it into actual practice.
Speaker 3: So can we give an example of a binary protocol?
Speaker 3: And can we give an example of textual protocol? And
Speaker 3: maybe if we can give an example of a mix
Speaker 3: so a.
Speaker 5: Taxi protocol, for example, would be a Jason. Jason is
Speaker 5: a soilization format that basically JavaScript notation object plantation. It's
Speaker 5: based on JavaScript. It's all value JavaScript, and it encodes
Speaker 5: data strings and the arrays and dictionaries and numbers as
Speaker 5: ASK or UTF eight characters, whereas a Vinyl protocol would
Speaker 5: be something like a proto buff which encodes similar data
Speaker 5: in this case with some schema as bytes. So a number,
Speaker 5: for example, would be just you know, a bike representation,
Speaker 5: which also means that numbers are represented in a much
Speaker 5: more efficient way. The number one, for example, would take
Speaker 5: just you know, one byte, but also you know eighteen
Speaker 5: and twenty five would be also the one byte, whereas
Speaker 5: in JavaScript, so in JSON the number twenty six is
Speaker 5: two bytes because that's two characters, so it's actually like
Speaker 5: the text representation of a number. But h I agree
Speaker 5: with you, By the way, I think that the framing
Speaker 5: this discussion as textual protocols versus final protocols is wrong
Speaker 5: because it's done said. It's all binary over the wire. Really,
Speaker 5: the question is the discussion should be specialized protocols versus
Speaker 5: general purpose protocols. And we know that it's also mathematically
Speaker 5: proven that general purpose protocols or general purpose things are
Speaker 5: less efficient across the board well as specialized things are
Speaker 5: obviously more efficient in specific use case, but may be
Speaker 5: less efficient in other use cases. And this is why
Speaker 5: I don't like the disframing of the discussions text versus
Speaker 5: everything else. Its text was selected because it's like a
Speaker 5: universal representation. It makes very few assumptions about what goes
Speaker 5: over of the protocol, and it's based on some premise
Speaker 5: which we inherited, which is that we are transmitting textual documents.
Speaker 5: And this specific assumption was more or less universal because
Speaker 5: when it was invented in the seventies, this is basically
Speaker 5: what we sent over the network, textual documents of sorts.
Speaker 5: We didn't send images videos back then.
Speaker 3: And if I can interrupt you for a second, I
Speaker 3: was about to give two more or a few more
Speaker 3: examples of such protocols. Exactly. An example of a textual
Speaker 3: protocol is in It's exactly the scenario of a document
Speaker 3: over the wire. Is sending the HTML document over HTTP.
Speaker 3: The HTP headers are textual and the HTTP body, which
Speaker 3: is the HTML document, is also textual. On the other hand,
Speaker 3: if you're sending an image over HTTP, then then you're
Speaker 3: the header remains textual, but the body becomes binary.
Speaker 5: This doesn't structure us.
Speaker 3: On. Let me tell you a story. I several years back,
Speaker 3: I was working on software for a remote access Basically,
Speaker 3: it was running a desktop or Windows desktop or Windows
Speaker 3: application in a data center, on a server or on
Speaker 3: a VM and accessing it remotely using the browser. So
Speaker 3: basically replicating a Windows desktop interactively inside the browser. And
Speaker 3: you want this to be really responsive, and ideally you
Speaker 3: want even to be able to support animations. And you know,
Speaker 3: even though I'm talking about something like fifteen years back,
Speaker 3: we were able to hit something like ten fps for
Speaker 3: videos running on the server being streamed in this way
Speaker 3: over web socket to the client to be re drawn
Speaker 3: by JavaScript. And we were ending commands and images. So
Speaker 3: a command might be, you know, draw an image, but
Speaker 3: it might also be draw a line, or play some sound,
Speaker 3: or you know, do some various other things that user
Speaker 3: interface Windows user interfaces do, and we we mixed, so
Speaker 3: the commands were sent as small Jason packets, and the
Speaker 3: images and audio and stuff like that they were sented
Speaker 3: as binary uh. And it actually made the protocol I
Speaker 3: would almost say, beautiful, because we were literally able to
Speaker 3: drive directly translate those Jason small Jason packets into function
Speaker 3: called JavaScript function calls with parameters, So basically sending commands
Speaker 3: over the wire directly translated into executing JavaScript commands where
Speaker 3: and and the binary packets were handled as you know
Speaker 3: or pay binary blobs. You just gave them to the
Speaker 3: blob object and you got an image or an audio
Speaker 3: file or whatever. So I don't see any problem with that.
Speaker 3: It's basically, if we're going back to the example of HTTP. Obviously,
Speaker 3: the image is not something that I'm going to be
Speaker 3: sending as textual data, and it has it's kind of
Speaker 3: meaningless as textual data. But being able to look at
Speaker 3: the HTTP header instructions easily, you know, without requiring special tools,
Speaker 3: from my perspective, has a lot of value.
Speaker 5: But you do you don't actually look at the HTP
Speaker 5: without special tools. You always use some special tools. So
Speaker 5: when you look at the HTP you use TCP dump,
Speaker 5: which is a specialized tool and by the way, knows
Speaker 5: pauls binary, or using a browser which knows how to
Speaker 5: pass binary, or using something similar like wild shark. All
Speaker 5: of those tools actually pass.
Speaker 4: Finally, I use current fair enough and netcat.
Speaker 5: Net cat is the only general purpose too that in
Speaker 5: this case I killed the specialized too. What prevents netcat
Speaker 5: from passing.
Speaker 3: Binally, my issue with binary is that in many of
Speaker 3: those cases it feels like premature optimization, and it leads
Speaker 3: to even more premature optimizations. And the fact and the
Speaker 3: fact that I really need highly specialized tools versus generally
Speaker 3: available general specialized tools in order to parse it is
Speaker 3: detrimental for my experience.
Speaker 5: So I would say that the little problem and the
Speaker 5: little discussion here is about tooling, actually tooling.
Speaker 3: And sols about tooling.
Speaker 5: The down pointing system is too, so so does that.
Speaker 5: But let me try to reframe the conversation a little
Speaker 5: bit here. So I view for a BUFF, for example,
Speaker 5: as as not as a binary protocol, but rather as
Speaker 5: a carrier for a family of user defined protocols. Okay, well,
Speaker 5: as uh, this is really the problem I have with
Speaker 5: with the text and HML that stuff is that it's
Speaker 5: it's a very poor system for writing usually defined protocols
Speaker 5: on top of it. Well, protoboff is a very good
Speaker 5: system for doing that because it was designed to do
Speaker 5: exactly that. So every message, every every protocol that you
Speaker 5: write on top of protocol or protobo is specialized, but
Speaker 5: you do get to define how it behaves.
Speaker 3: Can you elaborate a little bit about what protoboff is,
Speaker 3: because I think many of our listeners will.
Speaker 5: The part above is A is a protoc it's actually
Speaker 5: three three things. It's a serialization protocol. It's a network stack,
Speaker 5: not network stack, but network protocol and schemas uh and
Speaker 5: and this stem was designed by Google first. It was
Speaker 5: designed for antle used then they open sourced it, and
Speaker 5: they also open source the OPC level that came with it,
Speaker 5: know us DOLPC. It's a multiplatform system and it has
Speaker 5: a lot of fancy features, but that's not really what
Speaker 5: we're talking about here. And the way that you would
Speaker 5: use photobop is that you would likee something called the protofile,
Speaker 5: which defines the schema of messages, and then the server
Speaker 5: and client can agree on what is being sent and
Speaker 5: they know how to past messages and all that stuff.
Speaker 5: And protobap messages can be sent over like binary network
Speaker 5: protocols and HTTP and you know, various other protocols. You
Speaker 5: can even save them to files if you wanted to.
Speaker 5: So the kind of universal in this way. And this
Speaker 5: is the nice thing about this, that you can actually
Speaker 5: use a carrier that's more efficient or you know, more
Speaker 5: widely supported, depending on the use case.
Speaker 4: I'm having a real hard time with this. It seems
Speaker 4: like we're suggesting that the network is one of the
Speaker 4: great bottlenecks that we need to be concerned with when
Speaker 4: I don't see that in my experience. I agree that
Speaker 4: gRPC could be great for server to server communication in
Speaker 4: internal infrastructure, but I've also seen a talk that specifically
Speaker 4: argued against it. Where I mean, you can see a
Speaker 4: talk for everything right, so that doesn't say much, but
Speaker 4: the arguments were very compelling that the development time that
Speaker 4: they saved by having everything internal and external as JSON,
Speaker 4: being able to debug any service quickly you look in
Speaker 4: the logs that the efficiency that they gained by not
Speaker 4: worrying as much about one of their most abundant resources
Speaker 4: was well worth it. And what I have seen with
Speaker 4: gRPC is it's a level of complexity that most people
Speaker 4: can't manage. So I'm not saying that the experts that
Speaker 4: are working in the in the enterprise in highly tuned
Speaker 4: scenarios shouldn't be using it. They know what they're doing,
Speaker 4: they have use cases that I personally don't have. But
Speaker 4: what I have seen looks like and this could be
Speaker 4: a misconfiguration, but it looks like a minimum of two
Speaker 4: megabytes of JavaScript to be able to produce a few
Speaker 4: gRPC messages. Now, obviously you could you could hand tune it,
Speaker 4: and you could do that in you know bytes. But
Speaker 4: what I've seen is that the generated tools like the
Speaker 4: proto buff C generates an entire infrastructure for proto buff
Speaker 4: to basically get out that Hello World message. So I
Speaker 4: am not convinced for web applications that that what you're
Speaker 4: saying aligns with the experience that I have or that
Speaker 4: I know other you know, I'm not seeing it.
Speaker 5: And you're not going right away. So here's the fundamental problem.
Speaker 5: And we said that's a tooling problem. Yeah, sure, So
Speaker 5: javact doesn't actually support Jason. The buzzle does.
Speaker 4: So what is at this point, I'm pretty I mean,
Speaker 4: is it not part of the ACTMASCRIPT standard. I I
Speaker 4: thought it was adopted, which am I mistaken?
Speaker 5: No, No, it's it's the it's V eight.
Speaker 3: No, I think you're saying. Sorry, what Avisha I think
Speaker 3: is saying is that the code that parses the Jason
Speaker 3: is not written in JavaScript. It's written in in or
Speaker 3: C plus or something. Whether it's part of V eight
Speaker 3: or or blink is is kind of irrelevant to the
Speaker 3: web development.
Speaker 5: But but the thing is this, So first of all,
Speaker 5: that to mention the GTP thing, I find it very
Speaker 5: odd that the headles, which are the only thing that
Speaker 5: should be very very efficient and and is completely independent
Speaker 5: of you know, the actual payload and whatead is text
Speaker 5: or binary is text. And this is actually a very
Speaker 5: big problem that Google and you know the rest of
Speaker 5: the people working on HTP three encountered, actually they encountered
Speaker 5: in HDP two when they tried to introduce by binary
Speaker 5: headles because of all the reasons that are mentioned, because
Speaker 5: it's more efficient, because it protects the server and client
Speaker 5: implementations against the denial of service tax and all that stuff.
Speaker 5: So actually binary headles is something that everybody wants, but
Speaker 5: for historical reasons, we don't have. And if we designed
Speaker 5: HTP today, we would actually do the reverse. We would
Speaker 5: have binary headles and everything else could be text of binary.
Speaker 5: The reason that we have it in the verse is
Speaker 5: because of your basically the history of your computing systems
Speaker 5: and the Internet. And going back to your point about
Speaker 5: GPC versus Jason, Yes, Jason is universal for again for
Speaker 5: sol cobles and all the buzz will support it. But
Speaker 5: and this makes it the path of this resistence. So
Speaker 5: you're not incorrect in saying that, you know, put aboff
Speaker 5: coute les hodow, and it's true, it's hollow, but it's
Speaker 5: horbo because it's not universal in the sense that not
Speaker 5: all the tooling supports it natively well.
Speaker 4: And this is yes, yeah, because I'm not just saying
Speaker 4: it's harder.
Speaker 5: I also want to mention that everybody actually likes schemas,
Speaker 5: even for Jason. They don't do it explicitly, but the
Speaker 5: code actually has a schema for what message is and agreed,
Speaker 5: So it's not that you get around, you know, this
Speaker 5: complexity of writing schemas and describing the message as when
Speaker 5: you're doing Jason. Mmm.
Speaker 4: So to the first point, I'm not saying it's harder,
Speaker 4: I'm saying that it's it is in fact less efficient
Speaker 4: in one of the key areas that matters. I agree
Speaker 4: with you. Can we get a binary protocol built into
Speaker 4: the browser, like, can we have like we have Jason
Speaker 4: dot stringify, Jason dot parse. Can we get in the
Speaker 4: browser proto buff dot parse? Sure, like that would be cool.
Speaker 3: We can send binary data off off of web sockets.
Speaker 3: WebRTC is a binary protocol. You can send data in it,
Speaker 3: so we kind of do we are restricted in what
Speaker 3: we can send and and the in the carrier. But
Speaker 3: but to an extent we we we already do.
Speaker 4: Well, I mean the machinery. There's a lot of binery
Speaker 4: to produce binary I do.
Speaker 3: Want to say, I do want to say something about
Speaker 3: Jason and and the parsing problem. Now, obviously it's not
Speaker 3: a solution to denial of service, even though you can,
Speaker 3: you know, build such solutions. But if you're looking at
Speaker 3: it from a straight on protocol, what somehow eludes a
Speaker 3: lot of people is that instead of send being a
Speaker 3: huge JSON that needs to be parsed in its entirety
Speaker 3: before anything can be done with it, it's usually very
Speaker 3: straightforward to send much smaller Jason packets or parts and
Speaker 3: then parse each one of them individually.
Speaker 4: So well, json L does this, and that's a pretty
Speaker 4: decent solution.
Speaker 5: It might, as long as everybody on the system is
Speaker 5: well behaved.
Speaker 4: Yes, of course, So okay, one question I had earlier.
Speaker 4: Cbore and as N one are binary protocols that are
Speaker 4: generic protocols. I would think that in every way they
Speaker 4: suffer from the same problems as Jason. So proto buff
Speaker 4: is different. Proto buff is packed strucks. So would you
Speaker 4: also say that Cboor is you know, pretty much just
Speaker 4: as bad as Jason Or would you put seboor in
Speaker 4: the category of proto buff.
Speaker 5: So I would argue that every universal general purpose protocol
Speaker 5: suffers from similar problems. It's not really about text or
Speaker 5: by any It's it's more about, uh, restricting the use cases,
Speaker 5: which is well schemes tie in. And this is why
Speaker 5: I like protuba and similar systems because they allow you
Speaker 5: to define, you know, the special cases and you know,
Speaker 5: make up your own rules about what they mean and
Speaker 5: how to use them and how to validate them, and
Speaker 5: and and really this is like a big issue in
Speaker 5: computer systems in general. It's not really about like civilization,
Speaker 5: it's it's about systems in general. You you actually see
Speaker 5: this problem in many other cases. And going back to
Speaker 5: the point that you made earlier, and this is also
Speaker 5: a problem of you deploying stuff in the large scale,
Speaker 5: because every time we deploy protocol, if it's successful, it
Speaker 5: becomes legacy. And legacy you know, it's a very thing,
Speaker 5: but actually it means that you had something that worked
Speaker 5: very well. And once something works very well and becomes
Speaker 5: you know, widely used, now you have a problem because
Speaker 5: it's a network system and replace it. Everybody has to
Speaker 5: replaced it, which is why you know it takes such
Speaker 5: such a long time to deploy replacements for HDP one
Speaker 5: point one or you know, TCP or ip before and
Speaker 5: everything else. It's it's all basically the same problem. It's
Speaker 5: something that was widely successful. Now it kind of hit
Speaker 5: the limits of what it can do, and we actually
Speaker 5: suffer greatly from the limits of you know, the coding system.
Speaker 5: You know, you can see this IPD four for example,
Speaker 5: but also with HDP. There are many reasons why we
Speaker 5: want to replace HTP, but calling out a new version
Speaker 5: or something to replace it, it's actually a very big problem,
Speaker 5: which goes into back root compatibility and you know, actually
Speaker 5: having everybody installed tooling you know, to make it universal
Speaker 5: before the connective use it, and then you'll start sending
Speaker 5: out a new protocol and starting to use it. So
Speaker 5: really that's the problem. It's not that I don't think
Speaker 5: anybody you know, argues that Jason is somehow good or
Speaker 5: like that the most optimized system or the best system
Speaker 5: or anything like that. I think everybody pretty much, okay,
Speaker 5: except Ajmabe, but I think most people would agree that
Speaker 5: we can have better systems. It's just a problem of
Speaker 5: how to all it out.
Speaker 3: It kind of reminds me if I if I I
Speaker 3: recall a talk by Alan k whom I admire. He
Speaker 3: gave this talk something like twenty something years ago when
Speaker 3: when the web was starting to explode, and it turns
Speaker 3: out that the web was really rubbing him the wrong
Speaker 3: way for a lot of the reasons that you were
Speaker 3: mentioning a Vishai, and he showed a system built Surprise
Speaker 3: Surprise on small talk that was sending messages and agents
Speaker 3: across the wire, and he replicated various web apps, whatever
Speaker 3: web apps we had some twenty years ago with his system,
Speaker 3: and he did an interesting comparison. He was showing measuring
Speaker 3: the temperature of the computer running a web based solution
Speaker 3: versus his solutions, showing that his solution was running colder,
Speaker 3: much more green, much more environmentally friendly. And his system
Speaker 3: was amazing, But you know, looking at it, you know
Speaker 3: there was basically no chance because nobody was going to
Speaker 3: rip out the web and replace it with the custom
Speaker 3: solution built on small talk, regardless of how amazing llen
Speaker 3: K is and how great it theechnologies that he comes
Speaker 3: up with are.
Speaker 5: Yeah, because when you have a successful system, you need
Speaker 5: to have a very large advantage or very large limitation
Speaker 5: in the code system two, you know, to actually pay,
Speaker 5: you know, the very steep price of replacing the entil system.
Speaker 5: And it makes sense. This is why we have legacy.
Speaker 5: It's not a bad thing. But though many many like
Speaker 5: the only a lot of reasons, a lot of the
Speaker 5: it's becoming more and more obvious that the code stack
Speaker 5: is hitting the limits and we need to start replacing it.
Speaker 5: You see this with IP before because we basically ran
Speaker 5: out of the address of a space, so we have
Speaker 5: no choice at this point. We have to replace it
Speaker 5: just takes a very long time. You see this with
Speaker 5: HDP one point one though, a lot of problems with it.
Speaker 5: So now we have HDP two and HP three and
Speaker 5: like we're rolling it out as we go, and HDP
Speaker 5: three is based on UDP not TCP again because of
Speaker 5: the limits of TCP. And now we are starting to
Speaker 5: see a movement to get rid of TICIP in data
Speaker 5: centers to place it with UDIPBIS protocols.
Speaker 3: I don't know if I call it the limits of
Speaker 3: TCIP rather various the implementation decisions that made total sense
Speaker 3: in the seventies and the networks that we had back
Speaker 3: then don't make sense anymore in today's cellular networks and
Speaker 3: whatnot exactly.
Speaker 5: And this is the thing. It's like, whenever you make
Speaker 5: a design choice, although no right design choices that doesn't exist.
Speaker 5: What you have is a design choice that walks and
Speaker 5: works well enough, and you know that reality is going
Speaker 5: to change, you know, whether or not because computers change,
Speaker 5: or technology changes, or the users change their mind or whatever,
Speaker 5: it doesn't matter. It's going to change. At some point
Speaker 5: you will have to change the system. And good protocols
Speaker 5: and good systems adapt, but there's a limit to how
Speaker 5: much you can adapt. Like at some point the basic
Speaker 5: assumptions that you made but the system are going to
Speaker 5: be invalidated. And at that point, you know, the system
Speaker 5: is going to start hitting limits. And you can live
Speaker 5: with it for some time, but at some point you
Speaker 5: will have to replace it. So when we build systems,
Speaker 5: you know, back in the day in the seventies, we
Speaker 5: didn't think about, you know, future proofing it, and we
Speaker 5: didn't think about sunsetting it and how you replace it
Speaker 5: with the next generation. Now we'll smallter. We already know
Speaker 5: it's going to happen, because you know, we had this
Speaker 5: experience of a system that became very successful, the Internet,
Speaker 5: and we actually got to be old enough to see
Speaker 5: it hit the limits. So we are now a well
Speaker 5: of this problem and we know that the next generation
Speaker 5: has to be future poofed. But you know, we'll learn
Speaker 5: it to holdway.
Speaker 3: Is it, though, we will only know when we get there.
Speaker 5: I'm pretty sure that we will have to replace everything
Speaker 5: again in like thirty forty years, if not soon.
Speaker 3: By the way, this is, I think we could talk
Speaker 3: on about this. You know, we can keep on talking
Speaker 3: about this, but I think this is an actually an
Speaker 3: opportunity to kind of pivot to one of the articles
Speaker 3: you wrote, because it really ties into a lot of
Speaker 3: what you're saying, which is the article with this amazing name,
Speaker 3: which is Don't Paint the Roses, which is a reference
Speaker 3: to u a part in Alice in Wonderland. Can you
Speaker 3: can you explain where this came from and kind of
Speaker 3: how it ties into what we're talking about.
Speaker 2: The song of the Disney movie keeps playing in my
Speaker 2: head every time we Yeah, it's.
Speaker 5: A great scene. Anyway, Yeah, so those scene in Alice
Speaker 5: in Wonderland, this version from I think the forties, right,
Speaker 5: all the fifties. Yeah, by the way, painted, they actually
Speaker 5: painted all the friends by hand. And in the scene
Speaker 5: you see the cord soldiers, you know, painting the rose bushes.
Speaker 5: They're painting in them red because they accidentally planted the
Speaker 5: white roses and the queen wants them to be read,
Speaker 5: so they just paint all the roses. And the problem
Speaker 5: with this is that, you know, at some point the
Speaker 5: queen comes and she discovers that those bushes were painted,
Speaker 5: and she you know, goes off of their heads and
Speaker 5: all the cards lose their heads, which is very unfortunate
Speaker 5: to them, and.
Speaker 3: What never happened in a modern Disney movie.
Speaker 5: So the thing is that we actually have a lot
Speaker 5: of painted oil bushes around us. In reality, it's like
Speaker 5: something that we try to fall into a form, even
Speaker 5: though the COVID like the essence of it is very different.
Speaker 5: And this is you know, a lot to do with
Speaker 5: the industrial mindset of the design of mindset versus the
Speaker 5: organic mindset or the agriculture mindset. If you're trying to
Speaker 5: growth something something that is organic, actually control what it
Speaker 5: will grow into. You can you know, kind of try
Speaker 5: to to direct and influence it. You can influence it,
Speaker 5: you can direct it.
Speaker 3: You know you can.
Speaker 5: You have like for example, Bonsaie is a very good example,
Speaker 5: where you trim the roots to make it and the
Speaker 5: tree to make it in certain shape and size, so
Speaker 5: you can constrain it somewhat and direct the growth, but
Speaker 5: you can't actually change the essence of it. A bonesie
Speaker 5: tree will always look like a tree no matter what
Speaker 5: you do to it. And the industrial mindset is a
Speaker 5: designer mindset where you design something and you can actually
Speaker 5: force it to be that thing, and if it doesn't
Speaker 5: work that way, you can just destroy it and start over.
Speaker 5: So the problem we have in mode of society is
Speaker 5: that we are an industrial society and when we get
Speaker 5: to organic situations, we try to handle them into a
Speaker 5: sort of form, even though you know it's the organic
Speaker 5: and the very So the example of this is organization building.
Speaker 5: Organizations are organic. You can't just decide that you know
Speaker 5: they're going to be in a certain way. But you know,
Speaker 5: if you've been in corporate and you've lived through you
Speaker 5: know one of those organizational restructuring programs, you know what
Speaker 5: I'm talking about.
Speaker 3: Uh, and it kind of has to do with with
Speaker 3: what we were talking about before about legacy systems and
Speaker 3: legacy protocols, where certainly you can say that a lot
Speaker 3: of the Web has evolved more than it was designed.
Speaker 3: I think there's an excellent quote that I love in
Speaker 3: the HTP spec which basically says, we recognize that a
Speaker 3: lot of what is written here is kind of doesn't
Speaker 3: make sense, and it's even nonsensical. But that's the because
Speaker 3: it evolved more than it was designed, and a lot
Speaker 3: of discrete teams were working on it and working without
Speaker 3: proper synchronization and stuff like that, so it kind of
Speaker 3: grew organically rather than being designed, certainly not top down.
Speaker 5: A lot of seas actually described the factor protocols which
Speaker 5: will later qualify the ol seas. Rather than having them,
Speaker 5: you know, designing the protocols, documenting them in our season
Speaker 5: and then implementing them. It was actually backwards.
Speaker 3: Well, if you think about what RFC stands for, it's
Speaker 3: a request for what is it comment for comment? It's
Speaker 3: basically it's not here's the spec. It's basically, I've got
Speaker 3: an idea, what do you think about it? And you know,
Speaker 3: this request becomes codified as as the actual specification.
Speaker 5: Yeah, so it turns out that basically the web is
Speaker 5: a network of consensus. It's not so much design network
Speaker 5: as it is an organic network that evolved and we
Speaker 5: somehow got to a consensus about how it should walk.
Speaker 5: A few years back, you had an incident. Well, cloud
Speaker 5: flowed actually did something according to the LFCI, according to
Speaker 5: the spec but everybody else was using it differently, and
Speaker 5: this created basically an outage in total services. And after
Speaker 5: they discovered it, they fixed it in the sense that
Speaker 5: they now conformed to everybody else, which means that they
Speaker 5: violate the spec So this is basically how they entered
Speaker 5: the walks. We walks the consensus. It doesn't work by specification.
Speaker 3: Anyone who's ever wondered why user agents look the way
Speaker 3: that they do. I remember when Microsoft released a new
Speaker 3: version of what was it, a certain version of what's
Speaker 3: their browser's name, Edge, and they broke off a three
Speaker 3: sixty five on Edge because they actually used a proper
Speaker 3: user agent, but that confused their detection protocol, so they
Speaker 3: had to put in a wrong user agent yet again,
Speaker 3: just in order to get things to work right.
Speaker 4: The wheel of time keeps coming around and around.
Speaker 3: But how do you deal with it? I mean, you know,
Speaker 3: at the end of the day, we are very often
Speaker 3: forced to paint the roses because we need to deliver
Speaker 3: something on time, within budget, and we don't have the
Speaker 3: time to grow a new solution and make it conformed
Speaker 3: to whatever we already have.
Speaker 5: So it's it's it's a mindset actually, first all conversation
Speaker 5: you want to have with you know, the product manager
Speaker 5: and the business people because it's it's optimizing for the
Speaker 5: long age. Really, So even if you are forced to
Speaker 5: paint all of those bushes, you want to have some
Speaker 5: kind of an escape patch. You want to be propelled
Speaker 5: to eventuality. Well, you know someone will find out this
Speaker 5: is that really painted ball bush you because once someone
Speaker 5: discovers this, there will be consequences and there will not
Speaker 5: be nice. You know, it can be off with your
Speaker 5: head at some point. So if you adopt this mindset
Speaker 5: of organic growth and you understand that as a designer,
Speaker 5: you're actually looking for experimentation, you're looking for a future
Speaker 5: pool things, you're looking for escape passing hatches, you're looking
Speaker 5: for minimalistic design. So a good design is one that
Speaker 5: doesn't make decisions that it doesn't have to.
Speaker 3: You can examples going either way. For what, can you
Speaker 3: give concrete examples of either where painting the roses ended
Speaker 3: in disaster or or converse or conversely was done successfully.
Speaker 5: Yeah, so I can give actually a lot of examples this,
Speaker 5: So okay, let me actually if we won't go into
Speaker 5: that specific so you know how we can talk about
Speaker 5: the develops for example, develops is a very good example.
Speaker 5: Develops is a classic painted doll bush because it started
Speaker 5: out as something organic. You know, we had this movement
Speaker 5: that you know, said, look, we have this problem between
Speaker 5: operations and then developers. They don't understand each other. There's
Speaker 5: like a structural problem in organizations. There's a structured problem
Speaker 5: in the software stack where we have parts that don't
Speaker 5: you know, connect to each other. And then we, you know,
Speaker 5: we started trying to solve this problem. And then someone says, okay,
Speaker 5: you know what, let's invent a new profession. You can
Speaker 5: call it DevOps. Let's invent devlops tooling, let's invent the
Speaker 5: DevOps team, the devils engineer, blah blah blah. And now
Speaker 5: we have a painted close bush because we tried to
Speaker 5: design the solutions that are growing organically and it got
Speaker 5: so bad that now people talk about DevOps, you know,
Speaker 5: not interacting with ops all devs. So we have the
Speaker 5: like DevOps problem you can call it, and you have
Speaker 5: tools that are trying to solve the problem. Well, DevOps
Speaker 5: tools don't communicate well with depth tools or tools, which
Speaker 5: is like, yeah, ridiculous.
Speaker 4: Yeah, it's like it's it's it. It's like it was
Speaker 4: a buzzword that was created to sell aws certificates, and
Speaker 4: you end up with all these people who create these
Speaker 4: layers of infrastructure that don't help the developers. Developers now
Speaker 4: have to wait, you know, fifteen minutes for their deployees
Speaker 4: to get through.
Speaker 5: Yeah.
Speaker 4: Oh oh, this is I'll shut up now because this
Speaker 4: is one of my Yeah.
Speaker 1: But as point, it was originally this movement to bridge
Speaker 1: the gap between like infrastructure and code and make it
Speaker 1: manageable so that you could communicate about this stuff and
Speaker 1: the way you communicated about the stuff and the way
Speaker 1: you set up your your your people and your processes.
Speaker 1: And that's what it got co opted into, right.
Speaker 4: That's yeah, sorry, I think the Phoenix project still used
Speaker 4: it in the sense in which it was intended. The
Speaker 4: book the it's called the is it. The Phoenix project
Speaker 4: is the name of the book. I think that that
Speaker 4: one talks about DevOps in the actual terms of what
Speaker 4: DevOps is supposed to be, like partnering with the development
Speaker 4: team and the operation team to to understand both sides
Speaker 4: and provide tools that facilitate quicker and more efficient Yeah,
Speaker 4: agile development.
Speaker 5: Very good example.
Speaker 3: Another interesting example I'm saying and running into is the
Speaker 3: whole concept of shift left and development, where you say,
Speaker 3: instead of having dedicated QA and automation teams, we let
Speaker 3: the developers do the automation and be responsible for the testing,
Speaker 3: which is great on the one hand, but on the
Speaker 3: other hand, results in a situation where nobody owns or
Speaker 3: is responsible for the automations, and then when something breaks,
Speaker 3: nobody knows how to fix it.
Speaker 5: And it's also very weird because you know, if you
Speaker 5: have a process and you shift everything left, you know,
Speaker 5: you still end up with something in the right. You know,
Speaker 5: you shift on the dominos left, you still have a
Speaker 5: serious dominoes like something is going to be on the
Speaker 5: other side. Yeah.
Speaker 3: Yeah, before we're done, I really you want to touch
Speaker 3: on the other posts as well. We are running, We're
Speaker 3: starting to run towards the end, but I really like
Speaker 3: to spend a few words on that. And that's another
Speaker 3: post with a great name, and it's called the marshmallow effect.
Speaker 5: Oh yeah, So the marshmallow effect basically is stuff that
Speaker 5: has the you know, the original name, but it doesn't
Speaker 5: actually have any of the original ingredients. So most people
Speaker 5: don't know. But marshmallow was originally made from a marshmallow
Speaker 5: plantallow wood, and obviously you know nowadays marshmallows made from coal, silk,
Speaker 5: and sugar basically, and it doesn't actually have the taste. Yeah,
Speaker 5: and it doesn't actually have the taste of actually marshmallows.
Speaker 5: Some places in New Rope you can still get the
Speaker 5: original stuff. It's very hard, but you can still get it.
Speaker 5: But those in the food industry, it's actually very common.
Speaker 5: A lot of the stuff that the industrial stuff we
Speaker 5: today like still has the same names as the vigils
Speaker 5: from one hundred years ago because it's actually but it's
Speaker 5: not the same thing, doesn't even taste the same.
Speaker 3: I remember growing up they never ate it. I remember
Speaker 3: growing up in in the in the what was it
Speaker 3: like in the eighties and in the States, there was
Speaker 3: this leon lemonade called Old fashioned country lemonade or something
Speaker 3: like that, which had zero lemons in it. Uh And
Speaker 3: and yeah, I remember how shocked I was by that.
Speaker 2: I thought you were going to say that you used
Speaker 2: to drink cocaine in your Coca cola.
Speaker 5: Wonder bread, wonder blood. Another good one. And if we
Speaker 5: have something called sacla which is like a torkash drink
Speaker 5: which was made from safa plant, but obviously now it's not.
Speaker 5: And like, yeah, I still remember the vigilal saclub. But
Speaker 5: people who like you know, grow up now, they never
Speaker 5: actually tasted. They think that what they're drinking now safa
Speaker 5: it's not. But you also say this in technology, and
Speaker 5: I think the cloud is a very good example. You know,
Speaker 5: people talk about like discs. It is it's not a disc.
Speaker 5: It looks like yeah, I mean it looks like a disc.
Speaker 5: It has you know, some fake blocks and stuff, but
Speaker 5: it's it's not actually a disc. It's not magnetic or
Speaker 5: SSD or anything like it. It's just a name that
Speaker 5: puts on to tell you that this has certain eye
Speaker 5: ops and certain speed and buildings.
Speaker 3: That's kind of intentional. With virtualization, the whole concept of
Speaker 3: virtualization virtual memory. Going back to virtual memory is the
Speaker 3: fact that you know, virtual memory is not memory. It's
Speaker 3: files on a disc, but it's it's it's one thing
Speaker 3: that's intentionally created to look like another for very exactly.
Speaker 5: So it's backwards compatibility. But that creates a lot of
Speaker 5: interesting problems because first of all, it impacts how people
Speaker 5: think about the system. So I'll give you an example.
Speaker 5: People often debate whether they should use A or e
Speaker 5: B S or e f S, which is like NFS,
Speaker 5: and then they're like, oh, but discs A, you know,
Speaker 5: have these features or have this speed or whatever, And
Speaker 5: it's all long because actually S three and EBS, you know,
Speaker 5: they actually the same machines doing the storage. E f
Speaker 5: S is basically like the same with the VBS, except
Speaker 5: the protocol that you use to communicate with it. And
Speaker 5: so the real question is not, you know, if it's
Speaker 5: like discs or something else, it's like how many eye
Speaker 5: ups are getting and do you like this protocol that
Speaker 5: you're using to to talk to this storage. So though
Speaker 5: that's what you should be you know, talking about, really,
Speaker 5: but session people have because they don't understand that this
Speaker 5: is actually all the same storage, just presented in a
Speaker 5: different way, and you have a similar problem with VPC
Speaker 5: because you know it's again Beckward's compatibility, which you don't
Speaker 5: actually needed the cloud.
Speaker 4: You know.
Speaker 5: I had this conversation with one of my clients, well,
Speaker 5: they consulted me about out network design, like, okay, so
Speaker 5: how many subnets do we need to do and do
Speaker 5: we need to put all the application on the same subnet?
Speaker 5: And I was like, but you know, it's not just
Speaker 5: because you have the same subject doesn't actually mean everything
Speaker 5: the subjet is physically close. It's not going to have
Speaker 5: better latency or anything like it. You know, it's all
Speaker 5: public network the entire zone. You know, It's like, it
Speaker 5: doesn't matter if you if you use like one stub
Speaker 5: at twenty subnets, it's still going to be the same,
Speaker 5: the same, you know, under like structures that you have
Speaker 5: no idea about.
Speaker 3: So if if I'm understanding correctly, what you're saying or
Speaker 3: even lamenting is the fact that we create these sorts
Speaker 3: of virtualization layers that are kind of lies, and we
Speaker 3: do that to ease transitions, that say, between systems, but
Speaker 3: at the end we end up lying to ourselves because
Speaker 3: we're carrying over mindset and certain assumptions of how things work.
Speaker 3: When they don't actually worked that way at all anymore.
Speaker 5: Yes, and hills would get interesting because I'm through the
Speaker 5: generation that actually used data centers. I installed data centers,
Speaker 5: and I worked in data centers, and I know that
Speaker 5: stuff very well because I actually interacted with the machines.
Speaker 5: But now you have a generation that started the careers
Speaker 5: in the cloud with virtualization, and now though basically eating marshmallows,
Speaker 5: and they never actually tasted the new stuff.
Speaker 2: You're making me feel old.
Speaker 1: My first full time tech job, or not full time,
Speaker 1: it was part time, but I was when I was
Speaker 1: a student at BYU, I was working in the data center,
Speaker 1: and the server was a server, it was a machine, right.
Speaker 2: Some of those machines were like they take up a
Speaker 2: whole freaking cabinet.
Speaker 4: And then.
Speaker 2: Right by the time I left, now.
Speaker 1: We had servers that were we had these servers with
Speaker 1: blade servers in them, right, and so it was it
Speaker 1: was a box that had a bunch of computers in it.
Speaker 1: But then we had dmware installed on those, and so
Speaker 1: then a server was this virtual thing that lived on
Speaker 1: this right, but you still knew which server your server
Speaker 1: ran on, right, And yeah, anyway, and then talking.
Speaker 3: Volved and then VMware introduced v motion, which allowed them
Speaker 3: to move those vms between machines without ye without time.
Speaker 3: And then we got to the cloud, to the actual
Speaker 3: cloud where you literally have no idea where your lambdads
Speaker 3: are running.
Speaker 5: Right, and also have very interesting discussions between people about
Speaker 5: the same like containers more efficient, vms the more efficient,
Speaker 5: and it's like very little discussion because it's all the
Speaker 5: same stuff.
Speaker 4: Yeah, and we've got this problem, like docer is recreating
Speaker 4: the very problem that it was intended to solve. So
Speaker 4: for example, uh, the blue Sky self hosted installer choirs
Speaker 4: that you run on Ubuntu so that it can install
Speaker 4: all the things that need to be installed to install
Speaker 4: and configure Docker so that you install the packages in
Speaker 4: the container in a predictable way. It's like, well, why
Speaker 4: didn't you just say blue Sky only runs on Ubuntu
Speaker 4: or you need to follow you need to install these
Speaker 4: ten packages on your own right. But now, but now
Speaker 4: it's like I have to so in my container, I
Speaker 4: have to have nesting so that I can run debians
Speaker 4: so that I can run the Docker so that I
Speaker 4: could run Debian.
Speaker 5: Yeah.
Speaker 4: Machine, well yeah, yeah, yeah, yeah. We can't ship your
Speaker 4: machine to to the client, but we ship a clone
Speaker 4: and still nobody knows what's going like that. This is
Speaker 4: the thing I always say, so that, but that you know,
Speaker 4: the problem with Docker is not docer. Docker is a
Speaker 4: great technology, is a technology the doc The problem with
Speaker 4: Docker is that it just moved the goalpost to no.
Speaker 4: No one understands why my machine works, will ship a
Speaker 4: clone of the machine to no one understands why the
Speaker 4: Docker file works will ship well. And then you don't
Speaker 4: even get it because it's hosted on Docker Hub, so
Speaker 4: you don't even get to see the Docker file. So
Speaker 4: you don't even know how to recreate the container at all.
Speaker 4: So we're actually worse off because at least before you
Speaker 4: could kind of like look at the history on the machine.
Speaker 4: Now you get a container where all the history is
Speaker 4: stripped out and you don't.
Speaker 5: Know how it got there.
Speaker 1: Well, they do have the layers and things like that,
Speaker 1: but what's fascinating about it is that and it should
Speaker 1: work anywhere, but yeah, you know, it does make assumptions
Speaker 1: about how your Docker set up on your machine.
Speaker 5: Twist.
Speaker 4: Then it's a go binary and it didn't need any
Speaker 4: of it anyway.
Speaker 3: I'm ashamed to say that I've managed to have a
Speaker 3: pretty good engineering career without you know, truly understanding the
Speaker 3: finer details of Docker.
Speaker 4: It's just a Linux process group. It's just a process groups.
Speaker 4: It's just like forking from process but with more kernel
Speaker 4: level security.
Speaker 5: I want to make a shameless plug. Like about a
Speaker 5: decade ago, Nati Cohen and myself had a workshop called
Speaker 5: Rabo docer or docer from scratch. Will you write your
Speaker 5: own docer clone in Python and you basically implement docer
Speaker 5: using you know, Linux system calls like a clone folk
Speaker 5: and like over the fight system and the name spaces
Speaker 5: and c groups and all that stuff. So it actually
Speaker 5: gives you a pretty good idea of how doker works
Speaker 5: under the hood. It's all open source. It's in GitHub.
Speaker 5: You can put links that you want. Yeah, I would
Speaker 5: love it.
Speaker 3: Nat is great he even though he's moved over to
Speaker 3: the dark side. I think he's working at AWS now.
Speaker 3: We should probably have him on the show as well. Also, Karen,
Speaker 3: his wife, is presy amazing as well. Anyway, I'm digressing.
Speaker 5: Yeah, I just wanted to say about the doctor. It's
Speaker 5: a very good example of like how the discussion kind
Speaker 5: of trailed off like in the community because we had
Speaker 5: this tool. Because really the problem is that doctors that containers.
Speaker 5: It's reproducible bills mm.
Speaker 1: Hmm yep, which when you think about it, yeah, then
Speaker 1: then you start you start, like my brain started going
Speaker 1: to other places. Right, these are the other tools that
Speaker 1: I've used to solve similar problems.
Speaker 5: Mm hmm.
Speaker 3: Yeah.
Speaker 1: Yeah, all right, Well, is there anything else that we
Speaker 1: want to kind of kick around? Different marshmallows to kick around,
Speaker 1: or conversations to paint red before.
Speaker 3: We now, now you really want you You got me
Speaker 3: to really want to try out real marshmallows.
Speaker 2: I know I'm curious too.
Speaker 5: Now, yeah, it's not the fine, but then you find them. Yeah.
Speaker 3: The funny thing is when you find one of the
Speaker 3: original of things and then you discover you don't, you
Speaker 3: don't actually like it. I think our current model, Yeah,
Speaker 3: our current modern ketchup, for example, has nothing to do
Speaker 3: with the original ketchup.
Speaker 5: Do you know the story about ketch Peninsula, right.
Speaker 3: Yeah, yes I do, But you can tell it. It's
Speaker 3: a really weird one that shows up bureaucracies work and
Speaker 3: how business interesting bureaucracies can go hand in hand.
Speaker 5: Yeah, tell it.
Speaker 3: So. Basically, in Israel, we have a local brand of ketchup.
Speaker 3: And at a certain point in time, they started to
Speaker 3: if somebody started to import Heinz Ketchup and so, and
Speaker 3: that was starting to eat into their market share. So
Speaker 3: what they did is they changed the legislature on what
Speaker 3: can be legally termed as being ketchup. That's the way
Speaker 3: that Heinz Ketchup could no longer be called ketchup in Israel.
Speaker 3: So instead it's called sweetened the tomato sauce or something.
Speaker 3: And they got to keep the term ketchup for themselves,
Speaker 3: but it didn't really help them anyway, because people just
Speaker 3: bought hinds regardless of what it was. What it said
Speaker 3: below the Heinz Moniker.
Speaker 2: Oh that's so funny. Points for creativity.
Speaker 3: Though, Yeah, looking to the point where Heinz Ketchup can't
Speaker 3: be called ketchup.
Speaker 2: Yeah, well I found a thread on Reddit. But yeah,
Speaker 2: all right, well I'm gonna push us into picks a
Speaker 2: j Do you want to start us off with picks?
Speaker 3: Ah?
Speaker 4: Goodness, I don't know. Sorry, I actually today don't have
Speaker 4: anything top of mind. I'm going to need a minute myself.
Speaker 3: All right, Dan, Okay, so I actually have a pick
Speaker 3: I'm really happy about and it's this new TV show
Speaker 3: called The Penguin. It's about this Batman character, one of
Speaker 3: the Batman's villains, and what can I say, It's just
Speaker 3: an amazing show. And so far, by the way, Batman
Speaker 3: makes zero appearances. There's no mention of superpowers or anything
Speaker 3: like that. They do make occasional references to the latest
Speaker 3: Batman movie, but it's really subtle. Colin Farrell is absolutely
Speaker 3: amazing as the Penguin. He's totally unrecognizable. The makeup, the prosthetics,
Speaker 3: I understand, even shaved his head for the role in
Speaker 3: a certain way. But his acting is just it's James
Speaker 3: Gandolfini level. Really, he's giving the performance of his life.
Speaker 3: I think highly, highly recommended. So that would be my
Speaker 3: first pick. Everybody else there, by the way, is the
Speaker 3: acting is good all around, but he's he's just he
Speaker 3: just stands out. I really hope they're able to maintain
Speaker 3: this quality all the way through. I'm kind of halfway
Speaker 3: through the first season. I think it's the only season
Speaker 3: so far, and I really hope it doesn't get canceled
Speaker 3: or anything like that. So that would be my first pick.
Speaker 3: The second pick is I created an account on Blue
Speaker 3: Sky so if you for some reason have left X
Speaker 3: and are on blue Sky, then you can follow me
Speaker 3: now there as well, even part of a pack. There's
Speaker 3: a web performance pack, and I'm on there, and it's
Speaker 3: it's very much like X, you know. It's if anything,
Speaker 3: it's kind of like what X kind of used to
Speaker 3: be in a lot of ways. The algorithm feels less intrusive,
Speaker 3: which is a plus. The weird thing to me, especially
Speaker 3: is in kind of in an out to us politics,
Speaker 3: is the interesting fact that there's kind of a political
Speaker 3: divide between those people who stayed on X versus those
Speaker 3: people who went over to Bluesky. They're kind of saying
Speaker 3: that they went over to blue Sky because they were
Speaker 3: thick of the politics and wanted more pure technical stuff.
Speaker 3: But the politics really still find through. It's just a
Speaker 3: certain aspect of politics. And I'm not criticizing either ones,
Speaker 3: you know, but I'm just it's just a shame that people, really,
Speaker 3: you've gotten to the point where they can't talk with
Speaker 3: each other to the extent that they feel that they
Speaker 3: need to be on different social networks. But I'm still
Speaker 3: on both and you can find me either place. It's
Speaker 3: kind of annoying to have to post things twice. I
Speaker 3: think there are tools that should make it easier for me,
Speaker 3: and probably need to adopt one, but right now I'm
Speaker 3: still kind of posting on at both places, and those
Speaker 3: are marks for today.
Speaker 2: Awesome, AYJ did you want to jump in or should
Speaker 2: I go?
Speaker 5: Oh?
Speaker 4: I'll just come up with something.
Speaker 3: I think.
Speaker 4: I mentioned before that i'd played Portal a few weekends
Speaker 4: ago and got all the way through it for the
Speaker 4: first time, And actually most of the quotes that I
Speaker 4: remember were from Portal two, not Portal, So that's still
Speaker 4: to come. But if you haven't played Portal and you
Speaker 4: want a game you can just sit down and play
Speaker 4: in a matter of a few hours. The Companion que
Speaker 4: Bundle is available on Nintendo right now until December. We're
Speaker 4: not even gonna release by that anyway. Check Deco deals
Speaker 4: dot com. Keep your eye on Deco deals dot com
Speaker 4: and find out when games you love go on sale
Speaker 4: and get them there. But Portal is it's definitely worth
Speaker 4: it if you haven't. If you haven't played it and
Speaker 4: you just know the references, the cake is lie, that
Speaker 4: sort of stuff. It's a little bit morbid to play
Speaker 4: with a five year old, Like the first ten levels
Speaker 4: are fine, and then all of a sudden, there's blood
Speaker 4: on the wall. And my daughters, why is the blood
Speaker 4: on the wall, that's all?
Speaker 3: How does she recognize blood? Can't you just tell her
Speaker 3: it's ketchup? And so.
Speaker 5: I don't.
Speaker 4: I don't lie to my kids and I don't baby
Speaker 4: down explanations. When my three year old it's red pixels, yeah,
Speaker 4: but okay, fair, but it's representing it is It is
Speaker 4: not representing ketchup. It's representing blood.
Speaker 3: It's white roses painted red.
Speaker 4: Well with with my kids, even my three year old,
Speaker 4: when he asks a question, I will answer his question
Speaker 4: like an adult. And sometimes he will then ask, well,
Speaker 4: what does this word mean? Or what does that word mean?
Speaker 4: And our daughter, you know, she asked what does this
Speaker 4: word mean? What does that word mean? I am waiting
Speaker 4: for her to ask where do babies come from? It's
Speaker 4: it's got to come soon. But that's going to be
Speaker 4: a very I don't I don't know how to that what.
Speaker 4: I'm not gonna say it like I would to an adult.
Speaker 4: I don't think, but I'll.
Speaker 3: Say I'll tell you this story from my childhood. When
Speaker 3: I was like seven or something years old, somebody used
Speaker 3: the word prostitute around me. So I went home and
Speaker 3: I asked my mother, Mom, what does the word prostitute mean?
Speaker 3: And she, being having the similar mindset to yours, said
Speaker 3: it's a woman who sleeps with men for money. And
Speaker 3: I couldn't figure out for the life of me why
Speaker 3: somebody would pay someone to sleep with them, because it's
Speaker 3: all comfortable to have to share a bed with somebody,
Speaker 3: you know, you don't have as much space. And yeah,
Speaker 3: I just couldn't figure it out.
Speaker 4: Anyway, Well, when I was five, I asked my dad,
Speaker 4: and my dad told me and as as least graphic
Speaker 4: terms as he could, and I just thought that sounds
Speaker 4: so weird and gross. But then when I was about thirteen,
Speaker 4: I was like, got it.
Speaker 1: All right, I'm gonna throw in some picks. I always
Speaker 1: do a board game pick. I don't think I'm trying
Speaker 1: to remember if I picked this game last week or not.
Speaker 1: Maybe I'll just pick a different one. So not this
Speaker 1: last Saturday, but the Saturday before. I was helping teach
Speaker 1: games at the Board Game Convention. Right, so I have
Speaker 1: five or six games that we taught. I've already picked
Speaker 1: Challengers on here because I picked that. I played that
Speaker 1: game at SaltCON in March, and that was one of
Speaker 1: the games we taught. And there's another version of the
Speaker 1: game called Challenger's Beach Cup, which is the same rules
Speaker 1: with different cards that have different abilities. So I feel
Speaker 1: a little bit funny just pick in either of those
Speaker 1: because you guys can go pick them up and it's
Speaker 1: it's plenty fun.
Speaker 2: It's you know, the tournament war flag thing. You can
Speaker 2: go listen to the previous. So I'm hoping I didn't
Speaker 2: pick this last week, and if I did.
Speaker 1: I apologize, But probably one of my favorite games that
Speaker 1: we taught this time is called Gnome Hollow. You guys
Speaker 1: aren't looking at me like I picked this last week,
Speaker 1: so I'm gonna go with it.
Speaker 2: So effectively, it's.
Speaker 1: You're playing a game where you're placing hexagonal pieces on
Speaker 1: the board, you know, so you push them together and
Speaker 1: they create a path, and if the path creates a
Speaker 1: circle or a complete circuit, because a lot of them
Speaker 1: aren't circles, right, they curve at dif front angles.
Speaker 2: But you have to get them all to a line.
Speaker 1: You can't create anywhere it dead ends on another piece,
Speaker 1: so if you put it down, it has to continue
Speaker 1: any paths that it crosses. But you make these circuits,
Speaker 1: and then as you create the circles, what happens is
Speaker 1: you move markers on your board that's in front of
Speaker 1: you down and you get a reward for it. Now,
Speaker 1: the threes and the fours you don't get rewards. For
Speaker 1: the fives you get rewards. Six as you get rewards,
Speaker 1: and the sevens you get rewards, and two of the
Speaker 1: spots on the sevens, two of those rewards are you
Speaker 1: get to move another marker down and then you get
Speaker 1: something else with it. The game ends when all of
Speaker 1: your markers move down, or when you run out of tiles,
Speaker 1: and then you to add up your points, and whatever
Speaker 1: points you have you win. So you get points for
Speaker 1: each marker you've moved down right, and it's just you know,
Speaker 1: you get all all of them down, it's worth twenty
Speaker 1: five points.
Speaker 2: As you complete circles, you.
Speaker 1: Discover wildflowers and you automatically get one of those wild flowers,
Speaker 1: and you get a wild token that you can use
Speaker 1: anytime on your turn.
Speaker 2: And then what some of the rewards are.
Speaker 1: You get the wildflowers that other people discovered, and those
Speaker 1: tally up you get so many unique ones right, and
Speaker 1: so if however, many flowers, you get your points for that.
Speaker 1: And then as you complete the circles, you get the
Speaker 1: mushrooms that are on the circles, or there are other
Speaker 1: ways to get mushrooms, but you get those mushrooms, and
Speaker 1: then you can go to the market and sell them
Speaker 1: back and you get points in return, and that's essentially
Speaker 1: the game. There are a few other nuances, but it
Speaker 1: is really a fun game. It takes about forty five
Speaker 1: minutes to play.
Speaker 2: And board game.
Speaker 1: Geek waits it at let's see it's coming up two
Speaker 1: point two to oh, so casual gamers is pretty approachable.
Speaker 3: You know.
Speaker 1: It's really just visualizing how your tiles get you the
Speaker 1: size of the the circle you want, and you move
Speaker 1: the gnomes around to claim circles or to you know,
Speaker 1: get mushrooms or go to market. And that's the other
Speaker 1: piece to it. You have two nomes that you move.
Speaker 1: You can move each turn.
Speaker 2: So that's I mean, that's it. That's the game. It was,
Speaker 2: like I said, really fun.
Speaker 1: When I was teaching people, that take an hour, but honestly,
Speaker 1: with three or four people we were still you know,
Speaker 1: was people knew how to play.
Speaker 2: It was like forty five minutes because the turn order
Speaker 2: is real quick.
Speaker 1: You put down two tiles, you collect any rewards, move yournme,
Speaker 1: do whatever is involved to move in the nome next
Speaker 1: person's turn. So anyway, so yeah, so I enjoyed that.
Speaker 1: It's one that I kind of want to buy. So
Speaker 1: I'm going to go ahead and pick that. The other
Speaker 1: thing that I'm gonna pick here. So I am actually
Speaker 1: on my new computer, the my laptop. It's funny, we
Speaker 1: were talking about Docker, the Docker engine on the Mac.
Speaker 1: When I was running it one of my clients apps
Speaker 1: on it, it just.
Speaker 2: Got to the point where it just wasn't.
Speaker 1: It worked, but it was super slow, and so I
Speaker 1: determined that I needed, you know, the laptop six years old,
Speaker 1: and it just yeah, it just wasn't keeping up. And
Speaker 1: no matter what I did to kind try and clear
Speaker 1: stuff off or not run as many things, it just
Speaker 1: didn't quite hack it. So I looked around a new
Speaker 1: Mac at the level that I wanted because I'm starting
Speaker 1: to do AI stuff and I want to I want
Speaker 1: it to be able to run that stuff.
Speaker 2: And then it really bogged down the laptop did I'm like, okay,
Speaker 2: so the machine at the level I wanted a new
Speaker 2: Mac was going to cost me like nine grand, So.
Speaker 3: You wanted something like an M four something.
Speaker 2: Yeah, something.
Speaker 1: So what I wound up doing was I looked around
Speaker 1: and I thought, Okay, well, a lot of folks in
Speaker 1: the rails community are talking about these Linux machines that
Speaker 1: they're picking up. So the laptop brand that a lot
Speaker 1: of people are going with is Framework laptops, and they
Speaker 1: run a Buntu or whatever whatever you want. Really, and
Speaker 1: then for the desktops, they've been going with System seventy six,
Speaker 1: and so that's who I'm gonna pick is System seven.
Speaker 2: I got a desktop from them. It cost me about
Speaker 2: three grand, and.
Speaker 1: Yeah, but it I can't remember all the specs on it,
Speaker 1: but it's it's it's a pretty serious machine.
Speaker 4: And you got more than just one terabyte of storage
Speaker 4: for that three grand, unlike on Apple.
Speaker 2: Right, So I got the the Thelio model.
Speaker 3: What's it for you? Does it have?
Speaker 2: By the way, I'm looking it up right now, So
Speaker 2: it has I can probably just pull up my order.
Speaker 3: There'll be some AMD or something.
Speaker 2: Yeah, it does have an am D. Let's see.
Speaker 1: I got the Thelio Mirr Elite as a twenty four
Speaker 1: core fourteenth gen Intel.
Speaker 3: Nine, Intel Cool Interesting.
Speaker 1: Has one hundred and twenty eight gigs of RAM, four
Speaker 1: terabytes of storage, AMD radion Rix seventy nine hundred gre.
Speaker 2: Yeah.
Speaker 1: So I've been pretty happy running stuff on it, and
Speaker 1: it you don't avoid the warranty if you have to
Speaker 1: repair it or add cards.
Speaker 2: To it or anything.
Speaker 3: It's not Apple.
Speaker 2: No, it's not Apple.
Speaker 1: And it cost me about seven grand lesson it would
Speaker 1: have cost me to get a comparable Apple machine that
Speaker 1: did you know, that had mostly similar.
Speaker 3: Specs and you're running Ubuntu on it.
Speaker 2: I'm running a Buntu on it.
Speaker 3: Interesting.
Speaker 1: I wanted to run the omacube setup, which is what
Speaker 1: DHH runs, but I would have had to reinstall Ubuntu
Speaker 1: and I'm lazy and I didn't want to do that,
Speaker 1: so I'm not doing that. But I also switched my
Speaker 1: development environment back to Emacs and I've been pretty happy
Speaker 1: doing that. So anyway, it's it's been super cool. Oh yeah,
Speaker 1: I love me some Emacs. I had the Emacs key
Speaker 1: bindings running on vs code, so it really wasn't too
Speaker 1: much of a switch. The biggest switch is remembering to
Speaker 1: hit control instead of command.
Speaker 3: And running and writing scripts and listen.
Speaker 5: Yeah.
Speaker 1: Well so that's that's my third pick. So I part
Speaker 1: of getting an AI, I kind of on a lark,
Speaker 1: started asking chat GPT to help me write code, right.
Speaker 1: And before what I would do is I would ask it, hey,
Speaker 1: like when I was trying to write an audio player, right,
Speaker 1: and so I would ask it to help me. Okay,
Speaker 1: how do I you know, what's the web audio API for?
Speaker 1: You know, if I click a button to have it
Speaker 1: play the audio, because you could just put the audio
Speaker 1: tag in, tell it to show controls and you get
Speaker 1: an audio player. But it's not a very nice audio player, right,
Speaker 1: and it doesn't have all the features that I wanted,
Speaker 1: And so you know, I started.
Speaker 2: Asking it how do I get this? How do I
Speaker 2: get that?
Speaker 1: And then on a lark, I said, can you write
Speaker 1: me an audio player? I'm using Stimulus jas and it
Speaker 1: wrote it for me. And then it was like, okay,
Speaker 1: I want this feature, in this feature, in this feature,
Speaker 1: and it added them in. And then I asked it
Speaker 1: what features isn't missing, and it told me a whole
Speaker 1: bunch of features I could ask for, and so I
Speaker 1: asked it for those and then I copied and pasted
Speaker 1: the whole thing into my app.
Speaker 2: But wouldn't you know it? It just worked.
Speaker 3: So you know, as a spoiler, we're going to have
Speaker 3: Uncle Bob as a guest on the show, and in
Speaker 3: the near future, maybe we should also get Richard Stillman
Speaker 3: if he asked him, if he's willing to come with
Speaker 3: the show.
Speaker 2: I'm open to that. I think it'd be great. But
Speaker 2: the other thing that I've been doing with chat GPT
Speaker 2: is just.
Speaker 1: Sometimes I just need a little bit of direction here
Speaker 1: or there with stuff, and it's it's been great there too,
Speaker 1: So I'm going to pick chat GPT as well. I
Speaker 1: might be a little late to the game there, but
Speaker 1: it has been this amazing tool. It's helped me with
Speaker 1: layout stuff. One thing that I'm working through right now
Speaker 1: for my client is they have a report essentially this
Speaker 1: generated every every time a new transactions added to their
Speaker 1: ledger and it takes forever to run. And so I've
Speaker 1: been playing with it on how do I run this?
Speaker 1: How do I run this report? Just in post gris
Speaker 1: QO and so, I mean it's been a lot of
Speaker 1: there's a lot of refining, right It's like, Okay, I
Speaker 1: need it to do this now, and I need it
Speaker 1: to this, you know, I need it to operate in
Speaker 1: this way, and it's it's been pretty awesome. I mean
Speaker 1: I've had to tweak a few things, but it's been.
Speaker 2: Yeah, it's been wild. So if it's not a tool
Speaker 2: you're using, I understand that Claude is another tool that
Speaker 2: you can use.
Speaker 1: We just recorded an episode on Ruby Rogues where we
Speaker 1: were talking about how to do a lot of this,
Speaker 1: and a lot of the things that we talked about
Speaker 1: are applicable to JavaScript as well, just on how the
Speaker 1: tools work and what some of the tools are. Some
Speaker 1: of them are Ruby specific, but a lot of them
Speaker 1: really aren't. So anyway, Yeah, I'm really really happy with
Speaker 1: all that. And I am working on the AI dev
Speaker 1: boot camp that's going to be an AIDEV bootcamp dot com.
Speaker 2: I'm redeploying, I'm reworking a.
Speaker 1: Ton of stuff on top end devs and getting that
Speaker 1: deployed and so you'll be able to sign up as
Speaker 1: soon as I.
Speaker 2: Get that deployed, is essentially what we're looking at.
Speaker 1: So right around Black Friday or Cyber Monday, and I
Speaker 1: kind of have a number of people that I want
Speaker 1: in the first cohort, and so I think I'm going
Speaker 1: to offer a Black Friday deal that's going to be
Speaker 1: just considerably less than what I'm going to charge for
Speaker 1: it in the long run, just so that I know, Hey,
Speaker 1: I've got about twenty people in that are going through
Speaker 1: the boot camp starting in January.
Speaker 2: So keep an eye out.
Speaker 1: If you want to, you can just email me Chuck
Speaker 1: at top endepth dot com and I can just tell
Speaker 1: you when it's up or you know, however you want
Speaker 1: to do that. But yeah, just just some way awesome
Speaker 1: stuff there, all right, Avashi, what are your picks?
Speaker 6: I'm going to go with recently discovered Animal Manimal is
Speaker 6: like the next generation replacement for julipital notebook.
Speaker 5: So it's like a kind of an interactive Python environment
Speaker 5: that is also graphical, so you basically value yourselves or
Speaker 5: you can combine markdown and graphics and then and buy
Speaker 5: on output and stuff like that. It's very handy to
Speaker 5: build a widgets or calculators of what I built with it.
Speaker 5: I build like que Filly calculators and like various assistant
Speaker 5: design things that basically you can put like the balls
Speaker 5: and inputs and then just runs the Python thing. So
Speaker 5: it's very easy for doing interactive, interactive stuff, especially that
Speaker 5: involves graphing and mathematics and stuff. Previously, I used vis
Speaker 5: Coode in Jupiter Notebooks for this, but animals like it's
Speaker 5: really cool, so check it out.
Speaker 2: Nice.
Speaker 1: Yeah, a lot of people doing interesting stuff in Ai
Speaker 1: with Jupiter notebooks, so that sounds interesting, all right, Avishai.
Speaker 1: If people want to find you on the internet, I
Speaker 1: see that your handles on your video.
Speaker 2: But for the people who aren't getting this on video,
Speaker 2: how do they find you?
Speaker 5: So Nukemberg on Twitter that's n u k E m
Speaker 5: b e LG mostly there. Also I have a YouTube
Speaker 5: channel which is not very active, but it does contain
Speaker 5: like a playlist of a lot of talks that have
Speaker 5: given videos. Or if you just google a visa Shadom
Speaker 5: or youtubele Google and you can find that stuff.
Speaker 2: Awesome.
Speaker 1: All right, Well let's go ahead and wrap it up
Speaker 1: until next time, folks max out