 So let's go ahead and get started. I know that there's probably some people still having their lunches and coming in. My name is Preston So. I have been a Drupal developer since 2007. I am development manager at Acquia Labs, which is a new initiative at Acquia. And I'm also co-founder of the Southern Colorado Drupal user group. If you actually go to my website, it's not going to show up with anything because I'm currently upgrading it to Drupal 8. So you've been warned. So just to get a feel for everyone who's here today, how many of you are front-end developers? Oh, wow. All right, a lot of people. So a lot of this information might be kind of old hat. I'm hoping that this presentation will be a very comprehensive look at a lot of different possible tools that you can use and integrate into your workflows. And hopefully maybe even sprinkle in some Drupal as well. How many of you are Drupal developers? Oh, OK, great. So everybody as well. All right, so we've got a great Venn diagram here. It's awesome. That's like a complete circle. So let me just outline just a little bit what we're going to talk about today. First thing I want to do is I want to motivate front-end ops. Talk about what is front-end ops and why do we even care about it? Where did the term come from? What's it about? And then I'll dig into some of the more technical aspects of it, such as scaffolding and declaring dependencies, things like task automation, grunt and gulp. And as I'm sure many of you have heard of, I also want to talk a little bit about visual regressions and rendering and testing those sorts of problems that might arise from what you're doing. And then finally, I want to open it up hopefully at the very end if we have some time for some discussion about some of the tools that we use and what people like to use in their workflows and how we can get a lot of this high brain of interesting ideas from this audience. So let's go ahead and get started. Why ops? The really key thing about automating your tasks and automating your workflow is that automation engenders consistency. What does that mean? It means that any time you run a task or any time you do something, it's always going to be the same no matter what. And this is a very key point because oftentimes back in the day, back in the 90s or in the early 2000s, we didn't have any of these tools. And putting in a typo in your JavaScript or putting in a typo in your CSS would be something that's very hard to catch. And we have a lot of tools now available that help us to alleviate the impact of those problems. Why ops? Well, also we can begin to develop iteratively. What that means is that a lot of us have switched over to an agile workflow, to an agile approach to working on code. And what that means is we can actually begin to repetitively go through and figure out what are the best ways to actually create a process rather than just a project. And I'll talk a little bit more about that in a few minutes. So a lot of you have probably heard of the term DevOps. DevOps is really the sort of back end analog to front end ops. And the whole idea of front end ops really came about from the idea of bringing DevOps to the front end, bringing more automation at the front end. Obviously, we're very familiar with things like Jenkins and Travis CI. All these things are things that help us to alleviate a lot of the pain that we suffer from having to have built tasks and deploy our code. So nowadays, with the rapidly accelerating front end innovation that's going on in the web development space, a lot of the tasks that we have been asked to do as front end developers can be better served with automation. In the past, we only had to worry about a couple of assets, let's say, maybe an HTML file or some CSS files, maybe some JavaScript, if you're lucky. But today, we have a lot of new abstractions and frameworks that really change the way that we work. We have things like CSS preprocessors. We have things like aggregated JavaScript. Things that we really have to care about when it comes to the standpoint of performance and so on and so forth. So what is front end ops exactly? Well, front end ops is a term that was first promulgated by Alex Sexton in an article in Smashing Magazine about two years ago. And basically, he noticed this trend where a lot of application logic that was formerly on the server side is being moved over to the client side. And we've noticed that, I think, I'll just alluded to it briefly in the keynote with this trend toward client side apps and decoupled Drupal. And the key difference between front end development, which is what we all do on a daily basis, and front end ops is the emphasis on process. And the way I like to say it is that front end ops is about process. It's not about the project. When you're actually working on your front end ops workflow, it's really not at all about the end result of your product. It's the end result of your process. It's the end result of what kind of workflow you end up with. So as Sexton says, he says there's not too much work for front end developers to really do this on their own. There has to be some sort of automation that takes place in order to really reduce the amount of time that we're spending doing a lot of this work. So having a focus on operations yields a much more iterative workflow. It means that we can do things a lot faster. It means that we can test things a lot faster and do a lot of these things in a very efficient way. As Chris Ruppel says, and he's probably here somewhere at DrupalCon, front end ops is how to automate the process of breaking things. When you introduce a bug accidentally in your CSS, or in your JavaScript, you really want to be able to catch that immediately. You don't want to have to dig through a thousand lines of code to figure out what exactly is going on. So before, the front end workflow looked something like this. We had a very traditional sort of, maybe we download Drupal, we have a basic directory structure, and it's pretty easy to manage because Drupal, at least before Drupal 7, let's say, was actually pretty small. If you look at Drupal 8 now, obviously it's kind of a huge crazy directory structure that demands a lot more automation. You might add a few dependencies, things like jQuery, which is in core. You might want to have some other dependencies that you're working with. And then you might edit a few files, you might change some lines of code, you upload it, and there's your site. So today we have a lot of things that we've been tasked with nowadays. Things like scaffolding is something that actually might be very complicated because your application architecture or your site architecture might be very, very complex. Things like downloading libraries and frameworks, how do you actually keep all of your dependencies up to date? How do you keep your jQuery version up to the most current stable version? Things like SAS and Compass, which are CSS preprocessors, how do you actually manage all of the CSS files that you have and turn your partials into a sort of comprehensive CSS file? And obviously coding standards is very important, especially on a large team. If you have a team of five to 10 people or even more people, you really want to enforce certain standards that will make a lot of sense and ensure that people don't introduce a lot of mistakes. Finally, you've got test suites and debugging tools. These can all be integrated into your front-end ops workflow. And we also have very diverse needs. I mean, we have a lot of test-driven development nowadays. We have to do a lot of unit testing. We have minification and concatenation to really improve the way that we load JavaScript. We have performance testing. We have to worry about how quickly our pages load. Display testing, really scrutinizing things like visual aggressions and changes to CSS that might impact the way your pages look. And finally, builds and deployment. You can actually integrate a lot of this work into, let's say, your Jenkins workflow or stuff like that. So this is sort of a period where we're seeing a lot of new abstractions. Every major sort of base language that we have or base markup language or base programming language that we have has an abstraction like coffee script or Hamel for HTML or SAS and lesson stylus for CSS. So more abstraction means more overhead. What this means is that if you have more team members, it means you can get really misaligned code if you have merge conflicts that are due to minor errors that could have been resolved through an automated process. Those things are things that slow you down as a team. And you really don't want to push back the progress of your project with problems like that. More front end code, of course, means more risk of error. If you have a 30 kilobyte JavaScript file, chances are you're gonna probably introduce some small bugs or some errors if you're working with that constantly, especially in a large team. And of course, more users means more drags on performance. So we need an easier way to do all these things. We need an easier way to accomplish all of these tasks. And the way that we can do that is with these tools that are available that are currently in quite wide use in the web development community. You've probably heard of these. Yeoman, which is really good for app scaffolding, if you wanna scaffold your directory structure. What I mean by that is you actually introduce a generator that will produce the directory structure and all the files that you need to begin working on your project in a very, very efficient and quick manner. Instead of having to go through and declare all of your, and create new files and create new folders, Yeoman can do all that for you. Bower is a very, very good tool for dependency management. It's a way to allow you to really introspect and update all of your dependencies in a very, very clear and sort of a constant manner. Grunt and Gulp are really about task automation. So they're task owners that help you accomplish things that you really don't wanna do on your own or that is really gonna slow you down from a development standpoint. When you're developing, you really don't wanna worry about things like aggregation. You really don't wanna worry about things like CSS preprocessing. You want all of that to be done for you. So according to Adios Moni, who's one of those sort of big proponents of front-end ops, the new workflow helps us because we can customize our setups. And what this means is that we can actually go in and configure the way that we want our ops workflow to work. We can limit the time that we spend writing boilerplate code. We can limit the time that we spend writing our .info files or .info.yaml, in the case of Drupal 8. And we can also improve our productivity and delight during development. And that's the whole goal, right? We wanna have fun. We wanna be able to do things that we enjoy and not worry about the hard stuff. Or at least the boring stuff, right? So let's talk about yeoman first. How many of you have heard of yeoman or have used yeoman? Okay, so about half and half. So yeoman is interesting because it's actually, and this whole ecosystem of tools for front-end ops really have a lot of cross dependencies on each other. So yeoman explicitly recommends a workflow that involves Bower and Grunt or Gulp, whichever task order you choose. What you can do is you can install yeoman generators, what are called yeoman generators, and there's actually one for Drupal themes. And generators exist for a lot of different things you might wanna accomplish. So things like scaffolding an Angular app framework or an initial architecture using the Bootstrap framework or something like that. Yeoman can also scaffold portions of apps and you can actually introduce arguments into your generators that will allow you to really, really limit the amount that's actually generated and then you can do unit testing and stuff on that. So what about Bower? Well, Bower helps you find your dependencies. It actually is very good at locating your dependencies, the most updated versions of your dependencies and allowing you to introspect those. So, and you can actually determine when you want these things to happen. Bower provides a CLI command line interface to manage all your versioned and potentially obsolete dependencies that have been introduced. And so if you wanna keep your code up to date, let's say you wanna make sure your jQuery's up to date, which is kind of a moot point given that it's in core. But other JS that you might wanna introduce is something that you wanna manage with Bower. So grunt and gulp are task automators. And I'm sure, how many of you have heard of grunt or gulp or worked with either of them? Okay, great, awesome. So this is old hat for a lot of you. So grunt and gulp are task automators, which you basically introduce into your root directory a grunt file, what's known as a grunt file or a gulp file, which is basically a configuration file, which allows you to determine what tasks you want those task runners to do. The grunt and gulp communities, just like the Drupal community, is very vibrant. They're both very vibrant and they have a lot of plugins that will introduce a lot of interesting commands that you can integrate into your workflow and can be very interesting to use. So grunt and gulp together are not, sorry, not together, grunt or gulp reduces the time for you to get your code to the deliverable state. For your code to be shipable, grunt and gulp can help you get there very quickly. So just a side note from a sort of human perspective, we're talking about roles and responsibilities here where a lot of the stuff that we're working on with front end ops has really shifted. Sexton, for example, poses this new front end operations engineer role. I think you can also call this maybe a front end performance engineer role, where basically you manage the process. You don't manage the project, you don't work on the project, you actually manage and work on the process and continually improve it. In my opinion, I think that a lot of people are gonna become a lot more diversified. Chances are a lot of us in this room, even though we might be front end developers who specialize in Drupal theming or let's say in decoupled Drupal or something like that, people are gonna increasingly rely on more and more knowledge of these tools and it's very important for us to have awareness of them, even if we're maybe not as involved in the front end. So let's go ahead and get started. Well, the first thing we need is to install Node and this is a very simple step. If you have not installed Node yet, it's a very, very good runtime environment that allows for a lot of different things and we'll delve into this a little bit as well. So you also wanna have Node Package Manager and this is for people who might be coding live or wanna follow along. The way that you actually update NPM is with this command right here, it's very simple. So if we wanna install all of our dependencies, what we wanna do is we wanna do NPM install and this hyphen g flag means globally install all of these things. And so what we wanna do is yo, which is yo-man, bower, obviously, grunt CLI, which is the grunt command line interface and finally gulp. You can have all of those available in your system. So let's talk about bower first because bower is very interesting. So bower takes care of the grunt work, no pun intended, and finding, downloading, and tracking your dependencies. Bower leverages a manifest file called bower.json which contains a list of your packages. And so in order to, let's say, install a new package, all you gotta do is put in bower install jQuery and boom, you have jQuery and that's a declared dependency and you can manage it through bower. And if you ever need to update it, you can do it through bower. You can also go through and get GitHub projects or get a Git endpoint. So for example, if you really wanted to, you could get the direct clone of Drupal core from GitHub and declare that as a dependency as well and track it. And then you can also use a path. So for instance, if you want to have a, something host on your site, you've got a great little framework you've built, you can also include that as a package as well. So you can add to the manifest by using these commands. And so what you can do is bower has a very, very, very comprehensive list of various packages you might need of all the most common sorts of dependencies you might have while you're developing. And so when you do bower search, bower search is one of those commands that allows you to actually go through and look for a certain dependency. And then you can also list all of the saved dependencies that you have in your project. What about Yeoman? Well, our dependencies are all sorted out, right? So we've got all of our things settled. But what about basic scaffolding? So with Yeoman, we can actually generate a vast array, a vast diversity of different directory structures and basic initial boilerplate structures for our apps, for our architectures. So for this session, and I'll do a live demo of this shortly, we're going to generate a Drupal theme in Yeoman. And I'll show you guys, show everybody just in a second what this looks like. This is a generator built by Ian Carrico. He's a front-end engineer. And what we wanna do is we wanna install our generator and the way we do that is by using node package manager. We wanna install it globally so we can invoke it or so we can call it from anywhere. And what you wanna do is you, let's say, oh, that's a little bit out of date that's referring to the last time I gave this presentation. But you wanna create a directory and go into that directory and you can generate a Drupal theme that way. So just to show you very briefly what this looks like, I have my command line here. And what I'm gonna do is I'm gonna create a directory Barcelona 2015. Let's go into that. So right now it's empty, but if I do yo Drupal theme, what it gives me is this really nice guy. So Yeoman is this gentleman right here who is very nice and friendly and he helps you generate a Drupal theme. So what you can do is, and I think this is gonna be hard because it's off the screen, there we go. So what's your theme's name, right? This is literally is gonna give you all of the things you need for your .info file and everything you could ever want, right? So let's call our theme Barcelona 2015. And you can choose a base theme using this generator. There's various generators that you can use. I'm sure there's other generators out there for Drupal themes or you can write your own. And let's say that we wanna use Zen as our base theme. Do you wanna customize your site's directories? Well, maybe not. And then why don't we do something like introduce a Gulp file or a Grunt file or Bower components in order to see, in order to build those dependencies very quickly or to have a task runner already in place. So if I hit Gulp, what'll happen is boom, right? It's creating all of this structure, this initial structure for my Drupal theme. And okay, if this will actually run, this is why live demos are a bad idea. I should not have done this. Ha ha ha ha ha ha ha ha. Anyways, so while this is going, there we go, okay, so let's go ahead and look at my created theme, right? So if I go in and I do that, boom. I literally had to do nothing. All I had to do was type in a few commands and boom. All we have now is we have our .info file already created. We have our CSS directory, our fab icon, Gulp file.js, if you wanna run Gulp, we've got our image directory, we've got everything that we could need, including template.php, all of our templates are already there for us. And all you need to do now is to go into that directory structure, actually go in, drill down, and start editing those files. So that's a demonstration of Yeoman. So what about, so what is that package.json file that was in there as well? Well, package.json allows you to actually declare new dependencies that you might need. So they're actually development dependencies, and you can see that with the dev dependencies key there. And what this does is this says, well, you know what, this is the stuff that we need in order to perform our tasks. So if we need to declare new dependency, we can actually add it very easily to this JSON object. So if you wanna learn more about writing Yeoman generators, I highly recommend this resource, it's very good. I'm not gonna talk about it because it's a bit outside the scope of the session, but if you are interested, please feel free to take a look. So all right, what about Grunt and Gulp? Well, from the front-end developer standpoint, there is no significant difference between Grunt and Gulp. It's all about what kind of syntax you wanna use while writing it, and how you wanna architect your Gulp file or your Grunt file. I'll talk more about this later. So there's some of the paths for the plugins that you might want. There's a vast array of different plugins that you can use for Grunt as well as Gulp. So let's install a Grunt plugin, and the way that we do this is we can use npm install, and we can put in as an argument the Grunt plugin that we wanna use. And by putting in that save dev flag, we actually save it to the dev dependencies object, or the dev dependencies section of the package.json file. So we can also do, so both of these, for example, accomplish the same thing in either Grunt or Gulp. So where Grunt and Gulp differ is really the sort of difference is what your focus is when you're writing these files. Grunt is a lot more configuration focused. It's more about getting your initial state settled first before you run the tasks. Gulp is much more task execution focused, and I'll show you this in just a second here. So if you're familiar with Node.js, this might be familiar to you. This is how you export a module in Node.js normally. And what you wanna do is, this is the initial structure of your Grunt file. This is how you start out, and you wanna configure Grunt to run certain tasks for you that make your life easier. So for example, what you wanna do first is you wanna make sure that your package.json is being read, and what you also wanna do is you wanna say, hey, I wanna actually include that Uglify plugin that I installed and configure it. So then what you can do is you can tell Grunt that the plugin needs to be used. You can instruct Grunt to actually utilize that plugin, and then you can finally provide Grunt a task to register. And what that means is that Grunt will actually save the tasks that you want to run, and that's basically how it works. And within the Uglify object, basically, you can declare certain configurations that you might wanna use. In this case, you've got source, which is the source of the source files where they come from, and the destination, right? And then with our task registered, now that we've actually got this declared and we've got our Grunt file, and we've got awareness of the fact that Grunt is going to run this Uglify plugin, we can actually run Grunt from our command line. And you can also declare basically different kinds of arguments when you run Grunt that allow you to run tasks in different ways or different configurations. So you can run, let's say, two tasks, only two out of your 10 tasks, let's say, and there's a lot of really interesting things that you can do with actually specifying what you wanna run. So here's some useful Grunt plugins, I'm sure that a lot of you have probably used some of these before. Stuff like Grunt responsive images, Grunt contrib image opt-in, Grunt newer. Grunt on CSS is very interesting, it removes any CSS that's not used in your project, and I think this is something that we can all identify with as front of developers, is that oftentimes our CSS files balloon into these humongous sizes, just because we have a lot of CSS that's actually never called, because we're just declaring it, but it's never actually used. So Grunt on CSS can actually figure out which declarations are not actually being used. So Gulp is a little bit different. It still is sort of a very similar idea if you're familiar with Node.js development, you invoke require to get your Gulp, and basically what you do is you basically invoke a task method on Gulp to run your tasks, and this is where Grunt and Gulp really differ. Whereas in Grunt you have a initial configuration and then you register your tasks with Gulp, you configure and register your tasks in the same process. So what does that mean? Well, okay, first of all, we get all of our plugins so that we know what we want to have happen in Gulp, and then we might wanna set some paths to make sure that everything's in line. And this is really where Gulp is interesting if you wanna keep your code very well organized. And then what we do is we basically run a task in this case, let's call it process.js, and what this is doing here is this dot pipe is basically going through these tasks and running them. So first of all, we've got concat, which is concat nation of JavaScript, and that gives you a process.js result file in the JS path that you've declared earlier. And Aglify as well, which basically makes it so your JavaScript is totally illegible. So we can then run our command as with Grunt, it's very similar, you have your argument that actually specifies what tasks you wanna run. So one thing that I would recommend and one thing that I often do in the very little spare time that we have that I have is to really look at other people's Grunt files and Gulp files because they'll tell you a lot about what other people are doing and how their processes are influenced by incorporating Grunt and Gulp. So we can use Gulp to track changes in our theme files and automate what's tedious so we can focus on what's important. So whenever package.json or bower.json changes, you wanna run npm installer or bower install to make sure to get the most updated dependencies. That's very important. So we probably all at least heard of Grunt and Gulp, we probably worked with these tools before. Let's talk a little bit about some tools that may not be so familiar to everybody. So for example, visual regressions, who's heard of visual regressions? So I'll talk a little bit about visual regressions. One of the things that's very interesting in this front end ops kind of idea is we wanna be able to track changes that happen in terms of the visual design of our websites. If you have a page and you've got it very sort of elaborately styled, you don't want a change to happen near CSS. It's gonna totally obliterate, let's say, changes that other people have made or some slight changes in the typography. You wanna be able to track all of those things very easily. Visual regressions basically are comparisons. They're diffs, they're very much similar to like GitHub code diffs. But what you can do is you can actually introspect where on the page the differences lie. Which pixels have actually changed? And one of these, and the reason why this is important is because CSS is usually very quickly moving. CSS is very prone to errors and all sorts of problems. As we said earlier, CSS is a very sort of brittle language. It's not really meant for efficiency because you can declare a lot of CSS that's not gonna be used. You can introduce a lot of typos and stuff like that, especially if you're writing CSS very quickly. So one of the tools that I've looked at in the past and which is very interesting from the standpoint of visual regressions is Wraith. So Wraith uses a PhantomJS or SlimerJS to basically snap screenshots of your pages. And so it's made by BBC News. I highly recommend that you go to this repo and check it out. What it looks like is something like this. So this is the BBC News article on a mobile device. And what you can see is that all those blue outlines are actually highlighting the areas that have changed ever since the last time you took a screenshot. So what a visual regression does is it goes through and it basically samples both screenshots for anything that has changed. Any differences in color, any differences that are noted and then it actually highlights them in this manner. So if you wanna install Wraith, it's a Ruby gem so you just gem install Wraith. And then you use actually YAML to configure Wraith. So if you're familiar with things like the way configuration management works in triple eight or just YAML in general and how that works, it's very easy to actually get this going. And then you can call, you can use WraithCapture and use that YAML file as an argument in order to get your captured screenshots. So Huxley is an alternative visual regression tool. It's built by Facebook and Instagram. It's currently not supported by either organization. They actually recommend that you fork it if you're interested in working on it. It's also a very, very good tool. So what's really cool about Huxley is, and this is a direct quote from their GitHub repo, is it watches you browse, it takes screenshots and it tells you when they change. It's a much more sort of dynamic approach. So Huxley, just like, let's say, with your grunt files and your Gulp files, you can use a Huxley file to configure the URLs to be tested. So this is part of a sort of theme that is across the entire front of the ops presentation, right, is you basically configure everything you want to have happen in these files that are unified. And basically within the command line, you run these tasks and you run these commands that will basically get those files and run through the configurations and yield what you want. So Huxley generates these .huxley files, which are records of your tests, and you can actually track those changes within those .huxley files. And it's literally gonna be, so let's say you have index.html, if you run Huxley, it will actually give you an index.huxley file. And what's really interesting about this approach is that this .huxley file can actually be checked into a repo. And if you have a repository that you're tracking all of these different changes going on, Huxley gives you a very good introspective way to basically look at the history of your visual changes. That's very interesting. I mean, it's basically like what GitHub already does, but for visual design, which is pretty cool. So what you can do is you can use the flag record to start recording, and basically it's sort of a constantly running thing. You hit enter, just take a screenshot, and then queue to quit, very easy. So Fam.css is also another visual regression tool. As you can tell, there's a lot of different options that are out there for you. And it's really meant for web apps, lifestyle guides, and responsive layouts. If you're interested in sort of CSS testing and visual regressions, I highly recommend you check out these two resources. So we've talked about testing visual regressions. We've talked about noticing visual regressions, right? But that doesn't really help us in terms of actually doing it across devices, right? The only thing that visual regressions actually help us with is to find a single page on, let's say, your Chrome browser and give you a diff between those things. What if we want to actually figure out differences between things like WebKit versus Gecko or basically rendering engines and how those differ in terms of their approach and their display of your front end? So the big question is, how can we test rendering engines more quickly without waiting for page loads on each browser? And there's this whole concept called Headless Browser. How many of you have heard of Headless Browsers? So what a Headless Browser is is basically it allows you to basically perform tests in a browser, but you never have to look at the browser, right? There is no UI. There is no sort of front end that you see because it's all happening on a back end. That's not visible to you. So we can use Headless instances of rendering engines to actually render our pages without displaying them and then get those results back from those renderings. What this means is that we no longer have to open up 15 different browsers, as we used to do in the 90s or the early 2000s, to actually test all these things. You don't have to use browser shots anymore, stuff like that. So Phantom.js is the actual testing tool for WebKit. If you want it to, it can not be Headless. You can spit out some visual pages. It's very useful for batch actions in particular. If you want to do multiple actions on a single page, let's say, Phantom.js.org, that's what it looks like. So whoops, whoops, whoops, uh-oh. Okay, well, sorry about that. That's never happened before. This is why PowerPoint's bad. All right. All right. Let's see here. Should have used Reveal.js. Anyways, so Slimeware.js is actually the equivalent that you use for Gecko, Slimeware.js.org. And Casper.js gives you a lot more interaction, interactability, so if you have a Headless instance of your browser of your rendering engine, you can actually perform certain tasks with it, like filling out forms, clicking links, and you can also do things like logging and scraping. So great, testing rendering engines, that's great. I mean, so we've moved from testing visual aggressions, which are just differences between actual different displays of the same page on a single rendering engine. We've moved on to testing rendering engines and testing those diffs, which means that we can actually go in and interact with these things in very different ways, depending on the rendering engine itself and differentiate between rendering engines. But there's still something missing. We also want to actually be able to test devices too, because you can have two devices using the same rendering engine, but they're not gonna look the same. You might have a mobile device, and you might have a tablet or something like that, or a desktop. You wanna be able to introspect the differences that occur between those particular devices. So one of the best tools that I know of for testing devices and differences between devices is GhostLab. And the really compelling thing about GhostLab, the real sort of unique value proposition of GhostLab, is you can conduct synchronized testing on diverse types of devices. So about a year ago, I did some testing using GhostLab, and it's actually fascinating, because what you can do is you set it up so your devices are synchronized, and you have your, let's say your mobile phone, your, let's say, your Galaxy Note, and you have your iPhone, and you have your desktop, right? What you can do is you can scroll on your iPhone, or scroll on your Samsung Galaxy Note, and all of those, all the actions you perform are replicated across all those devices at the same time. So you can simultaneously test your frontend on all these devices without having to do anything other than set up GhostLab. It's a really good idea, because what you can do is have your desktop set up, scroll, and then as you're scrolling your desktop, the same thing happens on your phone and your tablet, or what have you. Obviously, we've got other device simulators that are available, things like XCodes iOS Simulator, which I'm sure a lot of you have used. It is a very compelling idea, though, to be able to sort of do this cross-device testing and have it occur simultaneously. So GhostLab, as I mentioned, allows you to synchronize navigation across all your devices. You can synchronize things like taps, clicks, and scrolls, and other really sort of important user interactions that might occur. So what about stuff like debugging tools and things like that? We've talked a lot about actual tools that allow us to really look in and get insight into the way that our frontend looks on a variety of different situations. We've moved from talking about setting up a frontend with Yeoman, we've moved on to setting up our dependencies with Bower, we've talked about running tasks on that frontend with Grunt and Gulp, and then we've moved on to talking about actually comparing differences between devices and rendering engines. But what about debugging tools? Well, there's a feature in Chrome called DevTools Remote Debugging, which is actually really, really cool because back in the day, probably even three or four years ago, it was completely impossible to do inspect element or use Firebug, let's say, on your iPhone or on your mobile device. If you're an Android user and you wanna test on Android, this makes this very easy. So what you do is you can set up DevTools Remote Debugging on your Chrome browser, you hook up your phone to your USB on your computer, and literally what you can do is you have your inspect element window in Chrome that is referring to your device. And what you can do is if you go into the DOM, and I should have really done a live demo of this because it's really compelling, but if you have a, you can go into your DOM using that inspect element tool and actually hover over the various elements in the DOM and those will highlight on your phone. It's really cool. And it's one of the most interesting things that has come out, in my opinion, from Chrome DevTools. So Chrome DevTools also allows you to audit your CSS, just like our Grunt or Gulp on CSS plugins. And DevTools Terminal gives you a shell within Chrome, which is really compelling as well. So at this point, we've got a little bit of time left. I just wanna open it up for discussion because I think a lot of us are very intimately familiar with a lot of these tools, or maybe just a few, or maybe just one. I'm sure that many of you have used some of these tools in your projects, and I hope this is a very comprehensive introduction to a lot of the tools that maybe you might not have heard of so much. And so I wanna open it up a little bit for some discussion because I think it's very compelling from the standpoint of the future of frontend. For example, what is the future of frontend development with the advent of frontend ops? What is, how does our role change as frontend developers and what does that mean for our jobs? How will development workflows change through the frontend ops? Namely, what kinds of things are gonna happen when we have code handovers and things like that? What sorts of, how does this impact things like onboarding? I think one of the big challenges that frontend ops, the whole concept of frontend ops has not necessarily really nailed down is the idea of really efficient onboarding. Because there's a lot of developers who might be very used to a very particular way of organizing things like their Gulp files or approaching problems in very particular ways. And we have to be very attentive to what that means for introducing new team members to our ops workflow and things like that. And finally, what will frontend workflows look like one year from now, five years from now? My theory on this is that it's going to be a lot more automation. We're gonna have much, much more of our frontends be automated. I think that this is only the beginning. This is just sort of the first initial steps of what's gonna become a very burgeoning trend. So five years from now, I have no idea what it's gonna look like and I'm curious to see what your thoughts are. So if you are a little bit less familiar with frontend ops and you wanna learn a little more, here's some really great resources. I highly recommend Chris RuPaul's presentation, Intro to Frontend Ops, which covers a lot of the same material in some detail. I also really encourage you to read Alex Sexton's original article in Smashing Magazine. And the reason why is because it's a really good sort of philosophical motivation for why we need things like frontend ops engineers and why we need a frontend ops workflow to begin with. And then there are some other things that are very good as well. Automating workflow and this article from Chris Collier of CSS Tricks called Grunt for People, who think things like grunt and gulp are grunt, are weird and hard. And I also wanna do one shout out as well. So Amitai is doing a presentation, I believe, today or tomorrow, I can't remember exactly. Thursday, thank you. Thanks, Jean-Paul. So I highly encourage you to check that out because he will probably go into much more detail about tools like Wraith and Phantom CSS and stuff that we really don't have time to talk about in this session. And with that, I'd love to hear your thoughts about how this session was. And I definitely welcome your feedback. It's very helpful for me. And thank you very much. So there's a mic over there on the side if we wanna have any questions. But if not, I'm also happy to stay up here for a little bit. And I'm interested to hear your thoughts. What do you guys think is the future of frontend, especially in terms of frontend ops? Sure. So I think one of the really challenge, well, okay, so let me repeat the question. So the question is, a lot of these tools, we have a very wide range of tools, grunt, gulp, bower, yada, yada, yada. That's a lot to deal with. Why don't we just use NPM to actually perform the frontend ops task that we need? I think the big challenge is that a lot of people are not as familiar with NPM. And a lot of people are really looking for a sort of single tool that accomplishes, let's say a single need. I've met a lot of frontend developers who really only need gulp or only need bower or only need certain things. And if you're really interested in sort of building your own frontend ops workflow, I think NPM is a really good route. But I need to investigate that as well. So thank you. Yes, yes, could you repeat the question, sorry? Sure, absolutely. So the question is, is there a very easy way to automate a lot of the testing processes by using something like Selenium? A lot of the tools that I've mentioned here actually have Selenium integrations very tightly wrapped up, so if you want to use Selenium and leverage that, you certainly can. In terms of actually bundling tests, it's certainly very possible. I've seen a lot of grunt and gulp files that actually do that. And it's a very easy thing to do. And obviously, I probably need to know a little bit more about sort of the sort of projects you're looking to make, but it's definitely not a challenge. Yeah, all righty. Well, yes, please. So by containerization, you mean like Docker? OK, well, so the question was, is there a way to basically merge containerization and automation? I actually am not as familiar with Docker or containerization as I would like. Maybe someone has some insight into that? Very good question. Yes, so the question is, which one do I prefer, grunt or gulp? So personally, I really prefer gulp. And the main reason why I prefer gulp is because it's a lot more legible. It's a lot more readable. If you're really, and I mentioned earlier that there's a big concern about onboarding new team members. And I think that's very important from the standpoint of readability. Managing change and managing your release management and change management based on very sort of rapidly shifting teams is something that's very, very hard to manage. And I think for a lot of people, gulp is a lot easier to wrap your head around. One thing that I've found is people who are very gung-ho about one or the other are very, very sort of adamant about those. I don't really have a sort of really strong preference, but I do think that gulp is sort of, at least at this point, in my experience, and please feel free to jump in. But I do see gulp being used a lot more these days. And that's also another reason to adopt gulp. Great. Well, thank you very much for the amazing questions. I will stick around for a few minutes. Oh, yes, one more right there. Sure, thanks. Hi. So I noticed the problem that with device testing on the website that we developed, somehow I always managed to skip a specific resolution and viewport with tools like Browser Sync or Ghost Lab, which you mentioned. I use Browser Sync personally, but I have to have a bunch of devices. So I'm using Chrome and there, I don't know what it's called, to simulate devices. Emulator, yeah. So somehow that's the part of front-end-ups that's constantly lacking behind on the support with new devices all the time being introduced and constant differences with browser renderings. And that's something that I'm not sure if we've resolved at the moment. And do you think that's the part that someone needs to improve or? Very good question. I think while there is a lot of focus on things like configuration, you saw that tools like Rafe use YAML, it's very important to organize these various properties, stuff like viewport sets or whatever you want to test. I think there needs to be a movement toward building a lot more of that configuration in easily packaged ways. And one of the ways that I think the front-end-ups world needs to change is that it needs to go much more toward this direction. They can take a lot of inspiration from the configuration management improvements or the new ideas of configuration management in Drupal 8, which is that you want to be able to have a very easily exportable set of configurations in your YAML file or, let's say, whatever thing you want to use that can be exported to any front-end that you might have. And that will actually improve the situation that you're talking about with the rampant growth of various kinds of devices and new kinds of things like new standard viewport sizes and stuff like that. I think that this is an area that needs some improvement. OK, thanks. Yes, please. I guess I'm not quite sure what you mean. So very, very good question. So the question is about basically scaffolding and task management within your Drupal instances, right? And contributing. Well, so I've had discussions with a lot of themers and people who write very front-end heavy modules. And one of the things that there's some discussion around is incorporating things like gulp files and grunt files actually into your contributed themes and modules. I think it's something that hasn't really gathered that much traction just because of how, I don't want to say reductive, but how minimalist Drupal is in terms of what it accepts and contributions, in terms of what they want things to look like. And it's certainly something that could be a bof topic, I think, that's very compelling, is this idea of introducing some new elements into things like contributed themes and modules, especially if you want to use things like Bower or Gulp files. You should be able to put those into your theme and contribute those back. And people should be able to download them and instantly jump in with their workflow already in place. I think it's tough, especially because of the fact that a lot of the approaches that people are taking these days with things like automation and scaffolding are really more focused on things like client-side frameworks, more on the JavaScript MVC side. So certainly something that also requires more discussion. Very interesting, though. All righty, well, thank you very much. And I'll stick around for just a few minutes if you want to speak with me privately. And thank you very much. Enjoy the rest of DrupalCon.