Okay, so this is my very first look at the new lineup of tight list irons, and I can tell you already that in amongst these four, they could have the iron to beat moving forward right now. So in today's video, I'll be giving you my first thought, a first look effectively at these four new irons. It's gonna be on course here at Betsy Coward Golf Club. I'll be talking about all the obvious things. There are in fact four models, T100, T150, T200, and T350. And we'll start off by having a little look at these four models before I tell you what the main differences are, and then can I find those out to be true out here on the golf course. That's a great start to the day in terms of the tight list lineup, but interestingly enough, that is not one of the main irons that we're gonna be looking at today. That is in fact from the utility lineup, and that will be also tested on course here today, but that is featured in another video. Anyway, back to the main irons. So these four irons, tight list of aptly characterized as the modern tour iron, the faster tour iron, the players distance iron, and the ultimate game improvement iron. So we can certainly see which category each of those fit into. What I wanna work out in today's video is, do they ring true? Should they be categorized that way? And more importantly for me, is how would we mix those sets up because I think there's a real opportunity to look at a blended set within this tight list lineup. Do you know what this place gotta be one of my favorite places to come and play a little bit of golf and test some golf clubs. We've got the water that literally surrounds this golf course at Betsy Cohen. Those tree lined fairways and the backdrops are so, so nice. But we're here about the tight list tee lineup of irons. I just wanna talk about the way they look because let's start at the bottom tee 100. Classic look, very minimalistic in its markings. I would call it a kind of muscle back design. It's not your sort of classic blade where you're just seeing not a lot of meat at all. I think there's enough on there to suggest that it might appeal to a few more players than you would think. Certainly for me at least. Then you got that tee 150. They're no different in all honesty. I couldn't tell the difference between the two. There's a slightly bigger profile and that's about it really. And then you move up into what is a very different looking set of irons in a tee 200 and a tee 350 because they're a very full iron if you like. I'd be happy with either of these sets of irons in my bag. Tile list has done a fantastic job in making them almost as good to look at as what this golf course is. So for me in terms of that category element first of all I think although there are four different clubs we've really got two categories. Quite simply the tee 100 is obviously that players tore iron as you've referred it to. Then we've got just a simply a more forgiving version of the tee 100. So these are the players irons. There's no doubt about it. The width of sole, the width of top line, the overall profile definitely puts them into this category. And for me the obvious thing to do that's where you're blending those two sets together. And then if I reach back to the other two it's exactly the same thing tee 200. And we'll talk about the way they look in a minute and tee 350 are exactly the same thing. They're a bigger and smaller version of each other. So obviously what you're gonna expect to see is more forgiveness in that tee 350 than you're gonna get in that tee 200. There's a lot of numbers to remember here but effectively we go right down to the bottom tee 100 proper players iron, tee 350, super forgiving iron. And in between all that I think we end up with what is two groups of product. And that's where you probably look to do the majority of your blending in the set. Anyway, I've got 150 in I'm gonna start off with a tee 100. Oh, well first of all, that's a real good towering ball flight. Perhaps just come up a little tad short of what we've got the 150 marker there. So just a tad short but a really solid striking. The first noticeable thing that brings a smile to me is just how good they felt. Don't forget this is a tee 100. This is smaller blade like style. I thought it looked superb at that address position to be honest with you. It's not small enough to put the fear of God up here. It certainly doesn't me anyway. And I'm really comfortable with playing that. That profile is really good. Very minimal offset. We've got a very straight ball flight. We've got a high towering ball flight. This is the weaker lofted obviously of all the four clubs that you'll see me test today which are all seven irons. And I'll put some comparable lofts of all the clubs all the four different sets on screen for you now. But that's a super start with a tee 100. So next up is the tee 150. And all it seems to be is just a little bit more muscle behind the club face itself. And hopefully you can see that in the close up images we've got. But really not a huge amount of difference between the two and if you sat them side by side you'd struggle really for me to find the difference. But I'm hoping is that little bit of muscle maybe that little bit of extra strength of loft I'm expecting a little bit further in terms of distance carried. But I'm more interested to know what the feel is like by comparison. Well that's an interesting one. Well that's right at the flag. Probably similar but I don't know whether you notice from the shot it was a little bit bottom groove you can see or I can see at least that didn't quite get then didn't quite catch that one as nice. So I'll reserve judgment so we've hit a few more shots. But my immediate feedback with that was that the fact that well first of all it done well from the bottom grooves in terms of where it got to but this idea of mixing those two sets up will be just hard to tell a difference visually in terms of your bag. But I'm gonna move on up into the bigger things now the players distance sign is the next one up is a T200 and we might as well stay in the same position and see if we can just sort of gauge yardage difference but I need a better strike with this one. Okay that's a different ball flight. I mean what always interests me okay that's the first one that's carried to the green real good strike real good ball flight. The interesting thing for me don't forget so that's T200 by the way and the interesting thing for me is the ball flight goes up even though it's stronger lofted it's flies higher than the other two balls that we've hit so far. So once again strength of loft is not always a determining factor in ball flight because obviously they've done a little bit different with that CG placement and we're able to still get that high ball flight. Felt really good but all of a sudden you start to feel a little bit of difference and if fear is your thing then you notice the difference between what I've just hit in those 100s and 150s and there's a little bit more of a clickier sound let's say than you're getting from those first two but in terms of performance probably in my hands the best performing club. However that T100 shot was pretty good. Let's move on to the big one. I've just cut across that one swing not as good but what again is very visible. Yeah that's not the best shot in terms of where it's ended up but in terms of the feel out of the thing I really like that you know and a bit of a surprise and that's why you need to hit multiple shots and that's what I'll carry on doing here this morning before I give you my overall verdict but the feel out of that thing was really really good. I got a softer feel than what I did out of the T200 and you would think in terms of the makeup there very much exactly the same. So clearly my shot with the T200 wasn't out the middle like it was out the T350. So first four shots, overall impression, super impressed with all four of these but I'm already starting to feel there's perhaps one in here that really is a standout product for me. That's a golf shot that is. I love it in that backdrop. Oh sit down well. Okay so that's back to that T100 and interesting enough and the weirdest thing for me is that the two best shots of it this morning and a few off camera and a bit of a warm up with the T100 is absolutely flying for me in terms of I just love the ball flight. It's a ball flight that is high but is still penetrating at the same time. Ball seems to be sitting down as well and grabbing so really impressive start with that T100. Great ball flight off these things. Oh, that's got a friendly bounce. I pulled that one just a little bit down the left but I got a friendly bounce in and that virtually finished in exactly the same position. Yet again, for whatever reason I didn't hit the T150 quite as good but the interesting thing is on both shots that you've seen on camera so far with this thing haven't hit the ball perfectly out of the middle. I know that for a fact, you get the ball has gotten there so we'll take that positive as well. Let's keep moving on. So I just had to have a quick glance down there make sure I had the right club and that's the interesting bit for me. We're up to the T200 now and I'm still not seeing a massive change in profile which I take as a positive to be honest with you because like I keep going back to and I'll speak in a bit more detail in a minute is the idea of blending a set seems a real obvious scenario here from tight list. Ah, that's a golf shot. That's a golf shot. Let's see where this pitches now. So again, we've got three balls on the green that sat down nice really good feel really good ball flight and I feel like there's maybe a little bit more forgiveness in there but it's only sort of, I don't know maybe it's a mentality thing, isn't it? Player's distance and at this moment in time those three irons have all landed in pretty much exactly the same place. This is the only club out of three where I notice a difference. That top line becomes really sort of visible. It goes into that game improvement category. It's still a neat profile but I must admit you can see the difference and you're supposed to see the difference. Got that heavy. This is where these things help. Worse shot of the lot. Well, I just got front edge to be honest with you. It was a worse shot, worse swing. Did okay, got there, helped me out. Did everything it's supposed to do. Do you know what? There's four decent irons here, you know? Now in today's video all I'm going to be looking at is on course performance and on my, like I said, first look if you like but I'd really like to get these inside on track but I'll look at some dry ball data and see what separates these four in terms of performance irrelevant of what we quite see out here. So I always think this is the key factor. These clubs are from Alpana Hotgolf and I'm just going to whiz over and have a look at the price of each of these now on screen because at this point I don't know exactly what they are so you're seeing them before I do. So let me know your thoughts. Where are they pitched in in terms of tight list pricing? Are they competitive? Are they going to appeal to you? And let me know would you consider putting any of these four in the bag? Are you going to be testing any of these? And if you do so make sure you give a little bit of a look at our partner at Hotgolf. So a quick look in terms of on course performance. Those three balls, like I said back there they looked as though they weren't separated by anything and they're not. So three different lofts but all finishing the same place. The ball by my feet interesting enough was the strongest lofted but the worst hit that T350 and it just goes to show forgiveness can only do so much but the performance of M3 can't separate it. Now do you know what? I can't believe this shot or the club that I chose to finish on was the T100 because I've not hit a bad shot with it to be honest here slightly baffled as ever because not expecting that to be the best performance in my hands but it was just pure everything about it is really good great profile, great feel that takes the box of that player's iron but it's not necessarily the one that I think is the standout product amongst the four because to be honest with you I'd go down the other end and put that T350 in there because again maybe it's not been the best performing in my hands if you look at it purely based on where the ball has finished but I would also I always liken the bit of the sort of what happens when you don't hit the ball quite so good my swings with the T350 weren't quite as good but the ball still did incredibly well and that's where I think that's what I think forgiveness is and that's where I think Tiles have got a real good iron set on their hands because that's the one that's going to appeal to the masses and the majority of average golfers and what they've done in my opinion this time around is they've improved the sound and the feel on a T200 and a T350 massively as well so tell your pick but from my opinion any one of these four could go in your bag depending on what category you're in what type of club you want to see in your bag but Tiles have done a fantastic job with every model cannot stress enough just how good these things are and you must make sure you go and give them a go if you're considering buying new irons right now and don't forget our partner over at Hock Golf right thanks for watching I would think tomorrow night we've got the utility irons to follow from Tileist as well and from the shots I've hit so far that's equally as impressive right, see you soon


