Hey everybody, how's it going? So those of you that have seen me speak before, know that I usually like to start my talks with something a little weird. This is not gonna be an exception. You will not be spared. So I wanna first make sure that we are all sort of in sync. So I'm gonna count to three, and when I say three at that instant, can everyone just clap? One, two, three. Turns out sync needs a little work. Let's try again, ready? One, two, three, that's so much better. Let's snap this time. One, two, three. Awesome, okay. So don't do it yet, but this time, when I get to three, everyone that is able to, please crack your knuckles. It's gonna be weird. Anyone wanna leave the room before this happens? Okay, ready? One, two, yeah. Yeah, yeah, that was weird. I like to start my talks with a little bit of disgust. That way everything seems like an uphill climb afterwards. I'm here today to talk to you about the future. No Vim today. No live coding, which is good because I have both hands taken.  All right, so I wanna talk about the future, and I wanna talk about the future of writing correct code. I think this is probably pretty important. I think it's gonna matter. I flew over here on an airplane that has apparently about five million lines of code in it. Yeah, and probably some of those awesome errors that Brittany was pointing out, if I had to guess. Not all of that is safety critical, I assume, but it's likely that we will soon be riding around in cars that have millions of lines of code in them, that drones will fly over our head with possibly millions of lines of code, trains, planes. It's all gonna happen, I think. And so writing correct code is important. Maybe that's not super relevant to us. I've never written safety critical code, like code that kills people, if it's wrong. But you can write, it's really important that code be correct even if you're writing web applications, right? To pick a totally hypothetical example, imagine you wrote some sort of web app that acts as an elite about 143 million social security numbers out as a quasi-governmental agency. Let's just say, that would be bad. So we wanna avoid that. So I've been thinking a lot about what is the future of writing correct code? How are we going to do it? How do we do it today? How can we do it better? And that's what this talk is about. And I asked myself early on, what is a good model? Like what are other places we can look for possible inspiration and possible clues about what this is gonna mean for us? And the answer to me, surprisingly, came in the form of chess. Does anybody know who this guy is? Yeah, Gary Kasparov, former world champion in chess. For a while, this was the best chess entity in the world. There was no option if you wanted better chess. He was the most correct chess player there ever was. And then in 1997, do you know what happened? He got beat by a computer, Deep Blue beat him, financed by IBM, and he lost. He lost a six game set, a six game match. And this computer was so far advanced from what had been seen before that Gary actually accused the Deep Blue team of cheating because there was a move in the second game that was so good he was convinced that only a human could have thought of it. Turns out, computers get better. So Gary lost, and then at that point, the best chess playing entity in the world, the most correct one was this computer. But then something was discovered. If you took a really strong chess engine and had it spit out potential moves to a grandmaster, that combination was stronger than just the chess engine alone. And that's actually still true today. So still, if you pair a grandmaster with the strongest chess engine, that pair will beat the chess engine. So today, if you want the most correct chess, the answer is a human plus a program to help that human. And I think that's where we're going. I don't think we're gonna have much success at making dramatically smarter humans. And even if we did, we'd have to make all of us smarter. But if you can make a really good, really smart program, you can help everyone, even if we don't make anybody else smarter. And so I think that's the future. We're gonna have, maybe call it an AI, if you wanna be fancy and impress people, but programs. Programs to help us write programs. Programs to check our work. I have some bad news. I don't think Ruby is gonna be the answer to this. I know we're at Rocky Mountain Ruby. I don't think this is gonna be, these programs are gonna be written in Ruby. That's actually good news though, because Ruby has been around a long time. And we would hope that we can do better, right? Like we would hope it wouldn't be stuck with the same language forever that things wouldn't progress. So that's actually good news. And I have more good news, which is the future is now. I've actually spent the last six months writing code with the help of programs to help me write code. And it has completely changed things for me. I am writing dramatically more correct code. I am refactoring with much more confidence and I am enjoying the heck out of it. And I wanna tell you about the first program. The first program is Elm. Somebody asked about that over there. This is a perfect dovetail. Where'd Brittany go? This is a great, she's gone, amazing. This is a nice dovetail with Brittany's talk, because Elm solves a lot of these error message issues for us. All right, so the thing I like in Elm, so here's what Elm is. How many people have heard of Elm by the way? Okay, how many people have running Elm in production? Aha, yes, so Elm is an interesting point. Elm is a programming language that compiles into JavaScript. So if you want to write some sort of UI for a browser, if the browser is the target, you might use React, you might instead use Elm. Elm has a really powerful type system. It's sort of descended from Haskell. If you've written some Haskell or heard of Haskell and seen people say, oh my God, the type system in Haskell is amazing, and it is. It's sort of like the creator of Elm chopped off the most complex parts of Haskell and simplified some things and made it a little more beautiful and we have this wonderful language that compiles into JavaScript so we don't have to write JavaScript. And that the generated JavaScript can be quite correct. So I've been writing a lot of Elm and liking it quite a bit. So, notice how we had a lot of people that have heard of Elm but only like two, it looked like a running Elm in production. I think Elm is about to cross the chasm where it moves from a thing that only a couple early adopters are using to a thing where it crosses over into mainstream acceptance and enough people are using it, enough companies are using it, that people can trust it and feel like it's gonna be good. And that's kind of part of my mission. I'm trying to help it cross the chasm right now. I'm hoping to inspire some of you to try this out. Correctness. I think this is a pretty good correctness measure. How many runtime exceptions do you get?  There's a thing that you didn't anticipate something went wrong. If you're running a pretty popular app that gets a decent amount of traffic, you're probably getting lots of these, right? Like, how many people have seen like 10 exceptions a day? No? Okay, just me. All right. I feel like if you look in your honey badger logs, you will be contradicted. Runtime exceptions. Not so good. Here's an example. So there's a company that is running 100,000 lines of Elm. They're an early adopter. They embraced Elm very hard. 100,000 lines of Elm, which turns into JavaScript. They've been running for about three years in production. How many runtime exceptions have they had in those three years? Zero. None. I challenge you to write 100 lines of JavaScript and run it for three years and get zero runtime exceptions. I don't think you can do it. The reason you get so few runtime exceptions in Elm is because it has a type system. I know you've probably heard of type systems before. You've maybe experienced some type systems. Maybe you wrote some Java and said, yeah, type systems are no good. Java's so verbose. I hated it. Not all type systems are created equal. Elm's type system is amazing. Let's look at some examples of some Elm code and I'll talk about the type system in these examples. So this top line is a type signature. It says the function length takes a string and returns an int and there are examples below. Length takes hey, returns three, or length takes an empty string and returns zero. This one line of code, which is simple to type and easy to think about, gives you quite a lot of security and guarantees. So Elm, the Elm type system, when you write that, will look through all calling sites of length and make sure you only ever pass it a string. You cannot compile an Elm program that will pass something that's not a string to your length function. That's a guarantee. If it compiles, you never have done that. Also, Elm will look through the body, the body of the length function is not here, but Elm will look through the body of your length function no matter how complex and make sure that it always returns an int. It will walk through all of the branches of your ifs, through your case statements. You can't fool it, it knows. You always return an int guaranteed. That one line gives you so much security. Another example, here's concat. This takes a list of strings and returns a string. Here's our example down below. There's our list and our output. Same thing. You can never call this function if you're not passing in a list of strings and it will always return a string. Strong guarantees. Last example, here's repeat. This has a little bit of a new idea that you haven't seen yet. The repeat function takes an int and some type A, some sort of type A here and returns a list of As. So here are our examples. We repeat takes like a three, let's say, and then all right, which is a string and returns a list of, all right, all right, all right. Nice. I wasn't sure if that was gonna work. Yes. All right. So this A right here just stands for any type. Send me an int and something and I'll make sure to send you a list of those somethings back. And again, that one line, Elm guarantees this is true. It's like a contract. It will not compile if this is not true all through your program. By the way, type signatures also make great documentation. So here we say the isAdmin function takes a user and returns a Boolean. That's pretty clear. That's like executable documentation. I bet you could write that function just given that type signature. Is logged in, takes a user and a session and returns a Boolean. I bet you could write that too. Here's a little example. You're familiar with map from Ruby, right? We have map on enumerable. Map, this is some new syntax you haven't seen yet but this says the type of map, map takes a function from A to B, that's what's in the prens there, and a list of As and returns a list of Bs. It makes sense if you sort of think about this in Ruby. Imagine you have a function from string to int and a list of strings, you get back a list of ints. And so every time you call map, Elm is checking to make sure that this is working correctly. This type system makes a big deal. It lets you have some pretty incredible error messages which I wish Brittany could see, but here we go. The branches of this if produce different types of value. The then branch has type string but the else branch is number, hint. These need to match so that no matter which branch we take we always get back the same type of value. Right? That's a pretty darn good error message. There's actually a repo of all the possible error messages that an Elm program can make and people file issues against this repo saying this error could be better and they will add things to like hints down at the bottom or links to further documentation. Here's another example and this is the kind of thing that trips up newbies so they add an explicit error for this. This condition does not evaluate to a Boolean value true or false.  I assume I can just use the integer as in the if. Elm says, you haven't given me a condition with this type, int, but I need it to be bool, hint. Elm does not have truthiness such that ints and strings and lists are automatically converted to Booleans do that conversion explicitly. This kind of friendliness is all throughout the language. It's like having a friend debug your code for you. This is kind of the thing you can get with a type system and a smart compiler. This is a program helping me write programs. This stuff is a big deal. I wanna turn now to one of my favorite topics which is nil, my favorite, I mean Lee's favorite. I tweeted this a while ago. The sad truth here, this is funny because it's true, unfortunately. I wish it weren't. Challenge, try this with your coworkers for a few weeks and see how long it takes them to catch on that this is all you're doing during code review. Can this be nil? What happens when this is nil? Ruby loves to return nil. When Ruby doesn't know what's going on, nil is Ruby's, I don't know. It's like find some things, I didn't. Okay, what do we get, I don't know. Cool. Something went wrong, what should we do? Return nil, it would be great. Okay, cool.  Whose most common error is no method error on nil? Yeah, everybody. Everybody, those are, and again, go check it if you don't believe me. That no method error on nil, classic error. It's like the Ruby error. If there were a quintessential error, it would be that one and it would be that you've gotten back a nil somewhere and you accidentally called something on it. Like what's the bug there?  You tried to call a thing on that nil, right? Ruby's answer to this problem of hey, nil shows up all the time is never forget to check for nil, right? Just be perfect. You should always assume that something might be nil and you should have tons and tons of guard clauses all over the place, right? Nobody writes code like this, right? We write it very directly. We write a very simple unit test that has like a perfect non-real world scenario and the test passes, we're like, great, everything's good, move on. And then later, somehow, that whatever thing is not there, you get a nil and it blows up and you get an exception at runtime, which is when your users see it. Let's talk about how Elm handles this. Okay, so here's a concrete example. Here's some new things you haven't seen. This is how you make a type in Elm. So there's a type called person and a person is like an object and has two pieces of data on it, has a name which is a string and a person has an age which is an int. And then we have this can vote function which takes a person, returns a boolean. So we say if the person's age is over 17, true, otherwise false. Okay, so imagine this scenario. We've written this code and we go, oh, actually, you know what? Person might not always have an age. We might not always have an age. We don't always know the age of somebody. What do we do then? Well, Elm has an awesome answer. So Ruby's answer would be, check for nil everywhere. Every single time you use age, don't forget to check for nil. And you would go, right, definitely not doing that. Gonna go do something else instead and we're gonna blow up in production all the time. Here's what Elm does. Elm has this interesting type called maybe, which just kind of has this like interesting like, maybe an int? I kind of like that a lot, actually. So what we've done here, we've actually, so think of maybe as a wrapper. We've sort of wrapped up the int that may or may not be there. It's like it's in a box now. And everywhere that we want to look at the age, the person's age, we have to explicitly unwrap and say, I know this is not an int. It's actually a maybe int. It's in that maybe box. And so because the maybe box maybe has an int and it maybe has nothing, I will handle both sides. I'll handle both things. And Elm will not compile if you don't handle both things. You cannot forget to handle both things. It just will not compile, your code will not run.  That sounds a little annoying, but it's actually rigorous. It's actually saying, we want our code to be correct. And if you're telling me that sometimes age is not there, you gotta tell me what I should do when it's not there. Here is how, don't worry about too much of the syntax here. There's some concepts we haven't covered, but here's our new can vote function when we switch int to a maybe int. I'll basically just translate, which says, let's look at the person's age, case, person age. When we look at their age, if they actually have an age and that age is over 17, then true. If it's under 17, then false. But if they don't have an age at all, then return false. So maybe it can be a just or a nothing. And it's not so important that you understand there, but the clear thing, this nothing down here, this is actually a big deal. This is saying like, this is what I want you to do when the age is actually not there. And this kind of thing rarely shows up in Ruby. Like, if age.present, maybe you might get that. But basically, Elm won't compile if you eliminate this lines of code, which say, here's what you do when age is not there. This reduces so many, so many bugs. It's a little hard to, it might be hard to imagine how this works in practice. I can tell you, once you get used to working with maybes, looking at Ruby will give you panic attacks. You're like, isn't that a maybe name? Isn't that a maybe int? Isn't this a maybe int over here? It's such a difference. It's such a high level of rigor and it prevents so many, like you'll never, ever get like a no method error on nil in Elm. It just won't even compile to that point. So, I'll make a bold claim now. And I'm actually repeating a bold claim, but I'm adding my emphasis to it. A former coworker of mine, Athopot, has written a lot of Elm. And he's written a lot of Ruby, a lot of Ruby. And he said, I would rather, I'd have more confidence in a code base that was an Elm code base with no tests than a Ruby code base with tons of tests. And that's pretty huge because like my code to test ratio is like two to one ish. Maybe 1.8 to one. I'm running a lot of test code. I would love to not write test code. And it turns out if your type system is strong enough, you need to write way fewer tests. So you can go a lot faster and make fewer errors and do less work because we have programs to help us write programs. And we should be using them. I want to talk to you about a real world example. This is some Elm code I wrote. I decided I wanted to make a sort of image evolver. And so I have a goal image and I want to randomly mutate my way from a set of random polygons into that image.  And if that image looks more like my face than it did before, I'll keep that version and mutate from there. And if not, I will throw away that mutation and try again. It's kind of like a hill climbing, like a naive hill climbing algorithm. I'm just sort of making these random changes and every so often that change is closer to where I want to go. Okay, that becomes my new baseline. Here's an example. So on the left is the goal image, is that those set of squares. And on the right we have 125 random polygons, random colors, random positions and random transparency, opacity. And you're watching them mutate. The bottom left number is how many iterations? The bottom right number is our current similarity to the goal image. And you can kind of see we're getting there. So we're just, like you see all this flickering because it's trying lots of things. It's like, is this better? Is this better? It'll pick like 20 polygons at random and change random things. Like one of their vertices, the color, the opacity, just tweaks it. And we're starting to get pretty recognizable. So this is a program I wrote because I want to just kind of flex my own skills and see what this was like. Here is another example. This one's just static. Faces are harder. The squares are, like the more detail there is, the harder it is. But you can kind of see we're getting there.  But we're getting the outlines. Like it's, you can see we're getting there. Now I wrote this program and in the original version I, instead of using polygons on the canvas, I used circles because it sounded simpler. I was like, well a circle just has a center and a radius and that seems easier than a polygon that has a list of vertices that I need to keep track of. And I was new to Elm, so I was like, I'll just use circles. So I built the first version and I got it working and I was like, okay, this is going to work a lot better with polygons. I'm going to have to do this refactor. And I made a new branch and I was like, this is probably going to suck. Here we go. By, as point of comparison, imagine you've written a Rails app and it's a to-do app. And you have to-dos and you can create a to-do and you can rename a to-do and you can edit them and you can assign them and you can complete them. And then someone comes along after a couple of days and is like, hey, guess what? That to-do app. We're actually going to make it be an issue tracker for software development teams. So to-do we should rename to issue. And to-dos no longer have a due date. And when you assign it to do, you might actually assign it to a team of people. An issue could be assigned to a team of people instead of a single person. And you have this change to a very fundamental data structure in your app. That's what I was changing. So like this circle's data structure was in basically every function of my app. It flowed through all the way the Elm app. And I was like, okay, this is going to be pretty terrible. So I made the change to the top level. I said, okay, hey Elm, circles aren't a thing anymore. Now they're polygons and they don't have a center. They have a list of vertices and a vertex looks like this and these are the coordinates and all that. And Elm immediately spits out like 15 errors. So I'm like, okay, here we go. And I get to the first error. And it's pretty simple. And Elm is like, you saw this error message. This is pretty friendly. It's like, hey, you gave me a circle and you need to give me a polygon. And I was like, okay, no problem.  Oh yeah, like now it's a vertex. And I very mechanically walked through this list of 16 or so errors that actually were like pretty straightforward. They were well explained and they were pretty easy. And then I finished and I solved the last one and it compiled. And I was like, no way. And I refreshed my browser and it worked perfectly the first time. And I was like, my life will never be the same. I got goosebumps when that happened. It was just like, oh my God, there were no tests in this. I was new to this thing. I'd always ready any tests. The type system and the compiler washed me through what would have been a really hairy refactor in any other language. It was simple. I never stressed. And as soon as it compiled, it worked perfectly. It's just like so mind-blowing. So type systems. They're all right. Let's talk about the second program that I've been using to help me write better code. Property-based testing. Is anyone familiar with this? Okay, wow, not even at the chasm yet. Awesome, this is great. I'm excited for you. Okay, so let's say we wanna write a function. And we wanna make sure the function is correct. So we're like, cool, we're gonna be good programmers. We'll write some unit tests. So let me think of an input. Let's say we have a reverse function. I should pass it a list of three items. And then when I call reverse on that, it should be reversed. And so we hand write an input, and we hand write an output, and we say those should be the same. And we do that a couple more times. We're like, that seems good. And we move on with our lines. And we often miss a lot of edge cases. And it's because it's annoying to come up with lots of inputs and think of lots of edge cases. And it's annoying to have all that test code there. And if you write 500 lines of tests for reverse functions, like this seems stupid, like why am I spending all this time here? So property-based testing takes a different approach. It says, hey, you know, thinking of test cases and checking that they're correct, that sounds like a great job for a program. That's not a great job for a human. So let's imagine we are testing this reverse function. With property-based testing, instead of coming up with test cases, you come up with properties. Properties are things that are always true for the function you're testing. Can anyone think of a property that should, for the reverse function, no matter what input we have, what should be true about the output? Can anyone think of some properties? Yeah, absolutely, yes, that's a great one. So no matter what input I throw into reverse, the output of reverse should have the same length as the input, right? That should always be true unless something is horribly wrong. Excellent, really good. Any other ideas? Any other properties? Yeah. It's still a list, yeah, totally. The type should be right. We should still have a certain number of things. Yeah. It should have the same content, absolutely. We shouldn't lose elements or gain elements. We shouldn't accidentally de-duplicate things. Awesome, so just armed with those three properties that we just rattled off without too much effort, we can then have property-based testing. Elm has a property-based testing framework. Generate us lots and lots of input and make sure that for every input, the properties hold. So it says, okay, here's an empty list. Do the properties hold? Yes. Okay, here is a list with 10,000 items. Okay, the properties hold. Here's a list with 20 Unicode items followed by some integers with a null byte tacked on at the end. Okay, the properties still holds. It thinks of these lots of nasty edge cases for your code for you and makes sure that they're right. So unlike a unit test where you run five examples, you're like, okay, those tests pass, a property-based test just hasn't failed yet. So it will basically run, let's say, a hundred different inputs through your thing. Make sure the properties hold and say, you're good so far, let's move on to the next thing.  This is a pretty big win. So here's the question, does this stuff actually work in practice? Does it actually test, catch real world bugs? And the answer is yes. So here's a real world example that a friend of mine ran into and he had written some tests, some property-based tests for a JSON encoding and decoding library. And when you have an encoding and decoding pair like that, property-based testing really shines because you can say, generate me some input, encode it, decode it, make sure I have the same input. You basically round trip all the way through your program and back and say, I should have that same thing back and you can generate me a whole list of things. I want you to make sure that everything works this way.   He tried this and his almost immediately failed and he discovered something. When he encoded something, it had a microsecond of precision and when he decoded it, it was down to a millisecond of precision. It had truncated that precision at the end there. Now does that matter? Maybe. For them, it actually matters. If you compare these two times, are they equal? That sounds like an opportunity for a pretty subtle bug where two times look like they should be equal when you encode and then decode, but they're off by microseconds. And this is the kind of thing, how could you find this in a unit test? Can you imagine catching this in a unit test? Probably not, but this is the kind of thing that property-based testing catches with ease. So I'm just about done. I want to tell you one more thing. Anybody know who this is? David Allen, yeah. So David Allen came up with a system called Getting Things Done. And one of the core tenants of Getting Things Done is that when you think of a thing you want to do, even if you maybe want to do it, you need to throw it in a system that you trust.  And I think we should take that and apply it to programming and realize that our brains are for dreaming up programs, programs that are ambitious and change the world and do wonderful things. And they are not for chasing down nil and watching for edge cases and worrying about microseconds. So that's the talk. If you liked this, this is my newsletter. You will probably like the things I send out. I'm really fired up about Elm these days, so I talk about it a fair amount. I'm also about to launch a course called Refactoring Rails, about taking care of aging Rails apps.  And if you sign up there, I'll send you information about that course as well. And thanks very much. It's been a lot of fun. I had to write some things down. I had some complaints. Yes, good, good, good. The complaint board is open. The first one is that you went through an example of discriminating biographical details of a person, age, and name. All anchored around discussion of maybe and you passed up the opportunity for phone number leading to obvious call me maybe jokes. Oh, damn. Second. Strong criticism. More grievous. I actually was about to shout it, but I was like, no, I don't wanna blow the punchline and then it never came. Damn it. It looks like you're writing a crud app. Would you like help with that with a little clippy graphic? Okay, all right, all right. Like when you're like, programs, I write programs for you. Yeah, sure, sure, sure. I thought that was coming in the intro. Okay. Other than that, I was sold. I don't know if anybody else, like so I used to do Java a long time ago. And just like type is a thing I have found myself like craving, especially in teaching. And so seeing like pre-condition, post-conditioner like input type, output type, it was honestly, I was like, I feel like you're going home. That'd be so beautiful. And the error message about the type mismatch coming out of the if was like really, really neat. And if you didn't see those things, if you saw those things and you're like, why would I care? Then just get into those honey badger logs and you'll find out why you should care. Yeah, exactly. So aside from my private commentary, we have time for like a couple questions. Yeah. Is it like comments? Ruby contracts, that's called. So I can actually recommend a gem. This is, if you like the maybe idea and you want to try it out in Ruby, it's not going to be as slick as Elm. But if you look at the wrapped gem, like as in like wrapped up in something, some former coworkers of mine said like, I miss maybe so much in Ruby. So here's the concept. And it's not quite as slick, but it'll give you the give you the sense of it. Yeah, yeah. So if you can't hear, he said, he's calling me out because in the past, I have prescribed null objects as an answer to the nil problem. And I don't think what I said was in conflict with that, which is that like nil is a problem and there are various ways to solve it. I happen to really like Elms a lot now. I would rather have a maybe than a null object most of the time. But because it's enforced by the type system, it's like, if a thing expects an int, you can never hand it a maybe int. It's just like, I'm not interested in that, man. Like you gotta give me an int. And so you just can never forget. Whereas like you can still have runtime errors with a null object, right? Like you have a null object standing in for a user, like you have a guest, let's say, and then you call like last signed in.  Yeah, so the question was, is there a testing framework for Elm? And there is, yeah. So that property-based testing is available in Elm as well. So there's an Elm test library. It has normal unit testing like you're used to seeing, but also has, they call it fuzz testing, but it's the same thing. What are the major hurdles around getting Elm in production? That's a good question. I think it's mostly cultural, honestly, at this point. It feels technologically ready. There are fairly easy ways to get it working in like the Rails asset pipeline, for example. As like at Thaubot, they are writing a fair amount of Elm. It's happening. I think it's mostly just like, do people trust it? We're at the phase where it's people need to look around and say, are other companies that are like sort of conservative like us using it too? Okay, fine, we'll use it. I think that's where we're at. That's it. That's all for you. All right, all right. You're done. All right.


