Beware The Blinking Folder Of Death

Show Notes:
Links:
Stripe
Spam Nation by Brian KrebsBad To The Bone by George Thorogood
GrammarlyEgghead.ioUdemyChris OliverJumpstartHeyaLambyStimulusReflexAndrew Mason
Remote Ruby podcast
Honeybadger

Full Transcript:
Josh:
So I'm sitting in my chair with this laptop and the thing literally crashes in my lap. And when I turn it back on, it gives me that blinking folder. The blinking folder. I don't know if you've ever seen the blinking folder, Ben says he hasn't.

Starr:
I've never seen it.

Josh:
The blinking folder is what you get when there is no hard drive attached to the system.

Starr:
Oh, no. What's there? Is there a hard drive in it?

Josh:
There was. It's not finding it anymore.

Starr:
I mean, is there one physically in there?

Josh:
There is a physical hard drive in the system. Yes.

Starr:
Okay, that's good. That's good.

Josh:
However, the hard drive I suspect has finally croaked. So now I've had to... I've literally had like two laptops die on me in one week. I don't know if I'm cursed or something.

Starr:
Well that's what you get for using that cheap aftermarket hardware.

Josh:
Right, yes probably. Just, I probably should never have upgraded the hardware, the hard drive. Anyway fingers crossed because if this Mac mini kicks the bucket then it really is back to Linux.

Ben:
It's just the universe's way of telling you it's time to take a vacation.

Josh:
I think you're right Ben. I've been saying that I could use a vacation.

Starr:
You two were talking about taking vacations and then like the world ends, so-

Josh:
Well, yeah that's like, the world ends and then it seems like... I don't know I've just been feeling pressure to get stuff done. I don't know.

Ben:
Yeah getting stuff done is a good thing.

Josh:
Yeah, it... Actually making progress on something is one way to kind of combat anxiety too.

Ben:
Well, speaking of getting stuff done. So while you've been trying to actually get anything done this week, I've been working on the... I was going to go on vacation, I was thinking about taking time off but then you said, "Well, I could use your help on this task." And so I'm like, okay, I'll help you with that. And that was two weeks ago and I thought it was going to take two days but it didn't end up taking two days. So what I've been working on-

Josh:
Sorry.

Ben:
That's totally fine. You know like sometimes the thing that's great about being one of the few people at Honeybadger is that we get to decide what we do, right? We don't have deadlines that we have to meet, We don't have like deliverables that we promised. And so when you have a case like this, where I felt like, there's something I want to get done here, we can just do it. So the task you gave me was to get some new pricing support ready. So we have some new pricing that we want to deploy. It's going to require some changes in our app too, because we're changing how we're structuring the pricing.

Ben:
And I'm like, yeah, I can bust it out real quick. And so then I looked at doing that and the way that... So Stripe has changed how they arrange the products and the plans and how you do pricing, since we launched with Stripe, seven or eight years ago. And I decided I wanted to use this new approach that Stripe has but the trick there is that you have to use the new API version or a recent API version. And we were not using a recent API version. We were using an API version that we started using back eight years ago. Which happened to be an API version of Stripe's from like, 2011. So-

Josh:
2011.

Ben:
Yeah. So I decided, you know what-

Starr:
It was year, you know?

Ben:
Yeah, it was a good year.

Josh:
It's a good vintage of API, like-

Starr:
Yeah. Exactly.

Josh:
Got to hand it to it.

Starr:
Like some people call that legacy, I call it vintage.

Ben:
Well, either way, props to Stripe for how they do their API versioning. It is freaking awesome. Like, you can stay on that old version as long as you want, basically, they will support it until the end of the internet, looks like.

Josh:
Yeah.

Ben:
And they have a really awesome way to manage the upgrade process, when you decide you do an upgrade and their documentation is very clear about changes that have happened between the different API versions.

Josh:
Yeah, I don't want to like jump ahead of you too far. But I was going to say, I noticed when I was reviewing the pull request that you sent, it looks like we're supporting both versions of the API for now or something like that. Is that true or did I misread that?

Ben:
That is true. So yeah.