This is specifically intended for Rubyists to use and integrate into your Ruby and or Rails apps. So I'm Chris Powers, I'm a software consultant for Optivo. We are currently hiring, so if you're looking for a gig in Chicago or Denver, let me know. But that aside, so I think the first question that we kind of have to tackle before we get into, you know, why do we want to try out the Jasmine library itself? First of all, why do we want to test JavaScript in the first place? And I think it probably goes a little deeper to ask the question, well, why are we testing the code? Because it's mine, it doesn't work. So the first thing is that JavaScript is important. And frankly, it's getting more important every single day. I've met several guys, I had conversations over the last couple of days here. We don't sound real happy about this. And unfortunately it's not going away. We can try to abstract it away using something like CoffeeScript. We tried to do something really clever called RJS. That went well. But it's important, and the bottom line is that the clients that we work for, the businesses, are going to continue to look for deeper, richer, more interactive experiences through the web. JavaScript is everywhere. Not only is it the language that we're going to be using to build out the client sides of our web apps, but now we've got JavaScript on the server if we're using something like Node or Ringo. And now we're even getting JavaScript in our databases. If you've been using Mongo, if you've been using Couch, you're very familiar with the fact that in the internals it's using JavaScript. And you're writing a lot of your queries or your views in JavaScript. Now one of the biggest problems is that while JavaScript is hard, and that's true. I think that JavaScript has become one of the most misunderstood languages that is still being used all the time. And I think because of that, a lot of times we try to take JavaScript and turn it into something that it's not. Whether it's a library like Prototype making a very ruby-ish or something along those lines. Trying to make it object-oriented when it's not strictly an object-oriented language, things like that. But this is probably the biggest complaint that I hear from people when we start talking about doing testing for JavaScript. And they say, well, it seems like a lot of work just for some lousy regression tests. And if that's the criteria, I would actually agree. Because when it comes down to whatever JavaScript you have in your app, it may not be too hard to just start clicking through and do your testing that way. Do some regression testing just by clicking through. Maybe you have a QA team, maybe you're lucky enough to have some people who can do this as their day job. And having automated tests may not seem like that big of a deal. But the thing is that that's not what TDD is about. Doing test for development is not just about building out a regression test suite. It's about guiding your development. So the first thing that it does is it drives good design in your code. Specifically, in your JavaScript code, you're going to find that it's going to become a little more object-oriented urr. Because it's not an object-oriented thing. There's objects and I think it gets oriented urr. What I mean by that is simply the fact that you're going to end up with code that is more modular and is more namespaced. Which is more important in JavaScript than a lot of other languages. Because our JavaScript deals with global variables and things. Modules, namespaces are very important. You're going to end up with code that is much more flexible. It's going to be easier to update, easier to modify and extend over time. And you're going to end up with code that is reusable. Both within the same project and then across projects. And those are all benefits of using modular design. Now why is it that writing tests and specifically test driving your development, why? How does that get you here? Well, the bottom line is that you can't test something without a name. You can't test something that you can't make a reference to in your tests. You know, when you're doing your jQuery code and you've got nested function inside of a nested function, they're all anonymous and it's all slick looking jQuery. Well, the problem is you can't test that. And that's one of the big problems that people have is they're like, well, I can't test this so I'm not going to. Test driving your JavaScript demands that you take a new fresh look at how you're writing your JavaScript. Focus and process. These are some of the benefits of using test driven development as well. The code that you write is going to be driven by the business requirements. It's not just going to be code that you're writing on a whim or you know, there's going to be a very strict set of business requirements that you get from your users or from your client. And you're going to iteratively work through those writing tests, writing implementation and following that red green refactor pattern. You're not familiar with that. The pattern is basically that red means that you've written a test that is failing. That's always where you start. You have taken a business expectation and you have written code that expresses that requirement and that expectation. And you see it fail because it's not done yet. It's not implemented.  You pass and that's green. And now refactoring is just that continual set of iterative changes that you're making to the internals of your code. Making improvements, simplifying your code that doesn't actually affect the exterior behavior or the API of the code. And when we get into that red green refactor, red green refactor, iterative development cycle, we start to get focused and we see process. You also know when you're done. You know a lot of times when you're working on a feature and there's really kind of vague requirements, you don't really know when you're done. There ends up being a lot of round trips between you and the client or you and your business partners. Nobody's exactly sure what it's done. But using TDD, we do know because once you're done with those business requirements, once you've written that last test, it's time to move on to something else. You also get some what I call free documentation. And for those of you who are using R-spec, and I hope that most of you or all of you are, you're already familiar with some of the benefits of this free documentation. So our specs that we write, assuming that they're good specs, they're going to be expressing the object behavior of the objects that we're writing. And when we run our test suite, we're going to have legible output that is going to be very descriptive and is going to kind of read like documentation and tell us what these objects and what these systems do. And these can be very helpful tools for when you have new developers who need to get up to speed on a project. They're able to go straight to the tests, to your specs. They're able to see how you are using these objects and what requirements you are putting on these objects. And it becomes a very expressive way of getting up to speed. Oh, yeah. Plus you get a regression test suite. And I guess the way that I've been looking at it recently is that this is almost just a side effect of all of the other benefits that we get when we go about our Ruby code, our JavaScript code, or whatever other languages we're using, taking a test-driven development approach to that. So why is it that we actually want to use Jasmine? Because there are a lot of JavaScript frameworks out there. And they're good ones, too. You know, you've got funk units, crew units. We've got Blue Ridge, and there's a series of them. So why isn't it about Jasmine specifically that I decided would be the thing to share today? Well, one of the biggest things is that if you are already familiar with RSpec, you're already familiar with Jasmine because they flat out ripped off RSpec. And it's a great thing that they did because it's to all of our benefit. They both have a very similar syntax. They both take that BDD approach, that behavior-driven development approach, to describing behavior of objects. And they also end up with very similar output, just like I mentioned before. Doubles is this kind of documentation. So the RSpec integration is very tight. First of all, if you're already using RSpec and you have a spec directory, it's going to drop a JavaScript directory into your spec directory. And that's where all your Jasmine specs are going to go. And if you're hopefully using something like Hudson or cruise control, using some continuous integration on your team to make sure that you always have a good build, Jasmine is out of the box ready to plug into that as well, along with your Cucumber tests, your RSpec tests, whatever else you're using. One other cool feature that has been added recently to RSpec is that when we're working with Jasmine and really any JavaScript tests, one of the things that you oftentimes have to do is you need to load in some fixture data.  And one of the cool things that RSpec supports now is that if you're using RSpec tests, controller tests that have the view integration turned on so that they are actually running the controller action and generating the view, it will actually take the output from the view and it will write it to disk. It'll save it tucked away in your TMP file. And when you run your Jasmine specs later, Jasmine will look in your temp directory, find these saved markup files, and actually use them. And so the great thing about that is that if you make a change to your view, and you forgot to make a similar change to your JavaScript files, you're going to see a test failure because it's going to load in that view. It's going to run the JavaScript and it's going to fail because of this change and you're going to find out immediately that you need to update your JavaScript. Getting up and running with Jasmine is surprisingly easy to do. It's about two steps. You just install the Jasmine gem, and then there's a Rails generator that you can run, and that will create a file like this. It's a Jasmine YAML configuration file. Basically, it just allows you to specify, these are all of the JavaScript files that I want, but my source files that I want to include so that I can run tests against them. Here's even style sheets that I want to include in case that affects the way that the JavaScript works. And then here's where I store all of my spec JavaScript files, and these are the orders I want everything to be pulled in.  One of them, and I think it's the faster and the easier way, is that you can actually run this in the browser, which is pretty sweet. You just run rate Jasmine, and that starts up a spec server on port 8888. And when you go to that browser, this is what you get. And you can see that of all these specs that I had, we had one failure, and the rest of them were passing. And when I make changes, all I have to do is refresh the browser, and I can see the updated tests. And these run very, very fast. I don't know, 10th of a second to run a couple hundred of these things. I mean, when you take the database out, it's pretty blazing. Now, using the browser has some definite problems with it, and one of the big ones is that, well, I want to run it from the command line, right? That's probably what a lot of you are thinking, and I want to integrate this into my CI system. I can't integrate a browser into my CI system. And so Jasmine also gives you rate Jasmine CI, which is going to run them on the command line in a way that you can integrate into your CI system, and it will run the specs from the command line. In the background, it's going to be using Selenium in order to run these things. And so it does take longer to do Jasmine CI than just running them in the browser, but this is going to be a good solution for those times when you need that flexibility. Chris, there's a lot of work going on trying to get other support for headless JavaScript testing. There's like eight different things that are being worked out right now for how to do headless testing of that so that you can get Selenium out of the picture. Yes. Yeah, there's some really cool development. I think I just saw a library called Phantom, I think, here. So there is a lot of active development in this space, which is really exciting to see where that's heading. So now at this point, I want to use RSpec as a point of comparison to show you what does Jasmine code actually look like. So let's get cooking. So first of all, all of our specs and our expectations are going to be grouped into these described blocks. And so on the top, I'm going to be showing RSpec code, and on the bottom, I'm going to be showing the Jasmine code that is essentially equivalent. And at one quick glance, you can see that, yes, these are very similar. So Jasmine gives you a described function where you pass in a string. You can't pass in an object, but you can pass it a string. To describe, I want to describe this cook object and describe the process of baking a pie. And now inside of these described blocks, I'm going to have the actual examples or the expectations in id blocks where it functions to JavaScript. And so what I'm able to do here is I can say it should be tasting, passing in an arbitrary string that describes this expectation. And then inside of this anonymous passing function, I'm able to run code and then set an expectation. So now RSpec, the way that we set our expectations is that we're given the should method on all of our objects. And we can then use matchers or we can use operators in order to actually set that pie.tst.should be true, setting that expectation. So in Jasmine, we have one function, expect, that actually sets up an expectation, as opposed to RSpec, which has a few, should, should not, should receive, things like that. Jasmine always uses expect. And you pass expect some kind of a value. In this case, my value is going to be the tasty attribute of pie. And then I'm going to use a matcher function in order to actually put that expectation on it. Now what exactly is this truthy? Why didn't we just say, expi.tst to be true or to be false? Well, and the reason has to do with how JavaScript as a language actually evaluates certain statements. There's a few quirks that you need to be aware of, and I think this is why they specifically chose to use the words to be truthy and to be falsey. So up top, we have the actual matcher definition of to be truthy. And you'll see what's happening is it's taking, so this side actually is what's passed in, and we're just evaluating that and inverting it twice to get an evaluated value, which is all well and good except for these and all these down here. So expect the string hello to be truthy, you know, that's true, because that string is going to evaluate the true. But in JavaScript, a blank string actually evaluates to false, which is totally different from how it works in Ruby and probably most other languages. Similarly, you know, one, two, three, that's going to evaluate to true, but the number zero actually evaluates to false. And so this is just a reminder of some of those quirks that it's more about evaluating truthiness than strictly whether it evaluates to true or not. So now if you want to do negative expectations using our spec, if we need to say that, you know, my should not be burned, then rather than using should, we simply use the should not method and then use the matcher. In Jasmine, again, we're just sticking with the expect function, but now we're able to chain on the not method in there in order to simply, you know, reverse the value returned by this matcher to be burned. So we've seen a couple of these Jasmine matchers. To be truthy, to be faulty, those are built-in. I'd say there's about a dozen or so built-in matchers for the most common cases, but if you want to be more expressive in your test, you want to do something like, you know, expect it not to be burned, how do we do that? So in both our spec and Jasmine, you're able to create custom matchers. And so in our spec, we get this spec matchers define method. We pass in a symbol for the method name and then we get this match block where we have the actual object and that actual object represents what is actually being tested. And so we can check that, check the color, see if it's black, and return a value based on that. So now in Jasmine, a little different syntax, but it's the same idea. We're going to use the this.addMatchers function and we can actually pass in an object with as many of these matchers as we want. Each key in this object is going to be the name of the matcher and then each value is going to be a function. And inside of that function, you get the this.actual object that we can then run different expectations on. The only thing we have to remember is that we have to explicitly return because it's not going to implicitly return the way it does in Ruby. Now you see in this Jasmine example, we're using before each. So in our spec, we get the before each and the after each blocks. This is nested inside of a described block and basically this allows us to do set up and tear down code before and after every single it block that's inside of that description. And so we have something very similar in Jasmine. We have the before each and the after each methods. The one gotcha that we need to take a look at here is you'll notice that in the R spec, I was able to just create the pie variable inside of that before each and that pie instance variable would be available in the after each in all subscript describes it blocks. Now the way the JavaScript scoping works, we don't get quite as much of that metaprogramming magic to make that happen. And so instead what we need to do is we need to actually declare the variable outside of the scope of the before each and then we can set the value inside before each because if we had actually declared the variable inside of the before each block, it would be stuck in there. We wouldn't see that outside of the scope. Now before all and after all, that's something that is supported in R spec and this is just run once before or after a set of expectations and in Jasmine, we actually don't need a special construct for that. We can literally just run code before a described block and run code after a described block and we get basically the same functionality out. So one of the things that really, I think, makes Jasmine stand out above some of the other libraries is how we are able to stub our values and we're able to do message expectations very similarly to how R spec does it. So in this scenario, we want to make sure that if a pie is 160 degrees, that it considers itself done baking. And so we accomplish this in R spec by creating pie, we're going to stub out the temperature method and then we're going to chain on and return so that we can return 160 degrees and then we can run the done baking method and assert that it should be true because that's our cooking temperature. Now this is where Jasmine and R spec start to branch off one another, I guess. And so Jasmine is able to do this exact same behavior with a little bit of a different style. What it uses are called spy objects and so a spy object is basically an object that when you use spy on, I'm going to spy on an object and then you pass in the name of the method or the attribute that you want to stub out. And what's going to happen is that Jasmine is actually going to take the method that you have that temperature method and it's going to pull it out and it's going to replace it with a spy object and that spy object can then do your bidding. And so when that spy object gets culled, it's not then able to do something like and return 160 and I get that stubbed value. So while it's a little different syntax and it's a little different under the hood, these are equivalently the same, the R spec and the Jasmine. So now in R spec, sometimes stubbing is not enough. We want to make sure that a certain method is culled. And so to do that, we would use the should receive. Say that, okay, so this cook should be going to make dinner, cook should receive the make a pie message. And we set that basically before it happens. We then do cook, make dinner and then basically we check to see if that expectation is met. Now again, we're going to use a spy in Jasmine and the syntax is the same for spying on this, the same as stubbing. We're replacing that bake pie method with our spy object. Now here's, and this makes a little more sense in Jasmine frankly, the fact that we actually run the method that we're interested in which is cook, make, dinner. And then we can put the expectation after as opposed to having to say what should happen in the future the way that we do with R spec. Jasmine allows us to actually look back and see what happened in code receiving which I think can be a little more legible. And so here we can actually place an expectation on cook.bake pie which remember cook.bake pie is now returning a spy object not the original method. And at spy object you can now do expectations on. So the spy knows whether or not it has been called so we're able to use the to have been called matcher in order to make that expectation. So taking that one step further we don't want to just make a pie we want to make a tasty pie. And so in R spec I'm going to say that it should receive the bake pie message and it should receive it with the argument tasty. And I'm able to just chain on the with method there to specify that expectation. And we have something very similar in Jasmine. All we need to change is that we can change the to have been called matcher. We can then use the to have been called with and pass in any number of arguments that we're expecting. So the real Jasmine only feature that R spec as far as I understand doesn't support is actually being able to haul through to the original method. So let's say that we want to make sure that something has been called and it has been called with a certain argument but we also still want it to run. Maybe it makes the test easier to use or maybe there's a significant original value that we still need to get out of that method. What we're able to do is when we spy on this cook bake pie method we can then use the and call through method and that's actually going to retain a reference to the original function. The spy is going to be hit with the message. The spy is then going to delegate it on to the original function and return whatever the actual response is. So I think that's actually, that is a really neat Jasmine only feature functionality that would be neat to see in R spec. I'm just not sure if it's possible to base on how the languages differ. You can do it with double R. Double R allows that kind of test doubling. Okay, using that as opposed to built in R spec. Yeah. Okay, thank you. You might want to repeat. Yes, so apparently the double R is a mocking library, right? Yeah, so double R actually does support the functionality I was just talking about which you can use inside of R spec rather than the built in R spec mock library. So the next thing that we want to do is we want to not only check to see that we received a message but that we received a number of times. And so R spec gives you the nice sugary syntax where we can say that the cook should receive the check the pie message twice because checking at once is not enough. We can do something similarly in Jasmine. At this time, inside of our expect function we're using cooked out check the pie which returns our spy. But now the spy actually has some attributes on it and one of those attributes is the call count. So you're actually able to ask the spy well how many times were you called? And we can then assert that it's going to equal two in order to get the same functionality. So now expectations on errors when you throw errors. So let's say that we have a cranky cook and when we tell him to make pie to raise the error, make your own damn pie. So if we want to test that, in our spec we actually kind of have to jump through a little bit of hoop here, right? Because we can't just raise an error inside of our it block. It's going to blow up our whole test week. And so what we're able to do is we're able to use a lambda to create a scope where we can run the volatile code. And we can then actually put an expectation on that lambda. And we can say that that lambda should raise the error, make your own damn pie. And with Jasmine, I think it's actually it's cleaner the way that we can do it here in JavaScript is that we can set this up.  And we can say that we expect this method the cook.bakePie to throw a given error message or given error object or whatever you're using in JavaScript to represent your error. And so what to throw does is it will actually execute the cook.bakePie method and then it will put the expectation on whether or not that through an error that matches the message or object that you passed in it. Finally, simulating errors. So getting a little more complex now let's say that we want to do some errors we want to read pie with pseudo. And so if our cook tells us to make our own damn pie we will then use the pseudo makePie. And so we're able to stub out makePie method and we're able to use the and raise Jane method in order to purposefully raise that when it's called. And in the error handling then that pseudo.bakePie method would get called. And this too we can do in Jasmine. When we spy on the bakePie method we're then able to chain and throw on to this and we pass in the string or the object that's representing our error. And then what we're able to do is we can just expect that the pseudo.bakePie method will be called. And so this again is going to be functionally equivalent to how our spec does it. And so I want to point you in the direction of some resources if this is something that sounds interesting I would say give it a shot jump in there and start playing around with it. So there's actually some really great documentation it's up on github it's pivotal.github.com and this is a full set of documentation and examples that shows you how to write your Jasmine tests. And again if you're familiar with our spec and you're using that already this is going to be a really smooth transition for you. You can check out my homepage chrisjapowers.com I have a lot of links and notes and things about Jasmine and other JavaScript TV topics so you can take a look at that. Also a project that I'm working on is not quite ready to go yet but it's going to be a set of resources for JavaScript specific you're going to be doing screencast tutorials etc. And so if you go to jobscriptmaster.com just give us your email and use the sign up code roa2011 and we'll make sure that we send some free stuff your way a free tutorial that goes more in depth than I did here tonight about how you can start using Jasmine. So if you have questions we've got some time now and you can obviously send me up on Twitter I'd be more than happy to talk shop. And also if you have any feedback let me know. I'd like to hear what you thought about the talk on thespeakerrate.com I'll tweet that one as well. Yes? Yes. Sure, yeah. So the the idea is that I'm technically speaking in the implementation code oh, thank you So to repeat the question he was just asking in this test we're making reference to the pseudo big pie method how would that actually be called that I'd be expecting it to be called and I guess the idea was that if I put in some error handling code to catch this error or make your own damn pie and then in that handling code rather than clean the program I'm actually then going to run the pseudo big pie in order to try to get you know Oh, you know what you are absolutely right. Sorry about that. I'm missing the last line should actually do something like I think I was using cook.make.dinner Oh, okay. Sorry, you're right. I was missing a line of code here. Imagine cook.make.dinner is at the bottom there and that would be the method that we're actually running in the test. Yeah, the maker pointed out anyone else have any questions about background? Yes. Have you seen evergreen at all for integrating jasmine with rails? The question was have I seen evergreen and unfortunately no, I'm not familiar with that. What is that? It's just another way to integrate jasmine with rails instead of depending on our spec. Does it give you a like a different kind of runner? It uses selenium by default but it uses capybara under the hood as well. Okay. Tell us about capybara also. Okay. So it sounds like evergreen is also another framework to fund your radars. Sounds like a cool project using capybara. Yes. Your JavaScript code includes references to things like buttons and links and we've got new trigger events on those objects in the context of your capybara testing. Yeah, so the question was assuming that your JavaScript code is going to have a lot of references to DOM elements, buttons, links things that you're going to be clicking and that you're going to be clicking on event handlers on. How does that work and how do we have access to these objects? So there's a few things. First of all if you're using jQuery a jQuery jasmine library that you can kind of mix into your current test code and it gives you a lot of helper methods that allow you to do stuff like this. And so a common usage pattern I would say there's probably two common usage patterns. The first one is that you would create elements in the DOM using jQuery like before each block for example. And so let's say that you have a described block where you're describing a form of functionality and you have some kind of an Ajax call or some kind of a click handler on the button. So what I would do is I would basically figure out which of the keynotes well I need a form with a certain ID I need a button in there with a certain ID and using some of the methods of jQuery I would actually create those those DOM elements and you can attach them to the document or you don't have to when possible I like to just keep my DOM elements you know they exist but they're not actually on the page test one faster you don't have conflicts of things bumping into each other the other thing that you can do that is the fixtures so if you have you know markup that is either generated from your RSpec code or it's just markup that you you know it's your fixture markup you can create an HTML file and then the jQuery the jQuery Jasmine library gives you helpers to very easily load that in put it in the DOM and now you can start simulating clicks and doing all that stuff so that you can fully test all of your interactive behavior Yes? Test AJAX calls using the spy function or is there some other approach that you use? I would say that usually I treat it the same way I treat like RSpec kind of hitting external resources or you know like I'll stuff out the basically use a spy to make sure that the call is being made and then in another test I'll be calling the callbacks the error callback or the success callback with simulated responses so that you're not actually hitting any external resources in the test game and I know that there's some I've seen some different helper libraries that I don't have much experience with but there is built in support for testing asynchronous coded in Jasmine and there is more extensions that I've seen on GitHub for people to allow them to better more easily spec out AJAX calls and other asynchronous behavior Yes? I was curious if that was important That I'm aware of No, it's pretty much all just kind of in the before blocks and like I said anytime that you create a variable that you're going to be using inside your tests inside more than one test those all kind of get declared at your highest scope usually have like a bar statement at the top of the page with all the variables you're going to be using just so that they're all declared at the top of the scope but yeah in terms of some of the semantics of using Subject and Lead I haven't seen an equivalent to that in the Jasmine Yes? I know it's a whole nother talk but endless JavaScript testing with CI and it does it uses some kind of a headless Firefox something or other in the background you know I actually I really do like using the Jasmine tests in the browser just because I find that it suits my workflow pretty well they tend to be very fast and I've had I just generally say I've had more longer than that in server and that always works well but I'm very excited to see some more mature implementations of doing the headless browser testing for sure alright well thank you very much