Hey, what's up guys, welcome to our training reviews. So today I've got this new massage gun, it's called the RecoverFun Mini. Now I've reviewed a lot of massage guns in the past, I'll have a link of them all in the description below, but this one stood out to me because this is probably one of the world's smallest mini massage guns. Now something so tiny like this can even fit in your pocket, but not just that, it's actually the same level of intensity as all of my previous massage guns, and I'm talking the large, powerful ones. Now this also goes up to 3,200 percussions per minute, which is on the same level as all of the other industry leading brands in this similar space. So what I'm gonna do is go ahead and give you an unboxing, see what it comes with, see the specs on this, try it out on myself and give you a review of how it performs, so let's get straight into it. Okay, let's go ahead and open this. As you can see on the front, it actually tells you there's two color options that it comes with, it's black and red. So I've chosen to go with the red one, I think it's just a bit more quirky, it stands out, it's more vibrant. It's something different as well. Let's go ahead and look in the box, so you have the user manual with instructions, you've got this nice little carry case and this fabric one, so these are really convenient to take this around because it is quite small, so it's very handy to put in your backpack. Now you have four different heads that come with this, you have the flat red head, which is gonna be complimenting the actual red body, then you have the ball head, you have the fork, and then you have the bullet. Then you also have the USB charging cable, and the one thing I really like about this, it is USB-C, so it is on trend to be top of the range industry standard. A lot of my previous massage guns are either power adapted or they come with the micro USB charging. So I'm gonna put this red head in there, which is quite a funny name, I've just given that name myself, to be honest. It's very heavy duty, it's metal, it's solid, it's not the lightest, it is quite heavy, it weighs just half a kilogram, but from end to end it is 14 centimetres, so it is very compact. And it does have a brushless motor with silent force technology, so it only goes up to 48 decibels, which is actually pretty quiet. In terms of the battery life, it is 2600 milliamp battery, which gives you about maybe five hours, and it takes about an hour and a half to fully charge. So you've got the power button, you just hold it down for a couple of seconds to turn it on, and then you have the four different speed levels here to generate between 1800s to 3200 percussions per minute. Level one is 1800, level two is 2400 RPM, level three is 2800 RPM, and then level four is the fastest, which is 3200 RPM. A lot of my massive massage guns that I have and reviewed in the past are all maximum 3200 RPM as well, so this is great to be on that standard in such a small size. So that's everything that comes in the box, and that's a little bit of the information around the specs, so now let's go ahead and try this out.  And I use this for a lot of my sort of soreness and muscle aches when I come back training hard at the gym, and it just really works, and I've really lived by some of these massage guns. So I'm gonna try this out, turn this on. So this is level one, as you can see with the blue indicator, it's so silent, it's, I'm gonna put this towards the microphone actually. So the microphone is just above my head, it's probably gonna be very hard to hear, and then I'm gonna put it to level two, level three, and then finally the fastest one, level four. Now if I was in a noisy environment outdoors, maybe I'm playing football in the park and I wanna use this or I'm in the gym and there's some music playing in the background, I guarantee you will not hear this. You can hear it now because it's a very quiet room here, but it's so tiny and it's so quiet, most people won't even realize that you actually have a massage gun with you or you're even using one. So I've put it back to level one, I'm just gonna put it to level four on the maximum, try it out. And in fact, using the metallic redhead rather than some of the original ball heads that come with it, which you find in pretty much all the other massage guns. This one, it feels quite cold because of the metal material on it, the aluminium alloy, but actually it feels so smooth and it feels like it's doing a bit of a better job because you can press a little bit harder and it won't hurt that much. So I tend to use this on my arms and specifically on my legs as well because I do play football from time to time and pressing this on my quads, it actually feels very nice, very smooth, but not just that. I think the main selling point on this is the size of it because it's got such a natural grip on it, if you hold it like this or you just hold it like that, you can easily get a very strong grip and go even deeper into your muscles and it's so easy to massage yourself without the need for anyone to help you out. Now of course, if you wanted to aim a little bit in towards the middle of your back or the top of your back, then you're gonna need someone else to help you out because it is quite small, it doesn't have sort of an extension pole on it or it's not large enough for you to reach those types of areas, but the areas that you can reach with this, it just works and I'm really happy with it. So I will be using this as my main massage gun going forward and the other selling point about this is that you can easily take this with you abroad.  It doesn't even take up much space. So it's very convenient to take with you. It's the perfect travel companion for people that do like to do a lot of sports, a lot of traveling, a lot of walking, you know, anything like that, it's just something you need to have. So for me, I'm very happy with this purchase and I do recommend this to anyone that does like to use these types of percussion massage guns. All right, guys, so I hope you liked that review. Of course, if there's anything else you'd like to know, drop a comment below, check out my Instagram at trainingreviews. Otherwise, I hope you subscribe. I've got tons more cool videos coming out in the future. I hope you like this video and I'll catch you guys next time. Take care.