Josh:
Yeah.

Ben:
So I just decided to go ahead and bite the bullet and do the upgrade of the API. Because I'm like, you know what, this is an area of technical debt that we should probably just pay down on some. And so as I was looking at the different payload formats, they're not dramatically different. Which is nice but there are some key differences. And there're two aspects, right? There's the outbound API request that you make, like when we want to update a card. We have to make a request to update the customer record.

Josh:
Mm-hmm (affirmative).

Ben:
But then there's also the handling of webhooks, right? And those webhook payloads also changed a little bit. And I knew that we could deploy the new version of our app with using the new API version but the webhooks would still be coming in as the old version. Until I went into the Stripe dashboard and changed that. Again, they're very good about, you can manage which API version you want. So I decided that we'll support both versions so that I could deploy the app, not have to worry about the timing of changing that setting in Stripe. Then go to stripe and change that setting and not have the app have to have an immediate deployment. So, kind of a straddling the river kind of thing.

Josh:
Basically, we've shaved all the yaks and we're ready to-

Ben:
I made a major payment on that technical debt.

Starr:
Yeah, we've completely like swapped out our old like Vim plugins for like new Vim plugins?

Josh:
Yeah.

Ben:
And it's, I think one of the reasons why it took so long is I did spend extra time on those tests because you don't want the billing system to break, right? You don't want to not be able to take people's credit cards.

Josh:
Oh, yeah.

Ben:
And to fail on those webhooks. So we have a lot of logic that happens when people's payments... You know things change and we don't want any of that to break.

Josh:
Yeah and I'm glad that you did.

Ben:
So one benefit of doing this work, aside from having that technical debt paid down and feeling all nice and shiny on the new API version, is that we also upgraded two major versions of the Stripe JS. So you know, we use their JavaScript on the client side to actually collect the payment information so that we don't ever touch it. Like it goes... You know, the credit card data goes straight to the Stripes servers and-

Josh:
Mm-hmm (affirmative).

Ben:
We just get a token. So we use their JavaScript for that. Well, we were using version one of their JavaScript and the current version is version three. So I completely skipped version two, like who needs that, right?

Josh:
Mm-hmm (affirmative).

Ben:
But the benefit is that now we can support the 3-D Secure thing for credit cards. So I don't know if you've ever seen this but when you go and you try to do a check out, like I don't know Newegg or something and your visa provider is like, you need to do this extra step of actually verifying that you want to use your credit card. Have you seen that kind of pop up thing?

Josh:
Right. Yeah, it's like an internment like-

Ben:
Yeah.

Josh:
In between the request. Like it go... Does it actually go to one of the other network, like websites or something or is it?-

Ben:
Yeah.

Ben:
Well, in this case, Stripe handled that in their new version of JavaScript.

Josh:
They do okay.

Ben:
So just by upgrading that-

Josh:
Okay.

Ben:
We're able to support that now. So someone who's using a card like that can now use Honeybadger more easily. And there was this whole thing in Europe about the secure card authorization, I think what's called. That happened late last year I think. They have a similar kind of thing except it's more prevalent. Like in the US we don't see that very often but it's more prevalent in EU. And now we support that better. So that's good.

Josh:
Yeah. Cool.

Ben:
Yeah I mean-

Josh:
So we're stronger, better.

Ben:
Exactly.

Ben:
Speaking of security, I don't know if either of you follow Brian Krebs. He's a security specialist.

Josh:
Yeah.

Ben:
He writes about security stuff and-

Josh:
I follow him a little bit.

Ben:
He wrote this post recently that talked about this new twist on bank scams. So you know you have someone calls you and they're spoofing your bank's phone number and they're like oh, there's some fraud on your account and then they end up convincing you to give up your password or your pin or whatever. Well, there's a new twist on that scam and that is the scammers, while they're calling you acting like your bank, they're also calling your bank spoofing your phone number. So that the bank thinks you are calling them and so they might, get your recent three transactions, for example, using the automated system because the automated system is like, it's the right phone number. I'll just let him get that info, right?

Josh:
Yeah.

