VALENTINO_STOLL: Hey now.
DAVE_KIMURA: And we have Steve Edwards.
STEVE_EDWARDS: Hello. Hello. Coming from cloudy and rainy and cold Portland, Oregon.
DAVE_KIMURA: And we have Dan Shapir.
DAN_SHAPPIR: Hey from warm and sunny Tel Aviv where the weather is great, but the politicians are terrible.
STEVE_EDWARDS: I prefer the latter. I don't think we need to fight it out too much, but we'll see how it goes.
DAN_SHAPPIR: Yeah. Otherwise Chuck might have a few fewer panelists at the end of this.
Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So if you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume, we'll get you that and you can just kind of use the formatting. It comes in Word and Pages formats and you can just fill it in from there.
STEVE_EDWARDS: You have to be honest when you first said Hotwire, the first thing I thought of was the commercial for hotwire.com.
STEVE_EDWARDS: Well, if I remember stimulus, it's an Alpine JAS, I don't know if it's precursor or sibling. Dan, I don't know if you remember when we interviewed the guy from Alpine, it's about a year and a half ago. You're going to render it all in HTML and if you just need little sprinkles here and there of something for a select list or some page interactivity, you can just drop it in as compared to a whole framework like a viewer react. Something like that, am I correct?
DAVE_KIMURA: I think that's fair to say, wouldn't you, Valentino?
DAN_SHAPPIR: So if I'm understanding correctly what you're saying is that if in the past I wanted to update content on the front end side using the runtime on the backend, it would literally require replacing the entire page. And what you're getting now is the ability to trigger updates that only update certain portions of the page and you don't have to use, like you said, iframes for it. It's just, it's smart enough to be able to make effectively like an Ajax call to the backend, but instead of getting data it's getting HTML and then swapping that HTML into the page in the appropriate parts and in that way creating the interactivity without having to reload the entire page. Is that correct?
VALENTINO_STOLL: Yep. Yeah, exactly. And I mean, it uses WebSockets as its way to do that, to stay up to date kind of in real time, if you will. I can't really say real time, but it gives it that bi-directional aspect and kind of how that's the fundamental channel for which it does those pieces of it.
VALENTINO_STOLL: Well, I think the first thing is to keep SEO and accessibility in mind where when you do have all these little spinners come in, so let's say a highly reactive dashboard. I think that's like the primary use case here that we're talking about where you have 20, 30 different little panels that are bringing in their own individual data fetching from the server. And if you first load the page and if you have 30 little tiny windows, and then as it gets the data, it expands out that shift in the content layout not only hurts your SEO, but for those who are maybe a bit more sensitive to the quick flashing or the quick moving items, then that could also cause some issues there. So having default heights, so there's not as much content shift layouts and stuff happening, I think is going to be the first important thing. But one nice thing about Hotwire that we get is typically when you make a request to the server end and you're returning the HTML over the wire. Sometimes you would have situations where you are rendering out the entire response, including layouts and all that kind of stuff, even though you just need a tiny snippet of the code. So Hotwire will only render out that small snippet that's actually required. But then to your point, if the backend is having to do very heavy calculations, and it's going to take a while regardless, then we do have that kind of problem. You know, I think one solution if you are doing a charting library or something like that is you can go ahead and display out the chart, but without any data and let that data kind of flow in and animate to the data points that it's going to retrieve. But I don't know what we would do other than that.
DAN_SHAPPIR: What about caching and CDNs? How do those kind of things fit into these this type of architecture?
DAN_SHAPPIR: If anything, there's a renaissance. Everybody's moving to the server now.
VALENTINO_STOLL: Yeah, I mean, but what you're talking about is what, you know, how do you handle the cases where you have like empty skeletons, where you're hydrating, you know, the skeleton as it comes in? You know, that to me, I thought the solution is server-side rendering.
DAN_SHAPPIR: Well, yeah, but...VA It kind of depends on how you do server-side rendering, because server-side rendering at the end of the day is about generating the content on the server. But that's not panacea, that's not a free lunch. I mean, it still works, that needs to happen. And like Dave said, if you're making, let's say, a lengthy database query or something like that, it could take some time to generate the data, even if the server is relatively quick. Another potential problem is that the server might be far away. And the round trip requires multiple hops. And then again, you won't get such great behavior. The thing is this. Very often, it really depends on the site. I mean, if you're creating a site that's super dynamic, like a dashboard, then you probably care less, not I won't say not at all, but you care less about the initial, let's say, startup time. You care more about how responsive the site might be once it's loaded. Also, you probably care a lot less about SEO. On the other hand, if it's a site like a shopping site, well then you need to ask yourself, do I really need to generate the main part of the content on each and every visit? Can I like, I don't know, generate much of it, like once, cache it in one way or another, and serve the parts of the HTML itself directly out of cache. It seems to make sense, but it can get kind of tricky, it seems to me, when the communication between the backend and the frontend is so dynamic.
VALENTINO_STOLL: Yeah, and I think one important thing that we should note is that you have to be using H2 or H3 in these scenarios.
DAN_SHAPPIR: Oh, yeah.
VALENTINO_STOLL: And that's regardless of which back-end framework we're using or front-end framework. Because H2 and H3, for those who don't know, is going to specifically introduce an HTTP2 that you can use one connection to request multiple assets. So you don't have to do several SSL handshakes to request several different images from the same server. So that's going to be a must if you are doing a lot of these little tiny loads.
DAN_SHAPPIR: It does something known as multiplexing. It basically enables multiple HTTP downloads over a single connection, rather than requiring multiple connections and only allowing one download per connection at a time. But I think this is more or less almost a given these days. I'm hard to...
VALENTINO_STOLL: No, it's not. No, I've still come across sites that are serving HTTP 1.1 and they're downloading like 50 different things on that page. You can only download six at a time, I think. Is that correct with HTTP 1.1?
DAN_SHAPPIR: The funny thing is the reason that it can download six is that when the connection to the server is HTTP 1.1, the browser will actually open six TCP sockets to the backend so that it can do six HTTP downloads in parallel, one over each socket. So that's the reason you see the six download limit. With HTTP2, it actually opens only one TCP socket, but like I said, it can actually do multiplexing on top of that socket, so it can actually download multiple resources over that single TCP connection. And HTTP3 actually replaces TCP with a different underlying protocol, which is actually implemented on top of UDP, and is more, let's say, modern web friendly, because you know all these other protocols, TCP is a protocol that's like what, 50, 60 years old? I mean the internet today is a different place. So yeah, things have changed. I'm kind of surprised. I mean, if you're using modern infrastructure, modern hosting or modern infrastructure, then you should be getting HTTP 2 or 3 out of the box.
VALENTINO_STOLL: Yeah, I think it's just how some websites have it configured. I know if you throw Cloudflare in front of there and enable the proxy, then you get H2 by default.
VALENTINO_STOLL: It's pretty self-explanatory to me.
DAN_SHAPPIR: For sure, go for it.
DAN_SHAPPIR: Oh, I understand that it's a object-oriented programming language with a functional bend. Would that be a good general description of it?
VALENTINO_STOLL: It's getting better. It is definitely object-oriented first, but people like to, as you say, bend it to be functional in many ways.
DAN_SHAPPIR: I know that it has lambdas and stuff like that. In fact, it makes a lot of use of those sort of things, doesn't it?
DAN_SHAPPIR: Well, it wants to be. In a way. It isn't exactly.
VALENTINO_STOLL: It wants to be.
DAN_SHAPPIR: Question, though. So you said that it's less asynchronous. Is it a multithreader? And I apologize that I'm asking questions on a Ruby podcast that all the Ruby listeners probably all know the answers to. But is it a multi-threaded programming language or a single-threaded programming language?
DAVE_KIMURA: I'd say it's single-threaded, but it can sort of do multi-threading. So you can thread together multiple things together, have them run asynchronously. And if we're talking about just Ruby on Rails and web designs, we just kind of scale by adding in more workers. So if you have a large machine, you just scale up more services to handle more requests. And then you can horizontally scale and add more servers beyond that.
VALENTINO_STOLL: And there are versions of Ruby that are multi-threaded. So if you want that capability, you can use it using a certain runtime of Ruby.
STEVE_EDWARDS: So getting down to the basics, I mean, for me, Ruby has always either been a gem or a title of a song by Kenny Rogers. But what is there's Ruby and there's Ruby on rails. So what is, is rails built on top of Ruby? What it is, what's the difference or how do they work together? Let's put it that way.
STEVE_EDWARDS: So it's the front end tool for... Yeah,
VALENTINO_STOLL: Rails is the framework. Yeah.
DAN_SHAPPIR: Yeah, but it's a framework that's mostly about data access, isn't it? Less about UI construction or am I getting it wrong?
VALENTINO_STOLL: I mean, so does Rails do the actual HTML rendering?
DAN_SHAPPIR: Yep. Yep.
VALENTINO_STOLL: Okay. It's a full stack. So it takes, it tries, you know, originally it was, you know, the blog engine, right? You know, you watched the creator DHH create a blog in 10 minutes was like his original pitch that made, you know, made it so popular originally. And, you know, from the back end, making that modeling the database all the way to the front end, you know, making a crud, you know, create a blog post, enter a title and save it to the database and then be able to view a blog. Right. Like that whole stack from the back end to the front end was all reels. And it's encapsulated that idea of, okay, if you need to build something on the web, you can use Rails as a framework to do that.
STEVE_EDWARDS: So it's sort of like the whole, what's the term, Dan, where you use the same language? Isomorphic?
DAVE_KIMURA: Or WebAssembly.
DAN_SHAPPIR: Or WebAssembly, which is what most people don't do.
VALENTINO_STOLL: But- There are people that do that.
DAVE_KIMURA: Yeah, you know, brave souls. But one more thing if I recall about Ruby and maybe again, maybe my knowledge is either updated or my recollection is incorrect, is that it uses a lot of conventions to speed up development about how it kind of maps items or data in the database into objects and in memory or stuff like that. Is that correct?
DAVE_KIMURA: Yeah, so we do have an ORM object relational mapper called ActiveRecord. And it makes it very easy to interact with the database. So if we have a table on the database called users, and that has several columns, first name, last name, email, then we can pull up that user with like a user.first. And then with that object, we can then call user.firstname, user.lastname, and that's immediately pulled from the database. So it's putting it into the server memory while we have that object initialized. And once the request is done, it often should release it from memory.
Hey, have you heard about our book club? I keep hearing from people who have heard about the book club. I'd love to see you there. This month that we are talking about Docker deep dive. That's the book we're reading. It's by Nigel Poulsen. And, uh, we're going to be talking about all things Docker, just how it works, how to set it up on your machine, how to go about taking advantage of all the things that offers and, uh, using it as a dev tool to make sure that what you're running in production mirrors what you're running on your machine. And it's just one of those tools a lot of people use. Really looking forward to diving into it. That's February and March, April and May, we're gonna be doing the Pragmatic Programmer. And we're gonna be talking about all of the kinds of things you should be doing in order to further your career, according to that book. Now, of course I have my own methodology for these kinds of things, but we're gonna be able to dovetail a lot of them because a lot of the ideas really mesh really nicely. So if you're looking for ways to advance your career, you're looking to learn some skills that are gonna get you ahead in your career then definitely come join the book club. You can sign up at top end devs.com slash book club.
VALENTINO_STOLL: Yeah. It's just amazing what you can do with Ruby. Like, uh, last night or two nights. So I created this monstrosity in Ruby. That's a lot of fun. So I created an active record, um, wrapper for Redis. And so I needed to store a bunch of data only temporarily for however long that Redis server is going to have it. So it works just like it would, you would expect any other active record object and Rails to work. And it'll just bring in a bunch of data stored in memory on Redis. And then I can just pull it down and interact with it, just like I would any other active record object. So it made my development. Actually creating that wrapper was a pain. I had to get down to the lower level Redis functions to set and get the data. But then once I did that, actually consuming that made it so easy. And I actually made it reusable so I can use it for other things as well. So just the power of flexibility. And this is, this can be said about any language really. But with the Ruby on Rails framework specifically, just having a lot of this built for us already makes it so much nicer and easier and faster to develop and work in.
DAN_SHAPPIR: By the way, Steve, how do you do data access in your projects?
STEVE_EDWARDS: Funny you just asked me that. I was just about to ask a couple of questions about that. So most of my work, at least for my day job, is a combination of you and Laravel, if you're familiar with Laravel, which is a PHP framework. And so there are a couple of ways to interact between front and the backend. If I'm doing a front end, like a small project, sometimes I'll use a headless CMS, like a Prismic. There's Contentful, there's Sanity, there's all kinds of them out there. And they will have either REST or GraphQL APIs that you can call from your front end or your backend, depending on what framework you're using. With Laravel there's actually a couple of different ways. The way in our large app, it's been around for a long time, is Laravel will create REST API endpoints with your posts you put, you get your patch, that kind of stuff. And so from your front end, whether it's in a state management, such as Vuex, I'm primarily Vue is what I work in, you'll make your REST API calls, using a library like Axios, which returns a promise, and then you get your data and do what you need to do with it. So first question is that if I if I was to use view with react for instance, is that the same approach you'd use in terms of just generating standard rest API endpoints from root from Ruby? Or is there another way that you would pass data back and forth between the front and the back?
VALENTINO_STOLL: We really don't worry about state or that kind of stuff on the front end, especially if we're doing Ruby, because it's all server rendered.
STEVE_EDWARDS: Yeah, it takes data out of the picture. That's just one way. But just how would you how would you pass the data back or could you use. Would you use like a viewer react or Svelter and Angular with Ruby on the back end and if so how would you connect the two.
DAVE_KIMURA: Yeah, it's kind of where I think as Rails developers and Ruby people in general, uh, it's kind of in the, at a divide right now where there are people where they believe, okay, the front end should be completely separate from the backend. They like the very, you know, single page application, uh, you know, have your front end code do the front end stuff. The backend code can still handle the backend code. And when there's some blend, we can take advantage of features that you know, are offered in the framework for Rails in this case. And then there's a whole other group that believes like Dave, you know, server side are like these, you know, do everything in the server and just, you know, have the page dynamically update based on the HTML that we get from the server. Um, and forget about all of the front ends because they're not needed. Right.
DAN_SHAPPIR: Not just the bots, users don't like it either so much.
DAN_SHAPPIR: React had two main things going forward from my perspective. One is the fact that both of them stem from the fact that from one point, which is that it had a really lively ecosystem because it was the de facto leader in front end development and the outcome of that was that you could find people, you could recruit people who are knowledgeable in React relatively easy or easier than other technologies and you also had a lot of components and reusable code that you could be using because everybody was creating their components for React. So those were the main advantages there. By the way, if I want to use a particular component, say you need some sort of a fancy date picker or a combo or whatever in your Ruby on Rails implementation, what would you use these days?
DAVE_KIMURA: I would probably try to find a vanilla.js library, so like select two I think or something like that and just bring it in and wrap it around a stimulus controller and then use it so it's contained and easy to maintain.
DAN_SHAPPIR: Wow, you're going way back. I think the more-
VALENTINO_STOLL: Yeah, it's kind of funny. I throttle my browser to 3G just anytime I'm testing something for that very reason, because it is a huge issue. Even just think about yourself with a brand new iPhone, if you go down the street and you hit a spot that isn't covered in a wonderful network, you're stuck just like somebody who has one of these knockoff Android phones, right? with a very similar experience.
DAVE_KIMURA: Well, back in 2014, we got the iPhone 6. And that was an amazing phone. It was a flagship phone at the time. But its speedometer 2.0 score was around 24. Fast forward a few more years, the Apple iPhone X has a speedometer to point a score of almost one hundred and the iPhone twelve pro another flagship phone has a score over two hundred. So we are getting like exponentially faster on our mobile devices where back in twenty fourteen and earlier I mean as you are saying it was just a horrible experience. No you didn't have for the LTE network and everything was slower.
VALENTINO_STOLL: Yeah, you know, and I bring all of this up because I'm curious. I'm not sold that it's going to go one way or the other still, right? I feel like this pendulum is still swinging and I feel like, you know, while there is this huge gap, people are going to continue to develop more client heavy applications. At the same time, they're also going to continue developing higher, you know, more server backend stuff. And because of these disparities, depending on your use case, right? Like one is going to be more favorable than the other and there's going to be a middle ground either way. And I'm, there still isn't really a winner, right? Because there are so many different, you know, edge cases.
DAN_SHAPPIR: Or the way that AJ likes to call it, it's a superset of a subset, which makes it a totally different thing.
DAN_SHAPPIR: So it's an interesting point that you bring up and maybe we can start summarizing with that is that React in particular was originally not even positioned as a framework. It was positioned as a library for generating the front end or the viewport. So it wasn't really a full stack solution for your business. It was intended for a very particular aspect or part of the solution that you might be building. It's really interesting because these days it's actually undergoing a sort of a metamorphosis kind of becoming a full stack. There's something called React Server Components. It's kind of being subsuming or being subsumed by Next.js. And in that sense, I'm thinking that a future version of Next.js with React, with a future version of React, might actually be positioned as an alternative to Ruby on Rails in this regard.
VALENTINO_STOLL: Yeah, that'd be interesting to see how well that plays out, you know?
VALENTINO_STOLL: Well, do we have any final takeaways other than just use Ruby?
DAN_SHAPPIR: All I can say is that I remember it was a few years back, I was at this largest meetup and a lot of representatives from different companies and I was the kind of schmoozing and I was asking different people which technologies they were using, you know, in their stack. And everybody was using something different on the backend. You know, some were using Ruby, some were using Java, some were using PHP, some were using other things, but everybody was using React on the front end. So, you know, time will tell what happens. We will see.
Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End Devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive, and we're gonna be going into Docker and how to use it and things like that. We also have workshops on the following topics, and I'm just gonna dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time, they also want to make more money. And so we're gonna talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. That one's gonna be on February 7th, February 9th. We're gonna have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're going to actually brainstorm together. You and whoever else is there and I, all of us are going to brainstorm on how you can get ahead. Um, the next week on the 14th, we're going to talk about how to grow from junior developer to senior developer. The kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a Visual Studio, uh, VS code Tips and tricks. On the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at topendevice.com slash sign up.
DAVE_KIMURA: All right. Well, I'm going to push this over into. What are we currently working on or has our piqued our interest? So I'll go first. I've been diving into Python lately. I've been doing a lot of machine learning learning and it's been quite the road. And I must say I much prefer Ruby over Python because I really hate my language dictating my white spaces. It's so annoying. But Python is like the de facto language for machine learning. And I figured that would just add another tool into my tool belt. So I've been diving into that lately. I initially tried on AMD cards, but found that they were finicky at best. So I did pick up a 4080 Founders Edition for playing with and for machine learning. And I love it. It's so nice. So.That's what I've been doing lately.
VALENTINO_STOLL: The Founders Edition, what is that?
DAVE_KIMURA: Nvidia RTX 4080 graphics card. Oh, card. OK. And Valentino, what's got your interest lately?
VALENTINO_STOLL: In a similar light, I'm heavy into machine learning at the moment, mostly around embeddings and generating vectors and storing them and performing analysis on it like that. It's kind of exciting. We use Neo4j, which is a graph database. So I'm learning how to store vectors in that and being able to query on them and run the calculations in Neo4j, which is interesting. But it works well because it's a graph database and that's kind of what it does. So we'll see, time will tell, but I'm kind of enjoying how easy it is to play with all this stuff. I have very little machine learning experience, so I'm able to get started really quickly, which is kind of incredible. So I'm excited to see what else I could do with it.
STEVE_EDWARDS: You know, it's interesting you're talking about machine learning because as of today, I have to do the same thing only because we are hiring at my place of work. And I'm sort of in charge of doing the hiring. And one of the things we're looking to hire as a data scientist and considering I know absolutely nothing about any of that, I'm having you dive in so that I don't sound like a complete moron when I'm trying to interview people for a data scientist. So I've been looking at TensorFlow or Python and just trying to figure out how the heck all of this works. It's an interesting note. I have a friend, an old friend from college who is very big into machine learning in the biosciences field in genetics. And so she uses a language called R, just the letter R, which is, as I understand it, very big in the scientific community in terms of processing.
DAN_SHAPPIR: It's a good language for doing all sorts of computations and statistics as I recall.
STEVE_EDWARDS: Right, yeah, that's my understanding of it too. So yes, I am not by choice, but by force, I'm having to delve into machine learning and just trying to get my head about data models and processing and how all that works.
VALENTINO_STOLL: I've heard from somebody at OpenAI talk about kind of hiring and getting teams to work with their APIs and They've seen a huge internal struggle with their data teams in that their models work so well that it kind of obviates the need for any other traditional maybe re-workings or traditional thinking in machine learning that is typical. So what they've seen is a very hard adoption of people that are already currently in that machine learning world adopting kind of the new large language model thinking. And I thought that was a kind of an interesting take.
DAN_SHAPPIR: I understand. I'm just saying that for you, if you want to play with these APIs.
STEVE_EDWARDS: I see.
DAVE_KIMURA: You know, the problem with that, I found because there's Ruby wrappers around PyTorch and that kind of stuff as well. But I found that as soon as you need something and you have deviated from the community standard way of doing it then any kind of documents or references can be a hit or miss, whether or not it'll apply in your application. So you might be banging your head against the wall a lot more than you would have to if you had just gone the community standard route.
DAN_SHAPPIR: So you're saying Python is essentially the mainstream. And when you deviate from that, you're running a risk.
DAVE_KIMURA: Yeah. I think that's very fair to say.
DAN_SHAPPIR: Sounds right.
DAVE_KIMURA: So, Dan, do you have anything that's piquing your interest?
DAVE_KIMURA: Cool. Steve, do you have anything that you're working on or are peaking your interest?
STEVE_EDWARDS: Well, like I said, there's the Mesh Machine Learning. Then what I had talked about earlier is I'm really getting in playing with Inertia.js because for me, it was a tool that allowed me to plug and play what I knew best in terms of backend to frontend and mix them together in a way that's really quite performant. Usually if I wanted to do some front-end project that used a CMS, I was using a headless CMS, but I don't like those because sometimes I really want fine-grain control over my data storage and how it's modeled and accessed and all kinds of little tweaks. So using Laravel with my SQL database really gives me the control that I'm familiar with and I like. So it allows me to control everything, start to finish, in a way that makes it easy for me for my particular application.
DAN_SHAPPIR: Okay, took me a second to get it.
STEVE_EDWARDS: And then finally, whatever nationality you are while you're doing the potty dance, what nationality are you when you're done? Finish.
VALENTINO_STOLL: I got one more for you.
STEVE_EDWARDS: Go for it. What do you call a cow that's just had a baby?
STEVE_EDWARDS: Decaffeinated Yes You know, the cow with two legs is lean beef or Eileen and yeah, there's all kinds of great ones Here's what do you call Valentino? What do you call a cow that doesn't feel pain? Just a C right no ow
VALENTINO_STOLL: Knock-knock. That's a good one.
STEVE_EDWARDS: Who's there you? You who?
VALENTINO_STOLL: summer blowout
DAVE_KIMURA: If you've never seen frozen, which I have three girls, so they've all seen it hundreds of times. Yes, the greatest joke ever
STEVE_EDWARDS: I can remember that because at the time frozen came out my daughter was in middle school and I can still remember all through that year. They would you know at their graduation parties they're Belting out the songs, you know frozen Everything was frozen. Okay. Thank you. Can we move on?
DAN_SHAPPIR: Yeah, for sure. We would love to have you on our show as well. And it's been a pleasure being your guest. So thank you for having a lot of fun.
VALENTINO_STOLL: Yeah, thanks for coming on. This was great.