Hi everyone, happy Tuesday. Tuesday? Tuesday. First of the month, we've got 2022 certified football, eight box, pick your team, 14, coming at ya. Big thanks to everyone here for making it happen. We had a nice little late night rally too on the filler where we gave away the remaining teams and certified. So thanks everyone for making it happen. Patrick, you got last spot mojo before we pulled those teams for the fillers. If you have double rooftops, that means you won a spot within the pack break, the filler break itself, and then you ended up with that team, like the Steelers. So that was a nice little parlay, Brandon. All right, now you remember from the break we did last night? Mark those with Xs so you know that this is the second half of the same case. Thomas feeling something great in these boxes, something good in these boxes, you can feel it in his bones. Now Oliver, who won the Broncos in this, kind of looking for a Russell Wilson autograph. He's the oldest, dressed up as Russ for Halloween. Nice.  It's always a good posture. Right, did he do Russell Wilson catchphrases? Is that today? He said, knock on the door, standard trick or treat. Once you get some candy, let's ride. And then he leaves. That'd be a good bit. Just high knees, Oliver's cool. That's some good cardio there. There's Trey Lance at 275, Roger McCrary to 199, and Devonte White, seven out of 20. Oh, Oliver, I've got more of these for you too, by the way. Devonte White, seven out of 25. Packers, that'll be for Nick Martindale. And then we've got Romeo Dobbs, 146 out of 199. Piece of the jersey, another one for Nick. There's Desmond Ritter, nice. Desmond Ritter to 149. That is for Brandon, and the ATL. I think he is the only quarterback drafted, still on an active roster that has not made an appearance yet or a start yet. I think everyone else has. Calvin Austin to third, that's another one for Brandon. He got the Steelers as well. He's looking for Calvin Austin's teammate, the guy that will throw him the ball. There's Ikem Ekwonwu to 275. There's Devonte Adams to 75. Brutal game for my Raiders last week. And if they lose to Jacksonville, I don't know what's gonna happen. Someone's gonna have to get fired. Won't be Josh McDaniels. It'll be, I don't know who gets the sack.  Maybe Patrick Graham, defensive coordinator, might be the, although it's actually not that bad. I think maybe the argument has been floated that maybe the boy genius, Josh McDaniels and Patrick Graham's schemes are too complicated for a team that's not that talented, especially on the defensive side of the ball. So maybe some simplification needs to be in effect. A lot of trades happen in the NFL. Trades don't, at least, at least this many trades hasn't really happened, at least in recent memory. What are some of the trades that jumped out at you, ladies and gentlemen? It's Hunter Renfrow to 349. Drake London to 399. I mean, the McCaffrey trades the Niners look like. That's an excellent move. Here's Trent McDuffie. Five out of 10 for Casey. That'll be for Jared, picked up the Chief straight up. Chase Claypool, right. Chase Claypool went to the Bears. That jumped out at me too, mostly because I didn't know what the point was, I guess. There's Damien Pierce to 349. Like, they strip away a lot of, two of their best pass rushers, but then they turn around and they're like, I guess weapons for Justin Fields. There's Fadarian Mathis. Justin Jefferson to 99. Vikings getting TJ Hawkinson, the rare in-division move. The Vellis Jones Jr. to 50, 19 out of 50. Nice color there. And Ink for the Bears. That'll be for Emma with Chicago. Good trade for the Steelers, says Oliver. Oh, okay, I see, I see, yeah. Got some assets back. Deontay Johnson. Speaking of Chase Claypool, there he is. And there's Skye Moore. Reach for the Skye. 300 out of 349. That is for Jared and Kansas City. All right, box two in the books. Thomas was thinking box three has the banger. Did I see where Justin Fields is undefeated this year against his classmates? There you know, like, I mean, he must have a lot of classmates that are in the NFL. There's the Sean Watson and Pierre Strong Jr. Three color patch in autograph. To 349, you can still get some nice color, even if it's out of 349. That'll be for Karen and the Patriots. Oh, his quarterback draft classmates, is that what you're saying? There's Jordan Davis to 199. Mark Andrews to 50. And TJ Watt, two color patch, three out of 30 for Brandon and the Steelers. There's Andrew Booth Jr. to 99. Snoop Conner, Snoop Doggy Dog. Yeah, he's beating Lance. Lawrence, there's Devin Duvernay. Nice, mirror signatures. 40, 40 out of 75. I'm a man, I'm 40. It's Anthony with the Ravens. They beat the Patriots, right? Didn't they beat the Pats? Matt Jones. There's Kenny Pickett, just a piece of the jersey. 30 out of 99 for Brandon and the Steelers. Kamara to 199. And Elijah Mitchell, dark horses to 199. Yeah, Lance, Lawrence, and Mack, huh. That's interesting stat. But ultimately the Bears are three and five. Box four of eight. Let's play a little game of If You Told Me. If you told me that the Seahawks would be atop the NFC West, I'd say you were crazy. Five and three, three game winning streak. They even have a positive point differential, plus 11. Not expect that. If you told me that at this season that the Falcons would be in first place in the NFC South with a four and four record, I'd say you were crazy. Maybe like get out of town. If you told me that the Vikings would be six and one on top of the NFC North with a plus 29 point differential on a five game winning streak, I'd say you were nuts. But there they are. If you told me that the NFC East would feature an undefeated team, seven and oh Eagles, a six and two Cowboys without Dak Prescott for much of the season and a six and two New York football Giants, I'd say get out of town. Well, it's a weird season, Brandon. It's Camara to 149. There's Dak Prescott to 50. Kavon Tibodeau, there's some Kenny Pickett and Derek Stingley Jr., Texans to 75. Yeah, Oliver, what would you say?  You need to go to the Looney bin. I would bet against that. I would bet you a steak dinner that they would not be the worst offense in the NFL at this stage of the season. Crazy. What's going on? This is why I don't play wind totals. I was telling everybody that preseason is just like we're playing wind total game. And I was like, well, I'll talk about it but I actually never play wind total. It's Chris Alaveta 349, Mark with the Saints. It's just too, I mean, I guess the NFL, it is a lot of parody in the league. Yeah, that's another good. If you told me that Russell Wilson and Tom Brady would be playing like garbage, I would say you were crazy. That you need to go into concussion protocol is what I would tell you. I'd say it was Mills for Jared and the Texans. Danny Gray, Jersey and autograph 69, nice out of 399 for the Niners, Victor. Ty Chandler to 399, Dallas Goddard to 349. How about Olive Phillip? Well, that's not as crazy. If you told me that the Eagles would be playing really well this season at the Phillies were, you know, went on a World Series run, that's not too crazy. It's Kenneth Walker to 349. A little crazy, not that crazy. Not Reims being the worst offense in the natural football league, kind of crazy. Kenneth Walker going to the Seahawks, Duane with the Seahawks, there's Stafford right there. Not Geno Smith turning back the clock. There even was a clock that he couldn't even turn back to. But him leading the NFC West, now that's crazy. Yeah, Geno Smith throwing darts. That's crazy. If you told me that at the beginning of the season, I would, David, I would laugh in your face as respectfully as possible. But I would say you were crazy, respectfully. Geno Smith has the second best, that has the best completion rating. Completion percentage, 72.7 completion percentage. It's crazy. He already has 1,900 yards on the season. That's what top 10 yardage right there. I mean, he's got, he's got, he's top five in touchdowns, 13 touchdowns. To how many interceptions, three. That's it. Wild, wild. If you told me that the Giants would be six and two. Halfway through this, this whole, this half case rate ladies and gentlemen. Let's take a look at the AFC. Is there anything crazy in the AFC? If you told, if you told me, I guess that the Raiders would be two and five. I don't know. That probably would not surprise me.  And that, and that Devante Adams would have like one catch. That would be, that would be crazy. I guess there's not too many. Yeah, I guess if you told me that Russell Wilson would be as bad as he has been. I'd say you were nuts. Any surprise in the AFC South? Yeah, man, Brandon saying, if you told me that Frank Wright would still be employed after a three, four and one start at a minus 28 point differential and somehow still be employed, Brandon would say you're nuts. Well, if you told me that the Bengals would look as not, I mean, they're four and four, but if you told me that the Bengals would be four and four and look as sort of as sloppy as they've looked, I'd say you were kind of crazy. If you told me that Bailey Zappie would be a hobby darling for at least a few weeks, I'd say you're crazy. But he was, might still be. Patriots, it's for Karen. And maybe the jury's still out. I think that might be a city divided. Is it a city divided? I'll just pretend it is. Yeah, the Jets, if you told me that the Jets would be five and three in second place in the AFC East, I'd say you need to get into concussion protocol. Here's Ryan Shazir, seven out of eight. It's a nice one for Brandon and the Steelers. Nice mirror signatures.  They've been looking pretty good, but they've got hosting Buffalo at New England, hosting the Bears at Minnesota, at Buffalo. That's that five game stretch right there. If they finish that stretch three and two, we'll be having another session of If You Told Me, five weeks from now, a month or so from now.  But what if they do? It's Jordan Poyer, Jared with Buffalo. Buffalo, we got EZE, there it is, nice patch. 87 out of 249, that will be for the Dolphins. That's gonna go to Anthony. Dolphins are kind of a surprise too, although maybe not if you told me. Where does that three and two come from for the Jets?  You gotta win, you know, one, you gotta split that Buffalo series. So if they beat Buffalo, maybe they'll lose to Buffalo, but they'll go to New England, they already lost to them. So they'll go to New England, beat them second time. They'll beat the Bears. And then I guess you got, I mean, at Minnesota, at Buffalo, both of those are pretty difficult. But if they can win one of those, that's three and two right there. I'm sure a lot of Jets fans will take three and two in that set of five. It's gonna be a lot of work though. I say their path is they're losing to Buffalo. And now that while they're hosting Buffalo, maybe they lose to, lose at Buffalo. Maybe they shock the world and they beat Buffalo. They'll go to New England, they'll beat New England. Watch, they lose to Chicago.  Strange, that's not too, it's a little crazy, but. Bills at Jets, Buffalo's minus 13. Road favorites at minus 13, that's, I think I'm actually, if forced to choose, I would, I don't know if this would be one of my picks, but forced to choose, I would take the, I would take a flyer on the Jets plus 13. Does Claypool do anything with the Bears? Yeah, Oliver's saying no. What does everyone else think? I don't really think so. Not this year anyway. I've got a lot of, I've just got too many different problems on that team. There's David Bell to 399. That'll be for the Browns. Patrick Davis, last one Mojo. Is that what Chris Bourbon's pick was? His Super Bowl pick was Bill's Niners? That could happen. And what a, what a move, getting Christian McCaffrey. There's Ray Guy, 17 out of 50. Old school Raider going to Emma and my Raiders. Oh, his pick is Bill's Niners every year. There's Drew Laugh to 99. Got a Kenny Pickett to 75. And Breeze Hall, poor Breeze Hall, three color patch and autograph to 149. I think he's done for the year, right? He was on his way to offensive rookie of the year, I feel like, or was at least the front runner at the time. Jets, that's for Mark, Mark L and the Jets. Brandon, you'll get this cool looking Kenny Pickett rookie card. There's Brock Purdy to 399. And there's, to Ryan, Davis Price, 90 out of 349. I mean, McCaffrey just completely changes that team. I mean, that game against the Rams was, and you know, the Niners just have the Rams number in general. But combined with getting Christian McCaffrey, so then you have Garoppolo, Garoppolo at 21 for 25. That's pretty much where you want him to be. There's Najee Harris to 50. There's Sky Moore to 249. You want him throwing about 25, 20 to 25 times a game. That's it. That means you're controlling the game with the run. That's exactly where you want him to be. Christian McCaffrey, 18 carries, 94 yards in a touchdown. He even threw for a touchdown. And then eight receptions, nine targets, eight receptions, 55 yards in a touchdown. Perfect outlet, you know? And then Waitill, there's Jalen Peter. And Waitill Debo comes back. And then they've got two players that can, you could set up two running backs in that back field. What are they gonna, what are they gonna do? Are they gonna run it or are they gonna pass it? They can do both. Both of those guys can do both. And then these, you know, you still have Brandon and I still have George Kittle. Still have guys like that. Then, you know, defense is pretty solid. That's a good team right there. I think let's see what the Niners' next games are. They are facing the Chargers in a prime time game. That looks like a Monday night game, Sunday night game, Monday night game. They're facing the Chargers. That should be a W. Arizona, these are all home games. Chargers, they got, what, one, two, three, four, five, six home games in a row? So they played a lot of road games to start this season. So they get some home cooking. Hosting the Chargers, the Cardinals, the Saints. I mean, that's gotta be three wins in a row right there. Dolphins will be a challenge. They're hosting the Dolphins. They're hosting the Buccaneers. We'll see where they're at in six weeks. At Seattle, which could end up being a pretty pivotal game. Then they're hosting Washington. They'll probably beat my Raiders. And then they're hosting Arizona. I mean, that's one, two, three, four, five, another five wins right there. That's at least nine. And then a couple others that are maybe coin flips or maybe not as good. I mean, it could be a nice 10-11 win season right there. All right, we got Tyrian Davis Price. It is sort of a classic key in peel football name. That's a good sketch. 120 out of 349, Trey McBride. Jared and the Cardinals. Yeah, that's a good, if you told me, Rex. If you told me that Matt Ryan, what, six, seven weeks of the season would be benched for the remainder of this season, for Sam Allinger. I would say, I would say, you know, beat it, pal. That's what I'd say. I'd say, get out of here. Don't waste my time.  But I'd be wrong. Here's Trevor Lawrence. Jaguars, 11 out of 149. Nicholas with the Jags. I mean, man, everyone thought Matt Ryan, all he needs is a little change of scenery. You know, he's still got something in the tank. You know, that Colt team is a good team. It's Derek Henry. It's Kyler Murray, the 149. It's Kevin Harris. Yeah, that is kind of wild. Everyone thought that they're just that away. Ooh, nice award winners. On-card autograph just in Herbert.  Nice, your 2020 offensive rookie of the year. Nice hit. And a Malik Willis for Nestor and the Titans. You guys first, first start, didn't have to do much last week, but got his first start, got a W. Thanks to Derek Henry. Yeah, a lot of people thought Colt were just a Matt Ryan away, but no. There's a Desmond Ritter relic, 93 out of 399, Brandon and the Falcons. Snoop Doggy Dog.  Snoop Connor for the Jaguars. Snoop Doggy Dog plays for a cat team. If you told me that a cat team would draft a snoop, I would say you were crazy. All right, last box. Well Rex, here's all you need to know about the Chase Claypool trade. I'm looking, for what it's worth, it's ESPN, but for what it's worth, grades, I'm just reading, the headline, grades for 19 NFL trades from the good parentheses, chubbed Miami to the bad Claypool to Chicago. That's what you need to know about that. Gino Smith, speaking of the bears, there's Velice Jones Jr., three-color patch and autograph, 94 out of 349. And we'll do a little recap after this too, it's a bit of a longer break. Roger McCrary did 325. Got goal team Jonathan Taylor to 199. Justin Fields to 99. I just don't, that was a little bit of a surprise. Like, you know, it seemed like the bears were like, oh, we're gonna try to add a weapon for Justin Fields, but at the same time, they traded away two great pass rushers. And yeah, they gave the Steelers a second round pick for Chase Claypool. There's Jameson Williams, 62 out of 149. That's for Shay and the Lions. We've got Evan Neal to 75. It's Kate Otten to 275. And there's Fred Taylor. Mirror signatures to 15. Jaguars, it's gonna be for Nicholas S., one of those classic boys. Those knees, if his body didn't betray him, could have put together a really nice career. And Kenneth Walker to 249. I think might be our final hit. That's for the Seahawks. That's gonna go to Duane. Stavante Adams to 349. I'll give you another, if you told me, Raiders edition before I do the recap. If you told me that Mack Hollins would have more receptions and yards than Darren Waller and Hunter Renfrow combined at this stage of the season. First of all, I would have been like, well, that means the Raiders are probably only one or two wins in, which is true. And I'd say you were crazy. Come on. I mean, I know there's been some injuries for Darren Waller and Hunter Renfrow concussion, but still. All right, thanks everybody for doing certified 14 with me. Nice, Justin Herbert, good late night rally. And thanks for playing, if you told me, with me. Seven out of eight, Ryan Chasier. If you told me, that's always a fun game to play every once in a while. It could be a regular bit in Jaspy's breaks. But thanks for playing, if you told me, with me. Thanks for doing certified 14 with me. I'm Joe for Jaspy'scasebrakes.com. I'll see you next time for the next football break. Bye-bye.