Ben:
No big deal but then the scammer is like telling you, so the last three transactions on your card were bla bla, bla, bla, bla. And you're like, it's actually right. I guess this is legit, right? And then that-

Starr:
It's like an actual literal man in the middle attack.

Ben:
Exactly. A literal man in the middle attack. So then you give them your pin and then they're like, okay, please hold and they are on the other line with the bank. They're like, okay, here's the pin. And then they get access to your account and then of course, they can just do whatever right?

Josh:
Wow.

Ben:
Amazing.

Josh:
Yeah, see they always think of like something new. That's the thing. Brian Krebs, did you ever read, I think it was Spam Nation? Was that the name of his book?

Starr:
I did read that, yeah.

Josh:
That was a good book about the, like the dark world of spam email and like all the things that people go to, to like own their little spam kingdom.

Starr:
Yeah, that one was about, like it followed this, I think it was in Russia like an internet pharmacy person who did like Viagra spam.

Josh:
Yeah.

Starr:
I don't know if people still do Viagra spam. I haven't seen that in a long time.

Josh:
Yeah, I don't know. There was like... I think like Spam has come in waves. Like it's... As I recall, like they'll kind of figure out a new method and it'll ramp up and then you know, the people that are fighting it will come up with new defenses. And then they'll have to go back to the drawing board and figure it out again and then you'll get another wave of, them deploying their botnets and all that. Because that's the other thing, you have to like build up your spam army. Like you got to have your botnets. So that's why they're actually like hacking all these, PCs and stuff, just so they can send emails.

Starr:
Yeah, I mean-

Josh:
It's a good book though.

Starr:
Just use Amazon. Why not move that to the cloud?

Josh:
Right.

Starr:
Oh my God, it seems like a lot of work to like rip people off. I'm sure there's money in it but I mean, then you're like, a bad guy.

Josh:
Mm-hmm (affirmative).

Starr:
And that... I mean, I would just... That just seems like it'll drain you, at the end of the day. I don't know.

Josh:
Yes. There's got to be some people who really are fulfilled by it.

Starr:
They're like, I was born to be bad, like that George Thorogood song The Boomers love. Or is that... No, it's Bad To The Bone, I'm sorry.

Josh:
Bad To The Bone.

Josh:
Yeah.

Starr:
Yeah. Man so this week I guess... Or past few weeks. What have I been up to? So yeah, I have this like grand scheme to have an editor, a freelance editor. Who had actually written for us in the past, on blog post. Do some editing to kind of lighten my load because I'm trying to, juggle, you know childcare and work and all that.

Josh:
Mm-hmm (affirmative).

Starr:
And that kind of just fell on its face. So I've been doing a lot of editing this week. And I was like, well, if I'm going to do this, I might as well invest a little bit of time and some tooling. So I actually have... I spent some time on setting up VS Code to be a sort of Markdown editor. I mean, it works with Markdown out of the box but you can sort of make it pretty, super nice for Markdown. And there's actually unofficial sort of Grammarly plugin. Grammarly is this web service that will... I mean, it's got spell check, it's got grammar check but also let's you know about like, hey you're using this word that people use too much and it sounds stupid. So maybe use this other word instead. Suggestions like that and so I can get like Grammarly suggestions in VS Code itself and it uses-

Josh:
That's really cool.

Starr:
It is. Yeah. And it uses the same sort of UI system that like, syntax checkers use.

Josh:
Yeah. You posted a screenshot, it looked like almost like it was a linter or something. So like, shows problems in VS Code or whatever and then, or like hints or whatever they call it.

Starr:
Yeah.

Josh:
It's really cool.

Starr:
Yeah, underlines the problem word or phrase or whatever and then you can mouse over it for more information. It's also got a... I don't know like, I forget what this is called. Like there's a pane down to the bottom where you usually get like a list of all your compile errors or whatever and the... It puts all the errors in there. So you're going to sort of go through them and it's pretty nice. I mean it's kind of an unofficial plugin and everything. So it's got like a few little hiccups here and there but overall I'm actually a lot more happy using VS Code for this sort of work than I was with them just because... What?

