 All right, cool. It's about quarter till now. Thanks for coming. This is a front-end ops session. So we're going to be talking about a lot of cool stuff that you can do to automate your front-end workflow and also automate other pieces of front-end development. And really, this is what I like to call how to automate the process of breaking things, because that's mostly what I did in order to get to this point to be able to share all this with you. So, my name is Chris Ruppel, one consonant short of our favorite content management framework. I'm a front-end developer at Four Kitchens in Austin, Texas. You can hit me on all these things. R-U-P-L is my username everywhere that I can make at that. And then, like I said, we're at Four Kitchens. We're a development shop in Austin. Maybe you've heard of us. If not, we have done a lot of stuff around server performance in the past, namely with a press flow making triple six viable for like integrating with the larger web stack, like MySQL replication, varnish, and that kind of stuff. I have nothing to do with that, so don't ask me any questions about any of that, because I don't know. Also, we're hiring, so if you feel like working at a pretty awesome company with a lot of cool people, hit the link in the slides here. These slides are already posted on my session page, so you can go there and check it out via the schedule if you want, and follow along. If not, that's cool too. There's lots of code examples, and I'll get to that in a second. I've done a couple of contributions to Drupal here. I don't have many of them listed just because I had to pick a few. The big one that I really focus on is the Modernizer Drupal module that, in turn, led me to be able to make some small contributions to Modernizer itself. I've got a pretty cool Jekyll schedule thing that's out there, like, oh, sorry, Jekyll. I shouldn't have mentioned that. And then I've done some work on Drupal 8 way back in the day when it was more like Drupal 7 than anything else, also making it a little mobile-friendly, and although I've taken a hiatus, I am interested in all the Drupal 8 JavaScript stuff if you were just in here for Nod's presentation before. There's some cool things that are happening, so that's me. So this is in the DevOps track, and it's fairly simple compared to a lot of stuff that's going on in front-end, although we're starting to gain these tools in the front-end world. No, this is new, so if you are already familiar with a lot of DevOps and the person that handles all of that in your organization, then I'm probably not going to be blowing your mind with the fact that you can automate some of these things, but hopefully I'll be able to show you a few tools that you can leverage using a system that you've already got set up. Having said that, I'm not going to cover the specifics of setting up Jenkins or anything like that because that's out of the scope of this, and there's other material where you can go and learn that type of thing. So we're going to talk about other things that we can integrate with continuous integration and those types of systems. But like I said, front-end is maturing as a trade, and it really has matured a lot in the last few years, and so we're starting to feel a lot of pain points that people already felt in other communities long ago. So when you break a PHP script, it just gives you nothing, or it gives you an xDbug stack or something like that, and so you either get your HTML to the page or you don't. And then yes, there are other nuances involved in errors in PHP, and you can have lots of weird things, but if you really break something, you're either breaking it or it's not broken. And then on the front-end, because of the way that browsers evolved and because of the way that they have to support all these different scenarios, there's lots of weird subtle things that can happen to your browser and to a mobile phone and to other devices like that that are very, very subtle and unnoticeable until they become this bigger problem. And so a lot of this stuff are things that we just rely on someone to fix and then not break, but we never had any way of making sure that someone isn't doing that and error checking all of these things like CSS, minor padding changes or margin changes, changes to JS files that break things like just adding or removing a semicolon, can delete an entire aggregate's worth of usefulness, aggregates changing when not necessary and that kind of thing, like introducing performance regressions when you don't really need to be doing that. And then also, like I said, there's tools that are evolving too and we need to use these tools because although it's not all about the tools, tools can really help you to provide a better experience to users in a way because if they take out a lot of, if they provide automation and take a lot of tedium away from your work, then you're able to use proper testing protocols and that kind of stuff a little more thoroughly because you've got a tool doing this for you instead of having to like run this automatically. So like I said, there's workflow tools in PHP, there's more than I could possibly name. And so we need the same community of tools built around the front end trade because that's how it can be taken to the next level and be more effective. So there's lots of things now that you can do in front end that are just a few commands away on your command line that were just not even existing two or three years ago. Things like dependency management, automated testing and review tools, and like even holding people accountable for the changes that they make to the code base. So this is not my term and this is a term that's been around, it's kind of been on the tip of everyone's tongue and it's still like a spot that hasn't been explicitly filled in most organizations or really, yeah, almost all. There's a guy, Alex Sexton, that wrote an article for Smashing Magazine describing the ideal front-end ops engineer and so he goes through the whole spiel of what he considers to be front-end operations and there's a lot there. If you go read this article, it is linked in these slides. It's kind of buried in the green there, but you can go read it and he talks about everything from deployment and asset management to making sure that rendering times are staying the same and your browser stack and all that kind of stuff. So there's a lot, lot, lot there. However, we are at a Drupal conference and most people for the most part are just building websites instead of building a product or a huge complex application and so all the examples I'm going to show you today are kind of like starter examples that should get you thinking about this kind of stuff and you can apply it and just build on this and keep it going because these are useful for basically all websites that are being built and it can be taken to so many degrees past what I'm going to show you that it blows my mind when I see what's going on in the front-end world. So the main takeaway today is that we want to change how we work. We don't want to change and be married to a particular tool. The stuff changes really fast, but what we do want to do is change how we're working. Was there a question back there? Okay, sorry. Yeah, I'm a fan of just like stopping. If anyone wants to stop me and ask a question at the end of a section I'll try and put some space in there so we don't have to wait until the end. So feel free if you want to just come up to one of those mics. So in order to deliver the best, fastest site possible we do have to think about our development process and update it a little. My huge perf crush right now is Ilya Grigorik of Google. He's on the Make the Web Fast team, part of the Chrome team basically. And all he does is performance and he's basically always saying, this isn't like a checklist that you look at at the end of your project. This is something that has to be continuous as you develop. You cannot put it at the end and expect to be successful. And then Fiert, which I'm not even going to try and pronounce his real name, has a great quote here that says, if you're trying to fix a website or make it better, don't take measures without measuring them. That's a bit of an English wordplay, but still don't do something without testing what you're doing. Don't radically change a strategy that you're approaching to. We've got a lot of things figured out in Drupal, like aggregation for example, but if you're going to change something or change the way you're loading your assets, make sure you've got good data that says that this is useful for your target audience. So a lot of these things are going to help you do that. Yes, right? We all agree. Because this question always comes up very often. Yes. All this stuff is on GitHub already. The links are on the session page. Check it out. You can take the code from the slides. It's all freely available. Use it for commercial purposes or whatever. I don't care. And also, actually this is a slight lie because I was like, I don't want to get caught by the Wi-Fi gremlins. But I basically, about 15 minutes ago, took a fresh clone of these slides and basically installed all the NPM modules that I'm going to show you, so I'm not going to run the NPM installs. But the slides should work out of the box. And also, one of the Ruby examples, you might need an RVM version or something like that, but still they should be pretty close to working out of the box so that you can inspect them. So cool. Automating workflow. This is the first thing that we'll talk about here. I'm just going to go over a couple of tools that help us stop doing manual labor. And like I said, when you stop doing manual labor, you can more frequently focus on delivering your work and letting the testing tools just kind of do that for themselves. So automation helps us stay consistent and it helps us deliver a quality product. Grunt, has everyone heard of Grunt? Let's get a show of hands. Okay, yeah, that's decent, cool. So Grunt builds itself as a JavaScript task runner. And what that means is that it does a bunch of grunt work for you. It does all these tedious things that you don't want to do. And it does this in an automated fashion. So you can read more about Grunt.js, but basically it's a set of tools that you run on your computer, on your dev environment, and it basically does things for you that you wouldn't want to do on your own. And then everyone's happy because both the things are getting done and we're not doing them. Hooray! The basics of Grunt is basically it's got a core and then it's got contrib modules, just like Drupal. So what you're going to do is it's all based on NPM, which is Node's package manager, NPM. And so if you're not familiar with Node.js, you don't really have to be to run all this stuff. You're going to see the code examples and see how little we're actually interacting with Node once you install it. And basically we're just going to run a couple commands and then you're done. They do have excellent intro instructions if you want to be familiar with Grunt and the slides contain the examples. Another tool. I'm just going to go through a summary of all the tools and then we're going to move on and look at them. Phantom.js. Phantom is a headless instance of WebKit and what that means is that it's exactly like the Web browser that you're using. I guess Safari, not Chrome anymore. But they're close enough that it's still useful. And so it does anything a WebKit browser can do except there's no monitor. It's all just happening inside the computer. It can, however, produce visual screenshots and that kind of stuff, which I'm going to specifically demo in a little bit. So this thing is really cool and it gives you a console and you can run jQuery and evaluate DOM nodes and do all sorts of stuff. And Phantom is its own tool, which I'm going to show you extremely specific applications of. But you can do tons of stuff in Phantom. Tons, tons more than I'm going to show today. It's a super awesome tool. So, yep, like I said, it's indispensable and if you have a task like taking a screenshot at several different breakpoints or something like that, you find yourself needing to do that to get, like, sign off on a bunch of work, then like Phantom is the tool for you. So check that one out. Docs, API, blah, blah, blah. Slimer, I don't really know. I guess Slimer, like Ghostbusters or something, is the not yet headless instance of Gecko, which is the engine that runs Firefox. And I hope, I'm not positive, but that it's going to apply to Firefox OS as well, which would be huge. SlimerJS is newer than Phantom, so it doesn't have all the bells and whistles, but they aim to be, like, API compatible, so that you can take, like, one script and say, Phantom, do this. Slimer, do this. And you can do them both at the same time, which would be rad. So there's Docs here. And like I said, it actually requires, like, Firefox to, like, do stuff. It's not headless yet. So on to some actual automation here, right? Who here authors CSS and JS? Right? Yeah. Oh, only three of you. Okay, interesting. That's surprising, so do we have, like, an entire group of IT here? Or what's going on? Are you guys just lazy, maybe? I don't know. So the meat and potatoes of Frontend is CSS and JS. I hope a few Frontend people are here to take it, to kind of start imagining this stuff. If you were in the last session about Drupal 8 JavaScript, you may have heard Theodore mention JS Hint. And so what they did was they went through the code base and they made sure that all the JavaScript in Drupal 8 could adhere to strict JS Hint linting, is what it's called. And so basically if you look at JS Hint, let's see if I can... Yeah. Yeah, there we go. So JS Hint is a code quality tool. And what you do is you put a bunch of JavaScript in here and you just type and then, you know, it tells you what's wrong with your JavaScript. We're not going to do that now. But it can basically help you debug and JS and help you catch little mistakes that you might make. So, you know, sometimes you can, like, forget a semicolon and then it affects something that's, like, 30 lines down the document when the parser finally catches up with it, right? And so that's really hard to find, but JS Hint makes this easy. And it does other things like tell you, hey, you're not using this variable to check the triple equals, which is, like, it avoids coercing variables and it's more of a strict conditional to check. So it does all this cool stuff. Actually, you know what? I can show you here some checkboxes at the bottom, so this is a good example. So it does all these things, just for the video later too, including, like, strict or even loose checking of ECMAScript so you can go... defaults to five, and you can go up to six or down to three. And going down to three is useful if you've got IE678 implementations that you want to work with. And then there's all this other stuff too. So, whoa, no. So, like I said, this is a useful tool, but sometimes it's tedious to go and, like, put the JavaScript in there every time. So let's automate this thing. So I'm gonna jump over to the console here and skip the install, like I said. But basically, we're going to run GruntWatch on this particular example. So now I'm in the js-hint directory and I'm just gonna type grunt. And now grunt says it's running a watch task. Now, what does that mean? It says that for this particular task I used a module in grunt called gruntwatch, which what it does is it watches the directory that you're developing in or, like, a theme folder that you're developing in. And it basically does stuff when you change the code. So I've got the code over here and you can see at the top, this file does have syntax errors that will trigger feedback from js-hint. So I'm going to save this file and you can see on the left that it instantly gives me a bunch of errors here. So it spit out a bunch of js-hint output to me that I can now read and grok. And it's saying, for starters, I'm missing a semicolon at the end of this line and it also says on line seven that I didn't do triple equals and we'll just do this again and see how grunt likes it. All right, I'd scroll down but normally you can see it when you... So now you can see it says example js changed again and it's running this stuff again and this time it says that I've got an extra comma here at the end of value two on line 13 and what that means is that I actually run... I ran this with es3 true right here and so that option that I just showed you on js-hint I have enabled for the grunt file and this is just the configuration for the grunt task and what this means is that it's actually checking this and producing errors that IE six, seven and eight would produce also. So I can do two things here. I can either change this to false or I can take the comma away from value two here and I will just change this to false real fast just to show you that there's only one error now and it's actually watching the grunt file itself so when I change the grunt file configuration it automatically fixes some of the other stuff here. So we're missing a semicolon is the last thing and I don't even know where that is but it's okay because it tells me there we go and see it even highlights the little red thing for me so oh great file example js changed we're running it, two files are lint free and it's done without errors so you know that you've produced quality code now you can move on and be assured that the code doesn't have any errors that you didn't catch because js hint has told you hey you're good to go which is pretty awesome I mean people have had problems with JavaScript and like this alone would be like something awesome that would help your day thank you, yeah me too so this is great stuff if you write a lot of JavaScript so cool, that's js hint any questions about js hint? the performance with large files that's a good question, there's not really a problem this is all local development too and I've had installs that have like dozens and dozens of files that I either wrote or vendor files and you can also in the configuration here if you do have lots of files I accidentally set this up incorrectly before and it was actually checking node modules the folder node modules which is bad because node modules, when you npm install stuff it'll go grab 20, 30 packages or something like that and then they all had these strict validation errors this configuration file is just checking top level js files and if I switch this to something like star star slash star dot js now it'll check all those node modules that here I can show you oh now I turn the es stuff off here oh my task is dead oh that's funny well anyway the point is that you can specify different directories and that kind of thing so if you only want to hit one directory that's totally possible so everything is in that grunt file too and you can see that the watch task that I wrote very very simple the watch just checks a bunch of files and then says run it on js hint in fact that's probably where this needs to go but I'm not going to hack on this in the middle of the presentation so that's the kind of thing to watch out for that's a really good question so thank you for bringing out you shouldn't have any problems with this and if you do you just kind of skip the pieces that you don't have any control over upstream packages and the like oh and then also this force flag can allow you to by default it'll just like stop when it finds errors and it's like fix this before I'll even can think about going on generate everything for you so that you can do them in really big passes and then as we just saw you can save your files like normal and you're hinting there are tons and tons of examples of grunt watch and earlier this year we went full in on it for our Drupalcamp Austin site and so we've got a great grunt file with a bunch of docs and also in the back there is Ian who is the mastermind behind all this so I may just like punt it to him if anybody's got like really advanced questions about grunt watch but the grunt file has all these built into it so jshint ugify which minifies your javascript then you can concatenate things into different builds you can minify your images you can run compass you can run live reload you can run jekyll and you can even have flags that do dev and prod build modes for this kind of stuff which is pretty awesome so if you want to build your javascript differently when you're developing or not minify it when you're developing and then minify it in your production you can have all of this stuff running through grunt no problemo any more questions about grunt watch grunt in general cool so performance testing this is a hot topic because like I said if you want to build a fast site you've got to start out by building a fast site instead of just trying to tack it on at the end that will not work as well as we all want it to even though it would be great if it did so everyone's familiar with yslow right everyone's used yslow we've all used yslow that's awesome so yslow is that service the grades front end performance for you and then there are many best practices that are checked here and you get a grade so it delivers a through f I don't know if that's a common grading system but it is common to us pupils historically you had to go to each web page that you wanted to test in yslow but that is boring and tedious so you can capture the data that you need to perform analysis via yslow very easily using phantom so phantom comes with a net sniff .js or net sniff .coffee if that's your thing to allow you to generate har files har I don't even remember what it stands for but it's basically when you look at a network waterfall that is not going to show up here but this network tab basically is what you're looking at when the har is a JSON file that this is visualizing and so you can install the yslow node module and basically get a readout of this thing so I'm going to take this example here this is what you get for there we go I think that's the end of it perfect oh man that's some wacky reveal stuff happening so I'm going to run this command and it's a little big but I'll talk about each piece here before we do it oh actually here it's at the top now at the beginning cut off here is phantom .js that's all it says and then we're going to this isn't going to work in this directory so hold on okay cool so now I'm going to run phantom.js in the examples folder of phantom and it's going to use the net sniff and it's going to look up forkitchens.com which is my employer's website and then the pipe means that it's going to pipe it to yslow and then I've told it to grade me and give it in a plain format so it's going to look pretty in the console right so I'm going to hit enter there's a delay because what it's doing is it's requesting the website and it's pulling down this JSON and then it's grading everything and it's running this node module on the thing here so actually this is like too much information for the screen but here's the basic stuff here and broken out you can see oh we're not using a CDN so we got an F but and this is a terrible conference Wi-Fi and well actually it's not that terrible I take that back conference since this is being recorded so it's actually being pretty good but it's not the it's not the number I want to see when I'm like checking this stuff which is a footnote that I'll get to in a second you can see here that it says that our website is 512k hooray and the overall score is a B which is really not that bad B is for not that bad and then the RL the number of requests that we incurred when we were doing this the RL set and then like the number of milliseconds that it took for the page to load now off the top of my head I don't know if this is the content DOM loaded event or the uh or DOM content loaded and or the page on load which comes much later in the stack especially if you're doing things right but basically you can get this basic information and um if you hook this up to Jenkins and you like push a branch to GitHub and then the WISO comes back and emails you and says like hey by the way I added 1200 milliseconds to your page load time you know that you're not done working because you need to unbreak whatever you broke while you were working unless of course your goal was to add a carousel to your home page and then you've done what you meant to do so that's uh WISO in a nutshell um and then also there are other versions of this um you can do WISO for Phantom um and this is the exact same command in a different syntax actually it's not as it says example.com but you do need to watch out for uh these tools because due to the way they're built you can find significant differences between the tools and so like one test is never good enough um like to get a good margin of error sometimes I'll run like 10 of them just to see what the average is for all of them and I don't have a way of like scripting all that together but you can at least look and see like is there a problem with our Wi-Fi right now or something like that um a lot of these tools aren't going to be handy for local development you want to do this on some sort of staging QA server right so that you're using the real internet with latency involved and all that kind of stuff so does anybody have any questions about WISO cool total experts I like this all right what's up the question was I put the URL the the particular URL is it going to scan the whole website or just one page and the answer is one page it'll just scan the URL that you provide so if you wanted to do this multiple times you'd have to set up the command multiple times and do it for slash about slash team you know slash subscriptions or whatever um but if you put this into a script it's really not that bad and this in particular is very low power like it's not going to pound your server to do this and if you had like 10 URLs you wanted to check no problem it does it in just a second another question is there an equivalent for google page speed automating page speed yeah yeah thank you that was totally unplanned by the way so not to be outdone by yahoo google has a competing service called page speed insights um depending on how you feel about google and yahoo and all that um you might find this one to be more interesting right so it can also be automated by getting an API key um uh and then you can also sign up for their service which right now is free but you have to sign up for a waiting list and they say that this is going to become a paid service so um using the API may suit you better if you don't want to incur a subscription cost later on at some unplanned date but they are being forthcoming about saying that yes this is going to turn into a paid service once we've hammered out all the kinks and we feel really good about offering it um so yes uh google can do the exact same thing um they don't use the letter grading system um they just use a bunch of numbers and they score it uh out of a hundred I think each way or each facet so uh the page speed API is documented quite thoroughly but there's also a grunt plugin for this um so if you were developing on a remote server um you can have this set up to run when you uh like for example like I use sublime so I have to have the files locally and then like when I want to show something on a remote server I have to ftp it up automatically right well you could like put a delay in there and then have your computer do the page speed lookup or the weisel lookup on your remote server as you're developing so everything stays in sync um but grunt's page speed is basically the same thing here um we're going to back out of that one go to page speed so we're in examples grunt page speed in the repo uh that's on the triple con site and so I've already done npm install but I'm just going to run grunt and this is set up to grade4kitchens.com once again and so it's running the task and unlike watch this is a discrete command that you have to run at a moments notice now you could set it up with grunt watch that's totally doable but as I have it here it's just a command that I run you can see that my shell is returned at the bottom of the screen and we're back at the prompt you can see this is a shell because I actually have a shell I'm so proud of my emoji um so here's the uh the results of the page speed desktop task now you're probably thinking in your head Chris don't you aren't you a proponent of not using those types of words well in this case I have to because page speed has two modes desktop mobile so that's their decision not mine and so the grunt plugin basically can do both of them and it's just a matter of configuring it and I can show the grunt file in a second if anyone's interested or afterwards if not too many people are interested um so basically it said here's your url your score is 84 greatness a little harder you can see the green on the side because I set a threshold of 80 so for kitchens.com it says us strategy is desktop and the threshold the score that we're looking for is 80 um you can see here that mobile is set up exactly the same with the same threshold but the strategy is mobile hooray so excuse me um it shows the number of resources the number of hosts that are pulling this stuff um see it complained about CDNs earlier but we are kind of using a CDN um the total request in bytes and all this sort of response time stuff and you can look at these and make sure that your numbers aren't changing or going up too far and all that kind of stuff uh the number of files that you're loading and so forth and so this is great then it tells you a bunch of other more advanced stuff that is when I start tugging on the shoulder of someone at my job and say like how do we do gzip compression um so you want to avoid redirecting and it'll tell you how many times you've redirected because if you're using m dots or anything like that um and um you know leveraging browser caching and all these advanced features right so um these are numbers that you can get out of the page speed plugin and then what I'm going to do here is I'm going to run page speed colon mobile which is uh if you saw up here running page speed colon desktop that's the um what's called the default task in grunt and so it does page speed here and then since desktop is the first thing inside page speed it just picks desktop if I were to move these it would load mobile um instead of desktop when I just ran grunt so now um whoops there we go grunt page speed mobile it's doing the exact same thing although it's simulating a mobile phone this time and look at that it's red so because the threshold is still 80 and I got an overall score of 89 you can see that um it's saying that hey you've kind of fallen below your absolute threshold so you could have this thing basically alert you whenever you fall below a particular threshold rather than having to check it manually every time and same numbers are here it's just done in a different way and it has like a little stricter requirements for this type of stuff because it knows that mobile phones have smaller cache files and that kind of thing so uh that's all good and um and and uh that's basically page speed uh in a nutshell any questions about page speed nap cool um this one is also really awesome CSS regression testing so like I said in the beginning you can uh nudge CSS around really easily because CSS has no scope and so you know sometimes you're just like whoa someone messed up the CSS that's impossible um so CSS can be knocked out of place really easily and we need to prevent this so enter Wraith Wraith is a tool from BBC News and it's open source and what it allows you to do is leverage Phantom or Slimer your choice to take screenshots of two different environments producing a visual diff of those two screenshots holy cow alright so we've got an example here of BBC News and you can see all this blue on the page is stuff that changed just a little and so someone like nudged it out of place or maybe increased the font size a little and it starts to just go haywire basically and this is a super cool thing and then also there's that little blue circle at the top I think someone like added an icon or something like does this work oh yeah there we go um so that's Wraith let's uh do a really quick Wraith uh check here so I'm gonna install it and then we're going to run the default Wraith um so and yeah it's all there so we're gonna run Wraith which is this is a Ruby tool and so this is the command that runs the tool that we're using so what it's doing is it's looking up I believe like BBC Russian and BBC UK and it's checking the slash path so it's checking home and I guess I'll talk a little slower because sometimes this takes a while and you can see it says it's doing width 320 and now it's gonna do 600, 720, 1024, a couple different options here and it's literally loading up the web page resizing the window taking a full screenshot of it saving it to disk and then doing the other domain as well and it's setting all those together and it's putting them aside so what it's gonna do is it's gonna run a diff just like a code diff but it's a diff on the images themselves and it's gonna show us those changes that were introduced between the two domains this one can actually run behind HTTP auth so if you have a really informal user pass on your dev environments and it prompts you to enter the user pass before you hit your dev environment you can actually include that by just saying like HTTP colon slash slash user colon name at my dev domain dot whatever oh now it's doing another one hooray I should have made the config file shorter but basically it's running through all these configs that are sitting there and then at the end it's gonna give us a web page basically formatted web page like we're getting a little too much for our money here which is none so whenever someone comes into a queue and it's kind of cranky at me I learned from I believe I heard this from Gregels originally but just tell them hey you're getting what you paid for but in this case we really are so we're almost done here we got two more 1280s to go and we're gonna see the results which are awesome does anybody have any questions about this while it's finishing up is it just a visual output or do you get some sort of mathematical 99% difference right now as the tool works it just gives you visual output and it crops them and puts thumbnails on this gallery page but I haven't dug into the code deeply but I feel like you could probably produce those numbers if you altered the tool or something like that so saving here it's almost done any other questions alright here we go shots gallery alright so here's the difference this is actually huge it's a lot bigger than it was last time but you get the point so we just did this dynamically and you can see that because I've got this huge cookie prompt at the top it makes it kind of useless but you can run this I think it would be possible to run it with no JS no JavaScript is what I mean but you can see that it labels them all with resolutions and then it moves on to the UK index page here and so you can set up many different config files and these are actually pretty simple so if I show the Wraith configs and actually as I was messing with this I found that it had a config bug which they've actually fixed now so you can run multiple configs they say rake, config, whatever and just run one of them so basically it will put it in the shots here you put your domains right here you tell your screen widths what you want and then paths also so very simple syntax and it does the rest for you very very simple for the people in the back is this something you tend to use for say comparing a local environment to a stage? yeah so the first time I used this it was incredibly useful because we were on crunch for two or three weeks I was just like oh IE8 I'm not going to test it it was a responsive site and I did a bunch of bad things right and so then came time to actually fixing that and so I was like okay let's fix the IE8 problems I made sure that I was fixing them but what I did at the same time was that I ran Wraith after I was done and I produced a zero byte diff on all of my webkit screenshots to confirm that I had not created any regressions while I was doing the IE fixes so the IE fixes had to be done manually in browser scope and VMs and stuff like that but yes you can basically confirm a lot of times what you're confirming is that you're not changing anything so Alan to answer your question a second ago it does tell you the numbers here in bytes but there's no percentage but you can actually like grep through this page that it generates and find that you if it says anything other than zero bytes you know you got a little work to do so you can automate that even further I suppose although I don't have it set up right now but that is something you could also do with phantom because you could look this web page up locally on your hard drive load it with phantom look for these zero byte strings the actual string of zero bytes and that kind of thing does that answer your question mostly cool awesome yeah that's an interesting question was could you use this for design qa getting screenshots from a psd I assume or something like that and then comparing your web output to a static like image that was generated before I don't know if that would be easy to do immediately but you could run through the diff code and I'll bet that that could be a possibility so yes it's technically possible but it's not a feature of this tool right at the moment out of the box but that's a very interesting point well okay so yeah that's also a good point you could put a jpeg of your site up on the website somewhere and then do that type of a diff so yeah that'd be an easy kind of like work around for not changing the tool but just getting a url out of the thing yeah and then also they're working on doing slimer versus phantom comparisons so you load up the same url the same path you're not changing any of those so you're not changing dev environments but what you're changing is the engine which is rendering the web page so you can see differences between slimer and gecko or sorry phantom and slimer which are webkit and gecko you can kind of see the differences between those two I personally am not too worried about that type of thing because it is the web and you've got to like embrace the squishiness and the diversity of everything but still it's something that you want to know sometimes so you might want to compare the two engines any other questions IE IE can't do this you just need a more modern stack that like so the part of the reason is because it's not open source so both phantom and slimer are only possible because the engines themselves are open source and you can fork them and do with them what you want and so that's a that's just how it is but basically Wraith can do all this stuff and if there were ever an IE engine that were produced that like a tool that were to produce this way I'm sure someone would immediately add it to the stack because it would be certainly useful we already talked about this but this is the syntax for multiple configs so yeah I said at the beginning I wouldn't talk about Jenkins at all really and I'm not going to show you how to do this but we do have a blog post up here that illustrates the general concepts needed to automate all this stuff so basically what you're doing is you're combining git hooks and some sort of CI server of your choice so I'm not at all opinionated about what you should or shouldn't use but you basically need those two ingredients a way to trigger things be a version control or disk IE and then a way to do something with that trigger so we use Jenkins and GitHub web hooks they're really easy and we have a blog post here that outlines specifically how you build a Jenkins job so that when you push to master it updates your trunk and while this is a fairly mundane process in terms of CI it does have all the ingredients necessary to get you up and running with your first Jenkins job so I included this just so you'd have somewhere to start if you weren't as familiar with Jenkins and then you can go from there and basically read on your own but by no means even an expert at that so whenever I do Jenkins stuff I have a lot of help from my colleagues and all that kind of stuff but basically you push to a repo it sends a message to your CI server and says hey I've got some new stuff and the CI server says cool I'm going to do something with the new stuff and you're done so in general we have any general questions am I good on time yeah ok cool oh gotcha because this is the DevOps track I'm going to read you some information Drupal.org infrastructure team responsible for all infrastructure for the Drupal project including Drupal.org and all the subsites is looking for help they have too many tasks to deal with and are looking to bring new people on to the team they have a community conversation this Thursday 1pm 13 in room 225 if you're interested come and see how you can help and the URL that I am going to show you is Lee, whoops oh man now I've done it infra team I think I did that right yeah so if anyone's interested in helping out Drupal.org sorry I don't understand are you talking about the large URL underneath it yeah ok cool man so does anybody have any other questions or suggestions no oh really that means I did terrible if no one has questions that makes me feel bad are you integrating any sort of commercial services as both of these open source tools so Slavs or any other speed would be the one thing that's potentially commercial that you might rely on but like I said the grunt plugin just reuses the API and you sign up for a free key it took me two minutes to log into Google and like turn the key on generate it I kind of skipped this part but the grunt file actually has a key thing here which I just basically said read the file out of my file system and so I don't have to stack in my key into the open source repo that I'm hosting and basically then you have 25,000 requests a day but if there were other commercial services that were worth it I would and one that comes to mind is browser stack they have automated Selenium testing or something like that so if you do want to do some of this stuff with IE browser stack might be the option now oftentimes like I haven't had the real need to do like serious like you know weeks worth of in order to like get something right but if I did have to do that I might take a couple days and like go and figure out Selenium on browser stack it's browserstack.com and it's a cool service if you've never used it for QA and stuff we had a question oh he's going to the mic awesome can you mix all these things between scripts in the stuff and phantom test with gaspar or something like that you can mix all these yeah you can totally mix all these so another one that was mentioned just now is Casper and Casper is like an API on top of phantom cause Casper is another phantom and all these tools are built on each other there's another one called phantom CSS which I was initially interested in but Wraith gets you what you want with slightly less trouble in my experience although I have had someone tell me that I was crazy because they found it dead simple to set up phantom CSS so I'm not actually making a claim here but I'm just saying in my experience I found one easy and one hard I picked one based on that basically but yeah by all means mix these together phantom uses require natively now require js and so what that means is that you can load other modules other javascript modules which I'm talking about AMD modules in that case so I think in front of now but basically you can add in other libraries and integrate them and mash them up and do all that kind of stuff totally possible did I see one more hand back there on the other side nope ah web page test what do I think about web page test in like the last talk I gave in Munich last year I advertised it it's good I think it's a great service web page test is good in that you can get our files you can get waterfalls out of the data and also it lets you truly test geographic locations which is fantastic so you can say I want an iPhone 3G from Syria or something like that you know you can just like pick a location or I want to test some sort of like Nexus device from actual Korea you know and so you can do all these tests and with and web page test is a really great tool I'm not up on the level automation that's possible with those but it is a great tool to look into and then actually you can just scan my github which was a link at the beginning of this presentation and there's some slides called front end per for high performance theming or something like that that have a bunch of information about both web page tests and blaze.io which was the mobile version that I acquired so whoops so any other questions cool one last thing here I think this is the right URL no it's not there that's the right URL so here we can do the big thing again so if you could please help me and the Drupal Association out by rating this session it helps me make better presentations and I want to hear like when I was too boring when I was inaccurate about something when I offended you all that kind of thing actually definitely when I offended you so if you could just go to this URL it's j.mp-dcp-fops it's really easy to rate the sessions on Drupal.org and that will take you straight to the page if you're logged in and other than that thank you for coming and I hope you enjoyed it