Welcome to Helix, the first professional wireless security system that can be easily installed any place in the home. This is chapter one of the Helix instructional series outlining the steps required to install the Helix panel. Everything you need to install the Helix security system comes standard in the box. This includes the desktop mounting stand, the UL compliant security system, a power supply, an Ethernet cable enabling communications, and an instruction manual. For a period of time we're also including a NanoMax door window sensor as well. Please review the manual for additional details on configuring your system. While it's possible to install the Helix on a wall, the recommended installation would use the desktop bracket. You simply insert the Helix panel into the base until it rests securely on the bottom. There's an alignment notch on the backside to ensure proper placement in the base. Adding communications uses the Ethernet cable provided. Plug one end of the cable into the slot on the backside of Helix and the other end into an open port on the home's router. Apply power by plugging the barrel connector into the slot just under the Ethernet cable and the power supply into an unswitched outlet in the home. You can secure that using the outlet cover screw as noted. The Helix system will emit a long beep and the LEDs will begin to light up. The top five LEDs should turn green with the top one blinking indicating AC power. It may take up to 30 seconds for the communication LEDs to come solid green. Make sure to subscribe to our YouTube page and click the Show More tab underneath the video where you can view valuable links pertaining to this product, similar how-to videos, and our low-cost, no-contract alarm monitoring services.