Josh:
Do you like it better than the Grammarly app too, for that sort of thing? Because they have like the Mac app or whatever but it's like more... You copy your text into it and then it makes the suggestions or whatever.

Starr:
Yes, so-

Josh:
Do you use that?

Starr:
I've tried it, yeah. So here's the thing that I would really appreciate Grammarly actually doing is supporting Markdown files because-

Josh:
Yeah.

Starr:
Yeah, you can't really open a Markdown file, like something with an extension MD in it. And then once you get in there, it doesn't really know what to do with the Markdown.

Josh:
Yeah.

Starr:
So, it's kind of just a huge pain in the neck because like okay, so I copy and paste the Markdown text into Grammarly and then well, once I've checked it now it's time to get it back, like it's screwed up all my Markdown.

Josh:
Mm-hmm (affirmative).

Starr:
And now I have to like reformat it. And it's just... So this... Yeah, that's why I was really excited to see this, this plugin for VS Code and-

Josh:
Yeah.

Starr:
I even got like a special like, you know writing font that had like... There's some like very good rationale for like the specific font. I completely went over my head because I don't understand typography. But anyway, it's pretty.

Josh:
Nice.

Starr:
So yeah, in addition to that just been, working on... I think we talked about this in a previous show how we're sort of like juggling responsibilities a little bit. And so I'm sort of more in charge of managing day to day marketing stuff. And so we'll be working on that. And we have instituted a monthly marketing check in meeting with like our marketing person, Ben Findley and Josh and myself. And so we did one of those. And one things I really liked about that is that, we did that thing where we open like a document in Notion and then collaboratively edit it.

Starr:
And I'm finding that super useful because normally at this point, I would be struggling to remember like, what did we talk about in this meeting? Like what am I supposed to ask Ben Findley about? What am I supposed to follow up on? And, you know hopefully I remember to write that down to my own to do list but since we've got this document here, I can just go check and be like, oh yeah, like we're supposed to be doing this stuff. So let's actually do that instead of forgetting about it.

Josh:
Yeah, note taking in templates are good. We could make, even like a template for each of those meetings so that we have like a starting point every week, which... Or every month or whatever. So we can just kind of fill it in and...

Starr:
Yeah, definitely. And, another way this is useful, it's like one of my tasks was to like, prepare some notes for Ben Findley because he's going to contact a vendor about a potential piece of software for us to use. And so I was able to just sort of put those notes straight in that document. So now it's like, you know I don't have to like, keep track of a separate file, you know before I put that thing like where is it saved? It's just-

Josh:
Mm-hmm (affirmative).

Starr:
It's just all right in there.

Josh:
Nice.

Starr:
So, I don't know, that's basically what I've been doing and you know, lots more childcare than usual. Which is both exhausting and wonderful and exhausting.

Josh:
Yeah, I concur. Well, I have been... Aside from like the tech support for my computers, I've managed to get a little bit done this week. And also, what I was planning on doing. And I'm just getting around to it like yesterday. And today is starting to dig into some more of like, third party library. Like open source stuff that I want to learn. And the reason for that is because since I'm shifting I've been... I was doing a little bit more of the marketing side before all this but now that we're not bringing on another hire at the moment to take over some of the like the client library development and maintenance and also some of the work that I was planning to actually like move those, those packages and libraries forward. I'm shifting back to focus on that a little bit.

Josh:
And that's actually been kind of fun because I'm trying to like, dig into some of the things that I was kind of like, holding off on. So like I took... We recently got a team membership for Egghead.io, which is like a screencast or education thing. And I took a Python course the other day to kind of brush up on my Python knowledge because we've been doing a lot of work on our Python package for our Django integration and that sort of stuff. So that was fun and like, right now I'm, like diving into some, isomorphic JavaScript and server side rendering and all that fun stuff, Vue and React. So that's where I anticipate spending some time over the next couple of weeks, try to get a better handle on that world. And my end goal is to better support those platforms with our JavaScript packages. So it's been kind of fun and I'm looking forward to it.