It's amazing how much a tiny little insect about the size of a grain of rice can change whole forest landscapes. Mountain pine beetle is native to the Rocky Mountains and can cause devastating effects when an outbreak occurs. Mountain pine beetle can be found from Canada to Mexico and sea level to 11,000 feet. At normal levels, these beetles help thin and rejuvenate forests by killing older or stressed trees. However, when there is a huge population explosion, epidemic levels are reached and entire forests are in danger. There was a drought in the Rocky Mountains in the late 1990s to early 2000s that stressed trees. The drought, in combination with warmer winters and old dense forests, triggered an epidemic. By 2012, beetles had killed nearly all of the mature lodgepole pine trees in southern Wyoming and northern Colorado, over 1.5 million acres. The total impact of the mountain pine beetle outbreak was 3.4 million acres. Mountain pine beetle flies slowly about the speed of human walks and they only fly a short distance to their next host. It takes numerous beetles to kill trees. These limitations make the feet of killing millions of acres of trees quite mind-blowing. From the University of Wyoming Extension, I'm Mae Smith, Exploring the Nature of Wyoming.


The assumption in marketing is usually that more is better. More Facebook friends and fans, more people on your email list, more people in your Facebook group is better. And I'm here today to challenge that assumption because I've started an experiment that is showing me what I intuitively believed but didn't concede, which is that I recently removed 3,000 Facebook friends. And, of course, eventually I can add them back if there's real mutual interest. But I noticed that after I removed 3,000 Facebook friends, my engagement, the number of likes, the actual absolute number of likes, went up on my Facebook postings. I removed two-thirds of the people in my public Facebook group and the number of likes has not gone down. Isn't that interesting? So it's not the size of the group or the friends list that matters. And this brings us to a deeper point, which is what if we each... I mean, none of us need a huge following. I mean, what we all really want is a stable income because we're serving people well and we need to have the feeling and the experience that we really are serving people really making a difference in their lives. It doesn't require a big following. It requires people coming back to us and saying, you know what, you're changing my life. And so I want to encourage us to take a stand and do the opposite of what traditional marketing, the limitless ambition is trying to say. It's bigger, bigger, more, more. But rather, what if we each took care of our own circle well, truly well. And the people who engage with us, we keep helping them and don't have to worry about all the people who are not engaging with us. Help the people who are truly engaging with us. Create services and make it really effective for them. Then we'll all have enough. We all won't be competing with, okay, how can I get a bigger audience and that eats into someone else's audience? We just take care of our own. So I'll add more notes and surprising details in the notes of this video, but I hope that that's a nice perspective to contemplate. Until the next video, I wish you well.