085 JSJ Huxley with Pete Hunt

Download MP3



01:10 - Pete Hunt Introduction


Next Week

Ember.js with Robin Ward


CHUCK:  Yeah, we know all about your office sharing shenanigans, Joe. JOE:  Yes. Yes, which is why I don’t turn the video on. CHUCK:  Oh. I wasn’t talking about that kind of shenanigans. JOE:  I wasn’t talking about those kinds of shenanigans either. CHUCK:  [Laughs] JOE:  You dirty-minded, man, you. CHUCK:  What can I say? I am my father’s son. JOE:  [Chuckles] [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCK:  Hey everybody and welcome to episode 85 of the JavaScript Jabber. This week on our panel, we have Jamison Dance. JAMISON:  Hello friends. CHUCK:  Joe Eames. JOE:  Hey there. CHUCK:  AJ O’Neal. I'm Charles Max Wood from DevChat.TV. And this week, we have a special guest and that’s Pete Hunt. PETE:  Hey guys. CHUCK:  You’ve been on the show before but do you want to introduce yourself again really quickly? PETE:  Sure. My name is Pete. I work at Facebook and I'm based in San Francisco. I worked kind of early on the Instagram web product. We have a small team building out just Instagram.com and everything you see there. I also have done a lot of work for Facebook’s product infrastructure team. So, figuring out kind of the way that Facebook is going to write JavaScript as a whole, everything around frontend development. That’s kind of been my gem over the past a year or two. It’s been a lot of fun. JAMISON:  So, it sounds like you're the grand viceroy of JavaScript and Facebook. PETE:  Oh, no. There's a lot of really great people there. I'm definitely not the number one guy there but we all kind of collaborate and specialize in different things. I work mostly on the Instagram web stack. So, it’s kind of picking and choosing the parts of Facebook’s massive JS infrastructure applying it to kind of a smaller, more open source-y type of stack. And then, back-porting the discoveries we’ve made back to Facebook. CHUCK:  Alright. So, we brought you on to talk about Huxley. It appears not even written in JavaScript. Do you want to explain what it is? PETE:  Sure. So, we build a lot of client-rendered stuff for Instagram specifically, kind of like UIs. So, displaying photo feeds, log in Moodles, when you want to look at somebody’s user profile, there's a couple of different widgets there. And we were a really small team when we were building that. And we found that it was pretty hard to ensure a consistent high level of quality as you're moving really fast and refactoring components around. So, you’ve been in that situation where you rewrite some CSS or some JavaScript of some unrelated component bricks. And current unit testing solutions do -- decent Java’s ensuring that your frontend logic is okay but it’s really hard to test for ‘does it feel right’ or ‘does it look right’. So, what Facebook kind of has historically relied on is manual test plans. So, whenever we make a change, we have a field that’s called the Test Plan and we say, “I click this button and it looked okay. And then I did this, and it looked okay.” And part of our code review process is reviewing those test plans. But that obviously doesn’t really work at scale. So, we needed a solution that could basically take that out [inaudible] test plan and it will give us a lot of those benefits more than in an automated way. CHUCK:  That makes sense. I find it funny that anybody in the know that pays attention to Twitter or whatever, every time they change the UI. And now I know somebody goes through it and looks at it and says, “Well, it looks right but they're going to hate us for changing the UI.” [Laughter] PETE:  Yeah. Huxley is pretty [crosstalk]… JAMISON:  Facebook is the originator of that feeling, right? I just remember every time anything changes, everybody freaks out. CHUCK:  Yeah. [Chuckles] AJ:  I just remember it changing like every three weeks. CHUCK:  It seemed like they were trying to figure some things out. It’s been pretty much the same for a while now though, hasn’t it? Facebook’s UI? PETE:  They use employees as guinea pigs for all the UI changes. So, that’s really funny. They’ll roll something out to employees and then the employees will go to the feedback group and complain about it. So, it’s something that we’re acutely aware of inside of the company as well. [Laughter] CHUCK:  So, you get to whine about it before we do, huh? PETE:  They roll it to employees and then we will see how long the employee whine lasts. And depending on that, we can figure out whether it’s just, “Oh, this is new and I don’t like it because it’s new,” or if there's actually kind of real fundamental problems with it. CHUCK:  That makes sense. Getting back to Huxley. So, the scenario that you kind of outlined that most people follow that I've used is using it to a like Selenium. And then I write my script too with Ruby and so then, what it does is it fires up a Firefox or Chrome browser and then it automatedly clicks through the links or whatever. And if it makes it to the end without exploding, then I'm in good shape. So, what this does is this is actually looking at the look and feel itself, the layout and determining whether or not it’s right. PETE:  Yeah. I can dive a little bit deeper into more specifically what it does if you're not familiar with it. But it does use WebDriver which is part of Selenium. And we inject some JavaScript into your page and it brings up a browser and it records user events. So, clicks, keystrokes are kind of the big ones and it saves them into a lock. And then, inside the console, the Huxley console, you can press a key to take a screenshot. So, what it saves is it saves all the user events and then it saves screenshots at specific times. And the idea is that if you play back those user events and take those screenshots, you can compare the screenshots and see if the look and feel has changed. There's some kind of really good benefits with building something around the look and feel and the first one is unifying the designers and the engineers. So, the Instagram team for a long time was just me and the designer working on building out this big kind of product. And the designer would tweak some CSS and I would tweak some CSS and build some JavaScript. And I may want to change a little bit of the rounding of the corner or something. And being able to bring the designer into the code review process and say, “Hey, you might not want to dive deep into this JavaScript but just look at how the UI has changed and how the interactions are working. Do you approve of this?” So, that was kind of the first big benefit that we got was we were able to multiply the productivity of our designers or at least bring them into the process. And the second thing, I think the one thing that really makes Huxley unique among other systems that do this, there have been systems that have taken screenshots before and compared them. And you mentioned Selenium and you can write a script that goes through and looks up at DOM node by an ID and clicks on it. But the key in site that we had with Huxley that I think makes it really productive is that we completely embrace change. And so, it’s a little bit less of a testing tool where your tests pass or fail. What Huxley says is something has changed. So, the default mode is basically replacing the old series of screenshots with the new ones and bringing them into your code review tool and basically saying, “Hey, are these changes okay?” And so, part of that is not requiring you to write a Selenium script that depends on your implementation of your UI. So, if you want to refactor some stuff and change an ID of your DOM node, that won't break your Huxley test. That makes sense? [Chuckles] CHUCK:  Uhm. JAMISON:  That makes a lot of sense. I have one quick question just from playing with it a little bit. It feels like when it plays back, it uses the same -- so, if you wait a certain time between clicking something, it will insert a sleep into the Selenium script before clicking that. Is that right? [Crosstalk] PETE:  Right. JAMISON:  Is there a need to request those so that you don’t have to wait the same length of time that took you to do the test to see the results when you're rerunning them? PETE:  Yeah. We actually have a parameter called sleep factor and it will multiply your sleeps by some constant factors. So, you can use that to either speed it up or slow it down. JAMISON:  Okay, cool. PETE:  It’s good to speed it up, obviously, but sometimes as your app gets bigger, depending on how you’ve kind of constructed your test pages, they might get slower over time. Sometimes, it actually helps to slow it down. [Chuckles] JAMISON:  Okay, cool. I cut you off track, what were you going to say? CHUCK:  So, I guess the thing that I wanted to know was -- I didn’t get the chance to play with this. I've been buried for a few weeks here with work. So, does this still require somebody to go and look at the screenshot? PETE:  It checks PNG files into git. And the way that a lot of people work is by -- you kind of come up with your git commits and then you submit them either as like a GitHub pull request or another form of code review. And so, we treat these screenshots as part of that code review process. It basically requires you to run Huxley before submitting diffs for code review. And then you can load that up into your tool and see the changes in the images. CHUCK:  Alright. Then somebody does have to go look at those changes in the images? PETE:  Yes. JAMISON:  Automated steps to make them appear in the pull request or you just actually add them as a file in the commit? PETE:  There's a [inaudible] in your repo called the Huxleyfile which kind of has the list of URLs that it’s going to test and kind of refers the file names that contain those logs and screenshots. And at the end of the execution of Huxley, you will have change files in your repo that are basically new PNG files. So, you just commit those and it will appear in your code review tool. CHUCK:  One feature I think would be kind of interesting -- I don’t know if this makes any sense whatsoever for this or how hard it would be, but if you didn’t intend to make any UI changes, it might be interesting to be able to compare it to the previous version. And then actually say, “I didn’t intend any changes,” to just verify that the two images are basically the same. PETE:  That’s actually the default run state. It will replace the screenshots that have changed and won't touch the existing ones. So, if you look at your code review tool, if there's no changes in the screenshots, you're good to go. We also have another mode that runs it in a more strict way. So, if you have like a continuous integration service, you can basically say, “Hey, break the build if the screenshots change.” What that does is that basically catches people that may have accidentally made changes and not rerun Huxley or something like that. CHUCK:  Nice. And then you get the manual review on anything that has changed? PETE:  Right, yeah. You can almost think of this more as a code review tool or linter even. [Chuckles] CHUCK:  I really like it. I'm kind of curious then, can you walk us through how you use it at Instagram? PETE:  Sure. So, I think the prerequisite for finding Huxley useful is if you build your UI with components. So, rather than thinking of your web application as a series of pages, thinking of them as maybe pages with a bunch of reusable components on them. For example, if you look at an Instagram photo page. We have a big photo component that just contains the image. And then we have an ocular component that has a profile picture and the user name. And then we have a comment box component and then those are all wrapped up in an image item component or a media component, that’s what it’s called. So, what we do is we create test pages on our stack that render these components with mock data. So, it kind of avoids some of the problems with traditional integration tests where you don’t rely on hitting like a data backend that can be really slow. So, we just kind of bring up our components with some static JSON data and then run through the test on kind of empty test page that just has this isolated component. So, what I would do is I would say, “Create this test page first.” And then I would add an entry to my Huxleyfile that says, “Okay, create a new Huxley test called open photo menu and kick this URL.” And so then, I would run Huxley and I would say ‘--record’ which means record any test. And it would bring up, it defaults to Firefox. It would bring up the Firefox browser and then I would then press ‘Enter’ in the Huxley console to record a screenshot of the initial state of the component. Then maybe I click on the menu item and the menu pops up and I want to make sure that that looks okay. So then, I take another screenshot. And then, maybe I close the menu to make sure that clicking outside of the menu closes it and I take another screenshot. And then I tell Huxley I'm done and it will basically save those screenshots to disk and then you can commit the JSON file that stores a record of all the browser events and those PNG screenshots. Then in the future when somebody runs the test, if anything changes in that UI, they’ll be alerted with new screenshots. CHUCK:  That’s awesome. So, do you know of other people who are using Huxley outside of Facebook? PETE:  Yeah. We have a fairly active community. We’ve got a lot of followers on GitHub. I think they're mostly smaller, kind of design studios that are using it. I think that this tool, this proportionately benefits really small resource constrained teams that need the highest leveraged way to just get some sort of test coverage on their UIs. I think that bigger teams with kind of frontend engineering departments can invest in writing Selenium scripts and more traditional unit test approaches. I'm not sure of -- I can't rattle off the name of companies off the top of my head right now. But we have a decent amount of activity on GitHub. JOE:  What do you think about those companies just using Selenium scripts? I mean, it doesn’t really solve quite the same problem, right? PETE:  Right. So, the traditional Selenium approach is to write a script. Actually, Facebook uses this traditional approach for a lot of things. Basically you say ‘find element by ID’.  And then you say ‘element.click’ and you basically tie your test to this structure of the markup rather than the UI itself. So, the reason why we avoid WebDriver test a little bit at Facebook is because we do a lot of refactoring of code all the time. And if the underlying markup changes or the structure of the UI changes a little bit, those tests will tend to break and be false positives. So, that’s where we kind of got the idea that these kinds of UI integration style tests are going to break all the time, so we should embrace change. And so, one of the ways we try to embrace change is by decoupling from the structure of the DOM which Selenium kind of relies on. And then the other thing is it’s not just kind of issuing those actions to the page, it’s also with Selenium, you kind of do asserts based on DOM queries as well. So, you click on something and then you assert that a certain node is in the DOM. It actually doesn’t catch a lot of bugs. One of the bugs that I ran into, it was kind of like a level one emergency at Facebook. It was one time, people weren’t seeing any images on our mobile site. This was about a year ago, or maybe a year and a half ago when I was working on photos. We looked at our dashboards and all of our tests were passing, all of our WebDriver tests worked as well as our unit tests. And we looked at our egress graphs on our image CDN, and all the clients were downloading the images, they just can't see them. And so, we went on and we realized that someone had accidentally set a CSS rule that set the height of all images to zero. And you would never have caught that with a unit test, you would never have caught that even with a traditional Selenium test. The only way that you would have caught that is if someone actually looked and saw that it didn’t look correct. So, those are the types of bugs that we can catch with Huxley that you can't really catch with a more traditional WebDriver Selenium approach. JOE:  I actually did a project at one of the places where I worked where I used Selenium and I captured screenshots and then I used previous screenshots and used the tool that would actually take two different images, compare them, and then highlight the differences. PETE:  Uhm. JOE:  Huxley doesn’t quite do that, right? It will tell you if it is different but it doesn’t necessarily tell you what is different. You actually have to look. PETE:  There's an undocumented feature in there that will do kind of a basic image compare. You can basically run it and it will give you all the pixels that are different, highlight it in bright green. But what I found was building an image comparison tool is a whole separate project. What we’d like to see is GitHub actually has a git image comparison tool built into it. We mostly shift that responsibility on to the code review tool. But a great one that I've used outside of code review is this tool called Kaleidoscope. That’s really great. It will let you look and see what pixel that pixel changes occurred. JOE:  Gotcha. PETE:  Yeah. The key thing with Huxley, I think, is that it’s not the most groundbreaking tool out there. But I think it really gets the workflow right. The fact that you can just completely embrace change and rerun this tool, and if your DOM structure has changed or your screenshots have intentionally changed as they often do, it’s just really easy to continue to move fast rather than having to debug the false positive in your test or something like that. JOE:  Yeah. And I think that that’s a really important point. You can do this stuff. It’s been possible to do this kind of thing, problem is there was no easy way to get it done so nobody’s doing it. PETE:  Yeah. JOE:  It’s just way too difficult and expensive and that’s what the industry really needs, these kinds of tools. Tools that make -- I mean, that’s so true just on the frontend in general. There's so many things that can be done that are just extremely difficult and streamlining that ability, that’s a huge, huge, huge need in the industry. PETE:  I know. It’s one of those barnacles on the hull, right? It takes you an extra five minutes every time you have to do it. So, it’s never something that people quite feel like they can prioritize. But if it was solved, you’d saved five minutes a day for the rest of your career which is pretty awesome. JOE:  Yeah, for sure. Absolutely for sure. JAMISON:  Can you talk a little bit about why you chose to write it in Python instead of some other technology or language? PETE:  Sure. I work a lot on the React projects. And somebody from the React community ported it to Node. So, there is a version called node-huxley. JAMISON:  As all things will eventually be. [Chuckles] PETE:  [Inaudible], right? JAMISON:  Yup. PETE:  So yeah, it is available in JavaScript. I think you can npm-install node-huxley and it works. I'm not intimately familiar with the implementation. So, the reason why I chose to write it in Python was mostly because at the time that I wrote it which was about maybe nine months ago, I was a little bit more familiar with the ecosystem of the Python libraries, specifically the Selenium bindings and the image comparison libraries. I was a little more familiar with how they worked in Python so I opted to go with Python. If I were doing it today, npm is moving forward so quickly, I would definitely consider doing it in JS. JAMISON:  So, what exactly is it doing on the backend? I know it’s doing something to talk with Selenium and it’s also controlling, taking screenshots. Is that done by Selenium as well? Can you talk a little bit about the internals and how it works? PETE:  Sure. There's a couple of environment variables where you say, “Hey, you use this Selenium server for recording and use this Selenium server for playback.” Selenium actually has an option that says ‘take a screenshot’. We just call that API, we get back a PNG and we kind of drop it into a workflow. There's a couple of interesting hacks that we have to do, though. So, simulating certain events like key events and click events doesn’t work all the time in Selenium. So, we have kind of our way of managing focus. When you're sending keys, for example, we actually have some kind of custom JavaScript that we run to get it working consistently. Another thing that’s kind of a challenge is if you're testing an application and you're running them concurrently, depending on which window is on top, you might have different active CSS rules, for example, that will change the pixels of your screenshot depending on if it’s running in the foreground or in the background. So, we do some tricks there to normalize for that where we basically steal the focus away right before we take screenshots because we can't control the focus exactly. Another thing that we kind of looked at is that if you run Huxley on two different environments, the pixels will be slightly different. So, I've noticed that taking the screenshots on my Retina display for my Mac versus on a Thunderbolt display which has a different pixel density, for some reason, those screenshots are different even though we set the browser size to be the same and we try to normalize for every factor. So part of the workflow is saying, “Hey, here’s where I want to run my local WebDriver,” so the web driver that I can interact with and record these logs. And then here’s a remote WebDriver where I want to actually take the screenshots and do the pixel-by-pixel comparison. So originally, we had a single machine that had a consistent configuration that we would use to take the screenshots so the entire team would get the same screenshots every time. Now, we actually distribute VirtualBox VMs to everybody so it’s the exact same environment. Again, the overall theme here is that it’s not the newest and greatest most innovative technology, but we figured out a lot of the crappy parts about it and normalized all that over for you. JOE:  Very cool. JAMISON:  You also said it gets used mostly in pull requests. I noticed on the readme that it has an interface to use in CI mode. Do you guys do that or is that just for people that want to use it that way? PETE:  It’s not currently running in CI at Instagram. I want to get it there. The one challenge to getting it running in our CI environment is just we have a lot of security things that we have to deal with like where do we run the web driver server and then how does CI go and talk to that, just kind of production engineering stuff. JAMISON:  Sure. I’m still a little confused how it would work in CI mode because there are going to be pull requests that will change the look and feel that will, presumably once you submit a pull request to have your workflows, it will run the CI server. And then won’t Huxley fail then because it’s different? PETE:  It will fail. JAMISON:  That’s not really what you want, right? PETE:  Well, that failure will indicate, “Hey, the person submitting the pull request forgot to run Huxley.” JAMISON:  Oh, they didn’t run it with the updated versions and stuff. PETE:  Right. So, part of your changes include all of the screenshots. JAMISON:  Okay, that makes sense. Yeah, I’m still trying to wrap my head around the workflow using this because it’s so different from the normal developer-driven, code-driven things I’m used to working with. PETE:  Yeah. If you think of -- the screenshots are almost like build artifacts that you check-in to the repository just to get the code review benefits and the fact that they evolve over time. I’m doing a really bad job explaining that. [Chuckles] JAMISON:  No, I think it makes sense. It’s just a different concept for me. PETE:  Yeah. I’m not sure whether to call it a test tool or a code review tool. It doesn’t kind of fit into one bucket or the other. JAMISON:  Yeah, it’s kind of cool because there are lots of frontend engineers that straddle the divide a little between designers and developers and this tool seems like it fits really well with those kinds of people. PETE:  Oh, yeah, absolutely. The design community in particular I think are the big adopters of this. JAMISON:  Just from reading the readme, I feel like I’ve missed a lot of the things that you talked -- well, I’m explaining this wrong. It seems like there are a lot of things you’ve talked about that aren’t in the readme, like options and command-line flags and stuff. What’s the best way to learn about all these? Is there a more in-depth guide to it? Or do you just kind of have to look at the code? PETE:  I’m trying to keep the interface to it really constrained. So, if you actually go and browse in the code, there’s the Python interface to Huxley which has a ton of options. And then, there’s the command-line interface which doesn’t expose all of those options. Just because it’s hard enough messaging what Huxley is and the benefits and having a million command-line options makes that harder, I think. My general approach has been like put it out with as few options as possible to make it useful. The ones that we basically, are the only ones that we use at Instagram. And then when people open GitHub issues or issue pull requests saying, “Hey, I really wish Huxley did X,” it probably does it already do that, we just haven’t exposed it. And so, that’s been my approach for managing that interface. But right now, the readme is kind of the canonical place to look. And there’s an example included in the repo. JAMISON:  Sure. I think that’s actually a really powerful lesson, that there’s a lot of value in constraining what your tool does. Lots of times, developers geek out over all the different options and how flexible and decoupled and abstracted stuff is, but it makes it harder to use. So, that’s a really -- I don’t know. It’s cool that you did that. PETE:  [Chuckles] Thanks. JAMISON:  Are there any plans for where Huxley is going to go next? Do you have a roadmap laid out for what it’s going to do that it doesn’t yet? PETE:  Yeah, a little bit. JAMISON:  Yeah, and just add more command-line options. [Chuckles] PETE:  Well, most of them do involve adding new command-line options. I recently added support for concurrent runs. So, rather than go through one test plan at a time, you can specify an arbitrary level of concurrency which is really great because you’re firing up a browser and taking screenshots and doing user actions. They actually can take a decent amount of time to run. So, that was kind of the biggest productivity boost that we could have done, or at least that we identified. And then upcoming stuff is we’re working on a way to specify different test environments. So, you want to run the exact same workflow on IE 9 and Firefox and Chrome and on different browsers. And another thing I would probably want to look into is maybe having some sort of standard. I mentioned the remote WebDriver, so the standardized environment where you take those screenshots. I’d look into maybe building a more official integration with either VirtualBox VM or Sauce Labs, which is a hosted Selenium service. JAMISON:  Oh yeah, that’d be cool. PETE:  Yeah. JAMISON:  So, your actual browser’s running somewhere else and you’re just pointing Huxley at it, sort of. PETE:  Yeah. Yeah, I think Sauce Labs makes a lot of sense for that. JAMISON:  Sure. They do a lot of open source stuff, too. I know. So, they’ll probably be pretty open to that. PETE:  Yeah, I should probably email them and be like, “Hey! This is a thing. You might be interested in it.” [Laughter] JAMISON:  It’s pretty cool. Is there a place for people that are looking to help? Do you have lots of open source contributors or is it mostly in-house people working on it? PETE:  We have a decent number of open source contributors. Huxley is like one project among Facebook’s big open source push that’s been going on recently. So, I don’t know if you’ve heard of Regenerator or React. For some reason, we have a bunch of projects with the re-prefix and another one is Rebound. But we’ve been open sourcing a lot of our cool stuff. And so, we kind of have the open source contribution pipeline pretty efficient at this point. And we have a lot of contributors that contribute. Some of them contribute to Regenerator and they go and discover Huxley and they go contribute something to Huxley. So yeah, we definitely encourage open source contributions. It’s more discussion about what the optimal workflow is rather than a lot of code-writing at this point because there’s not really a lot of code there. It’s mostly about the developer user experience. JAMISON:  Sure. CHUCK: Do you have any examples or stories of where Huxley has caught something that saved you a whole bunch of time, effort, or embarrassment? PETE:  Yeah. There are a lot of places where it’s caught some things. So, do you guys build single-page applications? JAMISON:  Yeah. CHUCK:  Sometimes. JOE:  Yeah. AJ:  Yes. PETE:  Have you guys ever asynchronously loaded CSS? When you go to a new page in your single-page application, you go out and have to fetch some new CSS? JAMISON:  Yes. PETE:  Okay. We had this problem where we would start on one page and we would have one set of CSS loaded. And then if we loaded another page in a fresh page load, it would have a different set of CSS. But if we navigate it from one page to the other page, it would have both sets of CSS loaded. So, if you use RequireJS, it has a way to load CSS in this manner. And we basically would have a bunch of conflicting style rules that we didn’t really realize until we started running Huxley and having all of these tests. So, our footer would get position fixed randomly on a page that it shouldn’t have been position-fixed. And it would just be this really bad, ugly experience that was really hard to reproduce. And if you had written a Selenium test for it, it would have said, “Oh, the nav bar’s there. It looks good.” But you wouldn’t have those human eyes on there to say, “Oh no, the nav bar’s stuck to the middle of the page. We probably don’t want that.” That’s one thing. A lot of the issues that it catches are around CSS. But a couple other things that it catches are for example added or removed a menu item. We have these little fly-up menus on Instagram that can open up, down, left or right depending on where they’re located on the screen. So, if you have a menu in the lower right corner of your application, you want it to open to the upper left. And we caught a couple of situations where that logic was a little bit buggy because there’s just no other way to test for that, unless you had specifically thought of that case ahead of time, which a lot of people may not have thought of. So, it catches a broad class of bugs. [Crosstalk] JAMISON:  So, I just have a… Oh, sorry. Go ahead. PETE:  No, I was just saying it catches a broad class of bugs. JAMISON:  I had another thought about a possible use case for it. So, it seems like sometimes developers have ideas about different workflows. I mean, one use case could be you just go and make a change on a feature branch and you run Huxley on it and then you also have the Huxley screenshots from the original branch. And then you have a way to walk through what the UI will look and feel like with your new feature or something. It seems like you could kind of use it to prototype and show off results to people. PETE:  Exactly. JAMISON:  Do you use it for that? Have you seen people use it with that? PETE:  We’ve used it for building everything since we launched web profiles. And we launched web profiles over a year ago. The way that we’ve used it, anyway, is the designer will give me a mock. It’s just basically like a PSD or a PDF that says ‘this is what it should look like’. And then I go and I build the individual components in the mock. And I add the designer on the code review and he can see the screenshots of what was in the mock or what I built, the versions of the mock that I built in actual code. And then, he’ll either accept it or reject it. And then he can go in and make changes and I can see the changes that he made. So, I can kind of get better by saying like, “Oh, maybe I missed this one little thing in the mock,” or something. But then when I actually have ideas for how I would want to improve how something behaves or whatever, I just go submit a diff that includes my changes and it shows up in the screenshots. So, we can actually work remotely without me calling him over and saying, “Hey, this is how I want this to work. Does it look good to you?” He can see in the diff, “Oh, this makes a lot of sense to me.” So, we did a little bit of iteration on our video player that way. JAMISON:  That’s super cool. CHUCK:  That’s really nice. So, what things are you looking adding to Huxley in the future? PETE:  It’s mostly the stuff around platform independence and integration with other ways of running Selenium. I’d really like to look at how maybe the Rails guys run test for example and see if it makes sense to build some sort of binding into Rails. I haven’t used Rails a lot, but I know that a lot of people use it and would probably benefit from something like this. CHUCK:  Awesome. JAMISON:  And then eventually take over the world. PETE:  Oh, this is a project that I want to take over the world for people that need it. I don’t think that this is a tool for everybody. If you’re a small shop, a small startup, and you had to ship yesterday and you don’t have time to write and debug a lot of unit tests, you just want to make sure that you don’t completely break the UI as you’re moving really quickly, I think Huxley’s a great tool for you. But if you’ve got an entire force of tens of engineers building frontends and have time to build really, really concrete detailed unit tests, you might only want a couple of Huxley tests to just cover, “Do my core flows look okay?” CHUCK:  That makes sense. So, do you guys have any other questions or should we start to wrap this up? Or… JAMISON:  I think I’m good. I just barely started playing with it today because I am not as prepared as I should be for the podcast. But it’s just made me think about a lot more possibilities that I haven’t. So, it’s kind of mind-expanding. I’m digging it. CHUCK:  Yeah, and it seems like it’s a relatively simple tool. If you’re familiar with writing things for Selenium’s WebDriver, the rest of it is just taking the screenshots, adding them to your repo and then making sure they get reviewed one way or the other. PETE:  Yeah. If you try it out, you’ll really kind of get a feel for the workflow and imagine how it would work in a bigger team. And it really just saves you time. CHUCK:  Yeah. Well, I’m excited to give it a try myself and see what we can get out of here. PETE:  Cool. Contributions accepted. [Laughter] CHUCK:  Awesome. Alright. Well, let’s go ahead and do the picks. AJ, do you want to start us off with picks? AJ:  Absolutely not. [Chuckles] CHUCK:  Alright. Joe, what are your picks? JOE:  AJ, you big wuss! [Laughter] JOE:  Alright. I’m going to pick a couple of board games this week. I’m big into board games. Really like them. And I’ve purchased a few recently that I’ve been playing and really enjoy. So, I’m going to pick three of those. The first one is ‘Spot It!’ which is not technically a board game, but it comes in a little round can. It’s a whole bunch of round cards and on the back of the cards are pictures of things. And if you take any two random cards, each card has eight pictures on the card and any two random cards from the stack of 55 cards will have exactly one of those pictures that match. And so, the goal is you’re looking at two different cards because you hold a card and somebody else holds a card and you want to find a match between the two cards before the other person does. And they have a whole bunch of game variations. But it plays really well for two people. You can play up to, there’s no real true limit, but probably eight is about the feasible maximum. I think I’ve played some games with ten people. But it gets to be really awesome. Very competitive, great for kids and families. Simple to learn, but you can play it for a long time. It’s a fairly popular game. So, if you haven’t played ‘Spot it!’, definitely check it out. I’m also going to pick ‘The Duke’ which is a fairly new game. It’s just recently come out. And it’s essentially chess except instead of having 16 pieces, you start off with only a king and two sort of pawns. But the pieces don’t move the way that typical chess pieces move. There are about 12 different kinds of pieces and each piece moves entirely differently. And so, instead of having a little standup figurine, you actually have a little card that lays down and shows you how the piece moves. Because each piece moves so differently, you need that to refer to, to know how the piece moves. And what really makes it even crazier is when the piece moves, you flip the card over and in the next move, it moves differently. And then when you move it again, you flip it back. So, each piece moves differently. And then on your turn, you can either move a piece or bring out a new piece and place it next to your king. So, you have a little bag. There’s some randomness to it. You have a bag that has all your tiles in it and you pull out one at random and place it next to your king if you want to pull out a new piece. So, you have fewer pieces on the board because you’re only dealing with, usually each side has three or four. But the movements are a lot more complicated. And it’s just a one-on-one game, but it feels a lot like chess but with just a lot more interesting movement and variation to it, and of course, some randomness. So, I’m going to pick those two. CHUCK:  Awesome. AJ, what are your picks? AJ:  I’m going to pick AngularJS again and Angular UI Router because Angular UI Router doesn’t suck. And Angular doesn’t suck either [chuckles]. Only a little bit. That whole, “Oh, we’re not going to give you error messages if something’s not right. We’re just going to be happy and work anyway. That’s the web.” That’s everything in the web. [Chuckles] JAMISON:  Angular UI Router’s sweet. It seems like it’s influenced a lot by Ember and it’s really cool to see cross-pollination like that. AJ:  Yeah, it seems to just make sense. You can have nested views. The thing that I’m working on right now is figuring out how to get a modal to show up based on the route. It really bugs me when I visit sites and I’m able to get to some location and then I can’t just copy and paste the link over. I have to tell someone how to get to it. For example, there’s a DJ scheduling site that I use for my DJ business and it has a calendar portion of it. But in order to get to the calendar, you have to click on something and then the calendar opens up. But you can’t bookmark that. And so, with Angular UI Router and Bootstrap modal, there’s supposed to be a way that you can. Not just bookmark a path to a template configuration, but bookmark a path to state. CHUCK:  Interesting. PETE:  That sounds awesome. CHUCK:  Alright. Jamison, what are your picks? JAMISON:  I just have one. It’s a conference that’s coming up in March in Utah called MountainWest JSConf. If you’re familiar at all with the Ruby scene, there’s a MountainWest RubyConf every year that Mike Moore has been running for a while and he’s expanding it to have JavaScript conferences as well. So, it’ll be two days. I’ll stick the link in the show notes. And the call for proposals is open right now. It’s kind of aiming to be a more grassroots low-key hacker conference. So, the tickets will be cheap and the talks will be, his words were like, “Mind-blowingly technical.” So, you’re supposed to leave with your brain hurting. So, if you’re interested in speaking or coming, check the website out. It will be super rad. And that’s my only pick. CHUCK:  Awesome. I know I’m going to be there too. JAMISON:  Cool. CHUCK:  Excited to see it. Alright. I’ve got a couple of picks. The first pick that I have, I’m not sure if this has been picked on the show before or not, but it’s a pretty handy tool if you’re trying to work with other folks, and that is Screenhero. You can get it at Screenhero.com. It’s a very nice tool for sharing. You can share an entire screen or you can just share an individual window. You cannot share multiple windows unless you’re sharing an entire screen, just so that you know. So, that’s one limitation on it. But it’s really nice and I use it quite a bit for work. The other pick that I have is OmniGraffle and it’s a little bit expensive. But it’s a great way to visualize what you’re working on. And so, I thought I would put that out there and let people know that I’m using it and that I like it. Pete, what are your picks? PETE:  So, I’ve got two picks. My first is this book I’ve been reading called ‘First, Break All the Rules’ by Marcus Buckingham. And basically, in the late 90’s, the Gallup Organization went around and interviewed 80,000 managers and a million people, like employees, and figured out what makes organizations work well and what makes them not work so well. And I just really like any sort of book that tries to tackle some really, really difficult poorly defined problem with just tons of data. That’s been a really interesting read for me. A little less because I’m interested in how that works, but a little more because it kind of makes me ask questions about the organizations that I’m in and how can I kind of contribute to a better environment. The second pick that I have is a tool called webpack. I think it’s the least appreciated JavaScript packaging tool ever. This thing does everything. They’ve thought of everything. It works really well. It’s really fast. It runs on every operating system and environment I’ve tried. And it’s just a great project. And every time I’ve opened an issue, it’s been fixed in a day. So, I really like webpack and I’m going to be using it for like all of my future projects. CHUCK:  Awesome. PETE:  That’s it for me. CHUCK:  Alright. Well, thanks for coming on the show, Pete. It’s been interesting to talk about. And hopefully some folks out there will get some value out of Huxley. PETE:  Thanks. CHUCK:  Alright. I just want to mention our Silver Sponsor, Reg Braithwaite, JavaScript Allongé, and thank him for supporting the show. Go pick up his book. It’s pretty good. And with that, we’ll wrap up and we’ll catch you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.