Ben:
So, you've done some Udemy courses I remember like we did a hackathon for Elixir. We picked up some Elixir and Phoenix ones. And now you've done some Egghead ones. So I'm interested to know what you think about the differences of those two? Like, how's that been? Are they both great or you like one over the other?

Josh:
So I really like Egghead now. And I've been meaning to like try Egghead for a long time. I'm actually friends with one of the founders. And they have been longtime Honeybadger customers as well. So like we love Egghead. And so, they have like a really strong focus on like the front end like JavaScript side of things. So this was like the perfect opportunity, I think, for me to dive in and do that. The thing that I really like about Egghead over, like my experience with Udemy, and I guess they both have kind of their strengths, but Egghead is much more tailored towards like small bits of learning. So the courses are typically... They seem to be much shorter. The lessons themselves, like the courses are like broken down into really concise little chunks. So like, they could be like three to 10 minutes or something or two to 10 minutes or something like that.

Josh:
And you have like a... I think the Python course I took had like 28 lessons that were within that time range. So it was like an hour, a couple hours I think, the total course was. But some of the courses are, you know under an hour even. So they really focus on like, optimizing your time. Like not taking too much of your time whereas with Udemy, I forget how long that course took but that was like that was like a month long. It was a long course.

Ben:
Yeah it was long. Was like eight hours or something.

Josh:
It was like a huge investment.

Ben:
Yeah.

Josh:
Like, I had to plan like days of my time for that month to actually get through that course. And that's a reason like I've... That was the first course like that, that I've actually ever gotten, like actually gotten to the end of I think. That was an Elixir, an Elixir Phoenix like Masterclass type thing.

Ben:
Yeah.

Josh:
So, like I enjoyed the deep dive into Elixir but I think it was more because I really enjoyed Elixir and less because I enjoyed like a, whatever, 40 hour course that I had to like, you know hit milestones on and everything. So, I'm liking the Egghead format and I think they're onto something.

Ben:
They just need some more server side stuff.

Josh:
Yeah, some of that. Well, you know I don't know we could always like, start making our own courses-

Ben:
We should make some.

Josh:
That's our jam.

Starr:
Badgerhead?

Ben:
Badgerhead.

Josh:
Badgerhead. The other thing I've been doing is I've been trying to, like play with things more. Like random, if I see a new project come up like actually take it and like try it out. So I recently took Heya, which is my email campaign gem for Ruby and went through the process of installing into a fresh Jumpstart app. Which is Chris Oliver's Rails template, you know like starter kit. And so that was fun. I got to like check out Jumpstart and at the same time like, I took down some notes for like how to install Heya into a new app. And also that was a really good opportunity to experience like the first run process of installing my thing into a new project because I don't get that opportunity very much. So I was able to make a lot of some nice improvements to that. Make it smoother and reduce friction. So that was fun.

Josh:
I recently tried Lamby. Which is... The Lamby gem, it's a gem that lets you deploy a Rails app to AWS Lambda. Which is kind of wild. I'm not sure like how I feel about that approach yet. But actually I ended up getting to talk to the creator of the gem and he made a lot of good points. Like they're... It's Custom Ink, I think, is the... They built this Custom Ink tech. And they've been using it, they're in production and it seems to work well for them. So it's interesting, like some of the things you can do if you really try make it work. But, I just like deployed. I went through their getting started guide and deployed a little "Hello World!" Rails app to Lambda. And that was a fun experience. That took a little bit longer than the Jumpstart thing.

Starr:
How long does the cold start on that take? Like, how long does it take to start up on the first-

Josh:
It's a while. Like, I mean, it's about as long as it takes a Rails app to boot. So it's not great but that that said once it's hot like it seems it's responsive and snappy and everything. I haven't... It might be an interesting test to do like some load testing on it. I should run A/B on it or something. But yeah, I mean like, once it started, it seems to be pretty good. And the other... I had that same question. The other question I had was about the... Well actually, my brother asked this, Ben would... Apparently Lambda has a max payload size of, like the unzipped package is 250 megabytes. And so my other question was like, well, Rails apps could be fairly large, like is that going to be a problem? But apparently the answer to that is like Rails apps are actually not quite as big like Node. Node apps can actually get up there, from what I've heard but for a lot of Rails apps they can fit under that limit, is what I gather.

Ben:
So recently, Amazon, they added a feature for Lambda, where you can actually keep a Lambda function hot.

Starr:
Oh nice.

Ben:
Yeah. I mean, obviously, it costs money-

Josh:
Yeah, I saw that.

Ben:
Because, you know you're running something pretty much full time instead of just on demand. But yeah, if load time, if cold start time is really a problem you can just run one concurrency all the time and always have something ready to respond.

Josh:
Yeah. It's interesting. And actually, like the design of this gem is really cool because it'll actually work with any Rack app. Because really all it does is, it creates a Ruby Lambda handler function that takes the input from wherever. So like API gateway, it's takes the function input and then basically creates a Rack request object from that. And then it passes that into the Rack endpoint for your Rails app. And then from there, it's just Rails. You know the Rack pipeline all the way down, it does its thing, responds. It's just a response and so that hands it back to the Lambda function, which hands it back to whatever, the gateway.

Starr:
You know what's funny? Is that, they say the technology goes in cycles. And I've heard Lambda compared to like, CGI-bin, right? And so this project is kind of like the old, I forget what it's called, like CGI gateway or something or Ruby CGI. Whatever you have to use to get Rails working under CGI.

Josh:
Yeah.

Starr:
To get rails working on the CGI and everybody knows that was a disaster, right? And so next, there's going to be Mongrel. Like next up is Mongrel. So that's going to... It's going to happen in the cloud somehow.

Josh:
Yeah but it's at scale. That's the difference-

Starr:
But it's at scale, yeah.

Josh:
Web scale.

Starr:
I have no idea what that looks like, I'm just...

Ben:
From a compliance standpoint, I love the idea of not having any servers. Like that just-

Josh:
Yeah,

Ben:
Knocks out so many problems. If you say, "Oh, it's just a Lambda thing. And my whole Rails app is there. I don't have to worry about any servers running. There's no patching. There's no network intrusion. There's no..."

Josh:
Yeah. It is. It's really interesting.

Ben:
It's a big selling point.

Josh:
Yes. Yeah so my next step on that, before I move on, I think is going... Of course, I'm going... I got to install the Honeybadger gem and create a failing error endpoint. So I can see how that works in Lambda, in a Rails app. Which will be a first I think, probably so that'll be fun. I might do that later, some point.

Ben:
You know, we can move our Heya sales site over there? Get it off Heroku.

Josh:
I thought of that. Yeah, that was my... I was... I thought about using that as my... Instead of just doing like the Hello World thing I thought, well, that's a small Rails app, I could do that. But I wasn't that committed to the project. I was like, that's going to be... Like, then I have to learn how to like run a Rake task and like, all this other stuff. I'm like, no, I'm just going to, like do the quick start guide like what they recommend. And even that ended up being a little bit of a can of worms because it wasn't quite up to date. So I got to figure out some things for myself.

Starr:
Once you get an error reporting from Rails app in running a Lambda, like you should do a little screen cap of that. And share it with the world.

Josh:
Yeah, I guess I could do that. I did. The thing I've been doing with these little projects is I've been writing. Like keeping notes of like everything I did to get to whatever the end result is and then just sharing the notes out there, which is kind of cool. It's actually been one... Like that's how I was introduced to some of the people that actually work on these projects and can ask them questions and stuff. So you can post like... I just like created Gist and then post that on Twitter or Reddit or whatever, Dev. So it's a good way to like get some extra mileage out of playing with new things.

Starr:
Totally. That makes sense.

Josh:
I think the next, one of the next things I'm excited about playing with is StimulusReflex. Did you guys see that video yet?

Ben:
Yeah, that was awesome.

Josh:
Yeah.

Starr:
Could you describe it?

Josh:
So it's... If you... Are you familiar with Phoenix LiveView? It's the thing, it's basically like a way to build reactive web applications but just with like a Rails Web stack instead of like all the JavaScript stuff. Like basically you can build applications without JavaScript.

Starr:
Okay.

Josh:
Yeah, so like, the way it works and I don't want to butcher this because I am not an expert at it but it uses WebSockets basically to pass information back and forth. So it allows you to basically respond to client side events. Say like, the app that he built was a Twitter clone. It was Twitter clone in 10 minutes in Rails. So say like clicking a Like button in... Normally, you'd have like some JavaScript that handles that and maybe like increments the likes counter and then forwards that to the back end or something. Well with this, it basically like literally lets you click the Like button on the front end and respond to it on the back end.

Josh:
So you have something called, I think they call it a Reflex. And the Reflex is basically like the controller that handles that client side event. So the Reflex does whatever the back end handles, the increments and stuff like increments in the database and then responds and it broadcasts the response back over the WebSocket. And then the client side has like automatic handler code that picks that up and does whatever, the action is, like incrementing it on the client side.

Starr:
Cool. So one of the things that I think, obviously I may get this totally wrong but I think that Phoenix LiveView did that was interesting. Like it used like a virtual DOM to like find the difference in the HTML that was sent down the wire versus the, you know whatever was being displayed in the DOM so that it only updated that I think. Does that sound right?

Ben:
Yes. Yeah, the LiveView has a very small data comes back out just a-

Starr:
Does this do like a similar thing? Do you know?

Josh:
I'm not sure. Do you know Ben?

Ben:
Yeah, I think it does. I don't think it's quite as little bit of data as Phoenix LiveView. I think there's more but yeah, it does do a certain kind of DOM to thing. It uses I believe DOM morph or... Morphdom, that's what it is.

Josh:
Yeah, morphdom.

Ben:
And changes... So you're definitely not sending back a whole page. You're sending back some HTML and so not as little bit as LiveView. Which is still a very small JSON payload.

Josh:
Sorry, I forgot, I had the same question. And actually, I forgot to give a shout out to Andrew Mason who's also on the Remote Ruby podcast now. But after the show yesterday, we were talking about... Because he works... I can't remember the author's name of StimulusReflex but he works with him at CodeFund. And yeah, so we were talking about it and he said, like... What I kind of got from him is that it should be possible to get it down to like the small amount of data over the wire as like... I think it's the same idea in theory. So I don't know if it's quite there yet but it sounds like it might get there eventually. Like, I think it's the same concept. But you're right, it does the... It uses morphdom or whatever, which is a no JavaScript library to... Or JavaScript library to do the diffing and then basically just replace just what has changed in your elements.

Starr:
I mean of course the big question is, does it work on Lambda? Because like we are using Lambda for everything.

Josh:
That's the biggest... That's the big thing-

Ben:
Stay tuned.

Starr:
Stay tuned.

Josh:
Yeah. I think part of the part of the answer to the question of like sending data over the wire is also like how you can choose how much you want to send. So you don't have to replace an entire element if you're just updating like a counter or something. Like you can actually... There's an option to like send just a counter. Like you can just send the data and then the data gets handled on the front end.

Starr:
Oh, cool.

Ben:
Well you've learned a lot from not having a computer.

Josh:
I know right? But the iPad has come in handy so that's the other pitch, other part of the story.

Ben:
So the moral story is have at least five computing devices in your home that you can use. In case two of them fail.

Josh:
Exactly. Yeah, like I never thought, that all this redundancy would come in so handy but it really has. And, we'll see fingers crossed, that I don't lose more devices over the next few days because if I go at this rate, I'm going to be...

Ben:
You'll be beating rocks together-

Josh:
Going to be like... Yeah, exactly.

Starr:
Well, should we wrap it up?

Ben:
We should.

Starr:
All right, well this has been FounderQuest. If you like the show, please go to Apple Podcasts and review us. If you would like to write for the Honeybadger blog and we hire people to write, you know Rails and Elixir and you know maybe other languages tutorials, so just go to the blog honeybadger.io. Wait, that's the old way of doing... That's our old way of getting to the blog but it still works just don't link directly to that, please. Go there and there'll be a link in the top nav saying how to write for us. So I will talk to you all later. Have a great week.

Episode source