Hi everybody! How's everybody doing? I want to welcome you to my talk this morning which the title of which is Embrace and Extend No More. It's how the Selenium project invited Microsoft to participate. When I was first contemplating this particular talk and how I wanted to approach it, I was truly really trying to figure out what format I wanted to take with it and kind of the things I wanted everybody to take away from it. And there's lots of really great information out there on the internet, lots of great things about how to give a great presentation, lots of lots of interesting things about rules you should use, what you should and shouldn't do, all that kind of thing. I'm going to break some of those rules today, so I'm going to ask you to indulge me on that. I'm going to break a few of those rules and we'll see. So one of the rules, and it looks like we might be having some challenges with seeing some of the slides on the on the monitors, but rest assured that this particular slide just has my name on it. And what's that? We're in good shape now. So one of the rules about giving a great presentation that I'm going to break is you shouldn't spend a lot of time and energy introducing yourself because nobody really cares who you are, they care about what you have to say, or at least that's the way the theory goes. But that's really not going to work in this case and I'll talk a little bit about why I need to tell you about who I am in a minute. But so I'm Jim Evans and I work at salesforce.com and I'm also a committer on the Selenium project. I work mostly on the .NET bindings and and the IE driver, which is where you may know me. So let's just go ahead and get started. First of all, this is a personal story and I want to spend a couple of minutes talking about what this presentation is not going to be. Just a couple of minutes. First of all, this presentation is not going to be overly technical. This talk is not going to be overly technical. We're not going to go through a whole ton of code.  We're not going to be talking about scripts or page objects or any of that kind of stuff. We're not going to be doing a ton of demos. So it's not going to be overly technical. Much to my dismay, the slide deck will not contain a whole lot of photos of cute photos of kittens or cats. That's really much to my dismay because who doesn't like cat photos, right? Aren't they awesome? And besides, I have the absolute cutest cat in the world at home who makes great photos, but I'm not going to be using a whole ton of them. So just to set your expectations on that. Hopefully this presentation will not be boring. I'm going to try my best to make it entertaining and we're going to have some fun. If you feel like I'm not holding up my end of that bargain, I apologize ahead of time. That's all on me. So that's kind of what this presentation is not going to be. But I do want to take a couple of minutes also to talk about what the presentation will be. And if you notice in the prologue, I said that this is a personal story. The first thing is it's a story. It's one that spans more than 20 years in the software industry. And it's a true story. It deals with history and ego. And yes, it does deal with browsers and all the fun stuff that we know and love. But it's a story and I hope you'll indulge me as I try to tell it. It's also a personal story. It's my story. And I lived it and I hope you'll find it enlightening and entertaining. But I also hope you will find it entertaining and I hope you'll find it engaging. I've also got three kind of takeaway points that I'd like for you guys to leave out of here with after I'm all done. I hope you'll take them to heart. So without any further ado, we'll start our story. Is everybody sitting comfortably? Well, let's begin then. So part one, catching the wave. Our story starts in 1992, 22 years ago with me starting in product support at a little company called Microsoft. I supported Windows and Windows for work groups. If anybody remembers that project, does anybody remember Windows for work groups? Anybody been around long enough to remember that project? I was on the phones for the first group of phone people that supported that. And, you know, it was a good experience. And then Microsoft released this little product called Microsoft Access. Has anybody heard of Microsoft Access? Give me a show of hands, quick show of hands. Okay. So at least some of you in the room have heard of Microsoft Access. Well, in Microsoft, when Microsoft released Access 1.0, they released it for $99 a copy as an introductory offer. Well, $99 a copy is a pretty good deal for a full-fledged application. So everybody bought it, right? I mean, everybody, who could pass up a database project for $99? So everybody bought it and then they couldn't figure out what to do with it. So they started calling Microsoft support a lot. And they really overwhelmed the Microsoft support team. So starting in November of 1992, I moved over to supporting Microsoft Access 1.0 at that time. And I continued to support it through the 1.1 and 2.0 releases. I'd had some DB classes at university. And I think I got to be pretty good at it. But my support, my term, my time as a support engineer is kind of coming to an end. And I'd done pretty much everything I could think of to do in that particular job. So I started looking around at other opportunities and ended up applying for a job as a software tester on the Access team. And that was a pretty interesting leap for me because I'd never done anything like that before. Had never really thought about what it meant to be a software tester outside of, you know, a couple of articles I'd read and a couple of books. And, you know, I'd had some classes at university, but my degree is not in computer science. I never took any, I took some computer classes as an engineer, but I'm not a computer scientist. So it was a little bit of a scary move. But they decided that I was a good risk. So they went ahead and hired me. And in 1994, I moved from Charlotte, North Carolina to Redmond, Washington as a software tester on the Microsoft Access team. Now, the interesting thing about the team at that time is that they used software test automation to test Microsoft Access. And they automated everything. I mean, everything you could possibly think of to automate, they did. And they did it through the UI. They did UI based software automation on the Windows platform for a Windows application. In fact, they were among some of the first teams to do that at Microsoft. And some of the concepts that they pioneered on that team eventually got folded into another product called Microsoft Test, which you may or may not have heard of. It's kind of vanished to the annals of history now. It was Microsoft Test and Microsoft Visual Test. And then it got bought by a rational software, became rational visual test. And now it's part of IBM's software suite. But that had its earliest beginnings in some of the work that the Microsoft Access Test team did. So during this whole time, you know, we're doing test automation, doing it through Windows calls, and sometimes using COM object automation when it made sense. But at that time, Access didn't do anything with COM automation. So we were limited to doing a lot of things with Windows handles and Windows messages and all this kind of esoteric that goes along with working on the Windows platform. And I was with the Access team for a good long while. And then came Windows 95. And there was this little add on product for Windows 95 that came out when Windows 95 was released called the plus pack for Windows 95. And it had this application in it, this little application inside the plus pack, it was an add on for Windows 95 called Internet Explorer 1.0. And that was the first release of a web browser for Microsoft. It was not long before this time that there was a memo that was sent out to everybody who worked at Microsoft by Bill Gates that said that the Internet was like the most important thing to hit since the invention of the PC. And, you know, if you Google online, you can see that that memo, the text of it, and talks about all the different ways that the Internet was going to change how Microsoft did things. But so Internet Explorer first came out and it had a COM object model. Now COM is the component object model. This is what is the technology. And it allows you to create reusable parts and script and tie them together and script them together through different interfaces. And that way you don't have to reinvent the wheel every time you want to say, do something with a word processing document and format text. Well, you can use Word for that and you don't have to reinvent Word to do it. You can just call some automation methods and get that done. Well, IE had that same thing and we started to look into what it would take to automate browsing the Internet using the COM object model of Internet Explorer. As part of my time, as part of the access group, there was a push. Right about the time Access 2000 shipped, there was a big shift that said that all Microsoft Office applications were going to heavily invest in Internet features and Internet-based features. And it was going to be a big thing and we were going to have all kinds of Internet features and Internet-enabled Microsoft Office. And Access was no exception to that. We had a feature that is now no longer in the product, but it was at the time it was called Data Access Pages. And the idea was that you would use the Access form designer and you could graphically design these Internet pages or these web pages that you could then host on a web server and have it connect back to your Access database and do fun things with your Access data right there on the web. The tricky parts for us on the test team was, well, since we've heavily invested in test automation, that means we have to automate this stuff. Which, you know, thankfully we did have the ability to use the COM interfaces for Internet Explorer which let us do a pretty good job of starting to automate that. So Access 2000 had this and then in 2001, of course, IE6 was released, right? And IE6 was, you know, basically at the time took over the world, right? I mean, it was the most ubiquitous browser in use at the time. It was, everybody used it. Businesses used it. Consumers used it. It was used by everybody. It came with Windows. It was part of the package. And we were able to continue to use that. Interestingly, as we were doing our test automation now, let me describe a little bit about how we approached that. I mentioned that we did straight Windows API calls and that kind of thing. We did this all through visual basic. It was the language that we used. When I started with the Access team, it was VB4, was the version that we used. And then eventually we upgraded to five and six as those went along. And, you know, we didn't try to do any kind of recording or anything like that. And it was, it was at that, it was, it's part of that experience of getting in and trying to figure out how to get hooks into the product and how to make sure that we were able to do all the things that we need to do and test all the things that we needed to test is where that came to the first thing I want you to leave this room with. That automated tests are and ought to be treated as software. They are software just like the product that you're automating is. They are, they are and ought to be in a source control program. They are and ought to be developed and developed in a programming language. This was where, this was part of, of where I came to understand that recording and playing back of, of, of actions doesn't work very well in the long term for the maintenance of your automated tests. And so the first thing I'd like for you to remember, and the first thing I'd like for you to take away is that let's remember that when we are writing automated software tests, we're writing software. Your job title may be tester or QA engineer or quality engineer or something like that. But at the time that you're writing tests using a programming language, guess what you're doing? Development.  So we fast forward a little bit. 2004, I left Microsoft and moved to a, to a small company, small at the time, called Numara Software was the name of it. Well, actually, when I started with the company, it was a division of Intuit, makers of Quicken and QuickBooks and all those wonderful products. The company was subsequently spun off into a private company. And now it's, it's been reacquired. It's, it's now a part of BMC software. But I was still doing primarily test automation work. I was, I was brought into the company to, to start up and, and maintain their, their test automation effort. The big product at the time of that, of that company was a, a client server application, thick client, that was, that you had to install the clients, the server part of it on a, on a server that you maintained on your premises. And the client version that you installed on people on everybody's workstation who would want need to use the software. Let's do a quick show of hands. Is there anybody in the room who's over 50 years old? Anybody over, anybody over, over 40. Okay. Anybody over 30. All right. Now we're getting there. Okay. So for those of you who are under 40, under 30, this is how software used to be delivered. You used to have to actually install it on your PC and maintain it. And somebody had to continue to monitor it and update it and all this other kind of stuff. Nowadays we have it, I don't know if it's better or worse, but it's a little different nowadays. But anyway, so this, this client server application written in Delphi, I don't know if anybody knows that particular language. It's a Pascal variant that allows you to do forms and stuff. So applying some of the same techniques, I started to create a software, an automated software test suite for this particular product. And then we had the idea that we were going to completely rewrite the thing, shifting to the .NET platform when that platform was released and it was new and it finally got into a mature place or that was the hope anyway. So scrapped all the work that I'd done, started over with the new, new test automation platform in .NET. That was an interesting project, by the way. We decided that we wanted to make sure that anybody could write tests, right? Not just the testers that could write them. We wanted anybody to be able to write tests. So we came up with this keyword based framework and an editor that you could do keywords with and, and choose the objects and we have the object model and you just say what you wanted to do. The problem is that the people who were developing it were also reasonably decent developers. So we decided that in order to write robust tests with the ability to have things, this code that you could reuse in other places, well then we had to introduce the idea of the equivalent of a function, right? And then we decided that we needed to be able to do things like run the same set of steps over and over again. So then we had to introduce something like a loop. And then we decided that, well, we, we, we had some places in our test where we needed to be able to do one thing if one thing happened and another thing if another thing happened. So all of a sudden we had to do branching and ifs. And all of a sudden we created our own programming language, which wasn't nearly as cool as it sounded. If we had it to do all over again, we would have approached it completely differently, obviously. But that was the mandate and, and it's one of the reasons that sometimes I get a little concerned when people say I want to write a bunch of tests, but I want my business analysts who don't know how to code to be able to write them too. Or, you know, I'm just a tester and I don't know how to code so I don't know how I'm going to write my automated tests. That's one of the reasons that that starts to concern me when I start to hear that when people tell me that. Anyway, it was about this time that I personally started to look at doing automation on the web side of things. With the access team I didn't have any responsibility for the data access pages features, so I wasn't automating with Internet Explorer, anything else for that matter. But this particular product, in addition to the thick client, also had a web portal. Now it was little used, nobody really used it, or not many people used it, but you could use it for, you know, self-service so that your end users could come in and reset their own password or, you know, submit their own work orders, that kind of thing. And so after we got our nice automation project done with, for the thick client app, we decided that we would tackle the web, the web product, the web portion of the product. Now, you have to remember at the time, let's go back and think about the context at the time, at the time the biggest operating system on the planet was Windows XP, right? This was in the days before Vista, this was in the days before Windows 7, XP was the king of the roost when it came to operating systems for business, you know. No self-respecting business would let its end users run Linux, and unless you were an artist or some sort of creative professional, you weren't using a Mac, right? I mean, that's just the, that was the state of the business at that time. Also, Internet Explorer 6 was the browser that everybody used. Firefox was, you know, Netscape had become the Mozilla Foundation, and Firefox had just started to get going. I think we had had Firefox 2, and maybe 3 had come out by this time. Chrome didn't even exist. There was no such browser as Google Chrome at this time. So, we started looking around for a way to automate this stuff, and this would be about 2006, 2007, if you want to know about then. And, oddly enough, we evaluated Selenium at the time. We evaluated that, you know, Selenium as a possibility for what library we were going to use to automate stuff to test this web thing. And we rejected it, because at that time all we had was Selenium RC, and we took one look at the API and shuttered, and said, ew, that's ugly, because we had reasonably competent developers who threw up at the idea of having a single object with 140 methods on it that you would use. So, the other thing that really threw us off was that we were a .NET shop, right? We were a .NET shop, and if you were going to use Selenium RC, what did you have to have? What did you have to use if you were using Selenium RC? You had to use Java. You had to use, you had to run the Selenium RC server, no matter what language your tests were written in, you had to use the Java server in order to communicate with the browser. And for a pure .NET shop, even in the testing environment, that was a non-starter. We weren't going to pollute our machines with having to run Java on them. So, we found this little library, we started looking around at other things too. Has anybody ever heard of a project called WATER? W-A-T-I-R, WATER? Web application testing in Ruby. Brilliant idea, lovely library, lovely API. We looked at it, we said, this is a great API. But then we said, but Ruby, ooh. Nobody knows Ruby around here. That's going to be a problem. So, a little bit more research, a little time goes on, and we figured we found this other little project called WATIN, W-A-T-I-N, web application testing in .NET. Somebody had gotten a great idea, had seen the WATER API and said, hey, that's cool. Let's do that in .NET. So, they did, and it was, it was a nice little library. So, we decided to use that because we were only really worried about Internet Explorer for the most part. We did support Firefox, but not really, you know, how you say you support things to get the checkbox on the thing, but not really, you don't really care about that. That was, that was kind of how our web project viewed Firefox at the time. And WATIN, while it was a primarily focused on Internet Explorer, it did have a cross-platform or cross-browser story for Firefox, which was great. We figured we'd tackle IE first because that was, you know, you prioritize things, right? You say, IE first because that's the biggest, that's the biggest thing we're going to do. And then when we get time, we'll get to Firefox, and then whatever else we have to do. You know, we all do that, right? We prioritize what we need to do by how many users we have and that kind of. So, the other great thing, and this was my first introduction to really, to really getting into using an open source library. Because WATIN is open source, right? Source code's right there. You run into a problem. Hey, guess what? We could fix it. And that was my first experience of submitting a change or a fix to a bug that I had found that was annoying me back upstream to the project. It's a really great feeling by the way. To see, you know, to see that something that has bugged you and you can fix it and then you can share it with everybody else to use. I think that's a fantastic thing. Now, you have to understand too that WebDriver didn't really exist at this point. So, we're using WATIN, discovering open source, having a lot of fun with that. We had a group of reasonably experienced developers in our test department. So, the so called hidden costs of using an open source library that you sometimes hear bandied about on the net were not an issue for us. So, that's where we were at that time.  And that takes us to, you know, a nice place to say, we start moving into a new phase because now we're doing Web Automation, right? We meaning me, right? Okay, I'm sorry. Aside. I know I'm standing up here in front of a group of people and that makes me something of a narcissist and an egotist, but really and truly it makes me terribly, terribly uncomfortable. So, if I slip into we, please understand that usually I mean I'm talking about myself, but because I'm uncomfortable talking about myself as I did this and I did that. That doesn't sound comfortable to me. So, I often lapse into we. So, please indulge me in that little quirk of language, if you will. So, we have some challenges. Time marches on, right? Again, like I said, XP is everywhere. Windows XP is everywhere. That's the operating system everybody uses in business, in enterprise software. Internet Explorer 6 is the browser everybody uses in enterprise software. Well, then things start to update because time moves on. Nothing ever stays static forever, right? October 2006. Internet Explorer is released. Multi-process Internet Explorer. So, all of a sudden you can't just say that this window of IE belongs to this process on Windows anymore. Well, we could deal with that. We could work with that. Not a problem. That's okay. Then came January 2007 and Microsoft released Windows Vista. Which is fine, except it introduced this thing called user access control. Has anybody ever heard of user access control? UAC. Yeah. It's a great feature. It really is. It's a fantastic feature. It really genuinely reduces a lot of the attack surface that a lot of hackers would use or people would use to intrude on your system. But it introduced some challenges for automating Internet Explorer in particular. Now, on the plus side, Windows Vista had a very slow uptake period. A lot of businesses were not ready to upgrade from Windows XP to Windows Vista right away. So, we kind of figured, okay, we can test IE7 on XP and it'll be the same. It shouldn't be that much different as if we tested on Windows Vista. So, we kind of ignored the Vista problem. Any problems that we have automating Internet Explorer, we'll just ignore that. We'll just test on XP and that'll be just as good, right? And for the most part, we were right. For the most part, we were right. We were able to get to ignore that issue because XP, frankly, was still dominant in the industry. So, let's do a little bit of a review of where we were at. Browser based testing. We have a system that lets us test against IE and a little bit of Firefox. It lets us test on Windows XP and not really on Vista, but we're going to ignore that too because, you know, nobody's really using Vista yet at this point. And then 2008 happened and Google released the Chrome browser. Okay, well, that increases our test matrix now. So, not only are we not testing against Firefox really a whole lot, but we're not going to test against this new browser called Chrome. Now, at the time in 2008, Chrome was a kind of a novelty, not a whole lot of businesses were using it in the very first, in the first incarnations of it. But then it started to get really good and started to get really fast and started to be known as the fast browser. And so then we had to start thinking about, well, now how are we going to do test against Chrome? And Wadden didn't have a story at all for how to handle Chrome. And then in 2010, Mozilla released Firefox 4.0, which is great. Fantastic. They're starting to, you know, they update their things. Problem is that their architecture changed in such a way that it broke the ability of Wadden to communicate with it. The method for communication that Wadden was using to communicate with Firefox 2X and 3X now no longer worked with 4X. And there was no hope of, I mean, they just completely broke that. They completely intentionally said this will not work anymore. It was a security hole, honestly, that they closed and we could no longer do it. So we really had to start looking for alternatives at this point. We were kind of up against the wall because now Chrome was starting to gain market share. Firefox was starting to gain market share. And we really started to have users saying, hey, you know, is your product supported on Chrome? Is your product supported on Firefox? And we couldn't with any confidence say, yes, it is because we weren't testing against it. Wadden wasn't working for us anymore because now it had these limitations that we couldn't work around. We loved the API. The API was still really fantastic. It really fit with the way that we thought about how web pages were built. But with no Chrome support and with Firefox support no longer working, we really need to look for an alternative. Let's talk a little bit about a little project called WebDriver. It started by a gentleman named Simon Stewart. I think you may have heard of him. I think you may have heard about it, maybe even earlier today. It's about 2008. WebDriver started to gain steam, started to gain popularity. And in 2009 there was the merger with the Selenium project. Now at that time the Selenium project or the WebDriver had really good Java support, pretty good Ruby support, some Python support and not much .NET support at all. The .NET bindings had been started. There was a skeleton there, but they didn't actually do anything. So I saw the potential, right? The thing that WebDriver really brought to the table for us, that we thought, oh, this is fantastic. Cross browser support. It works on all the browsers and abstracts all of that away so that I can use the same code to test multiple browsers. Now I realize that the Selenium RC project in theory had the same potential or the same promise. But remember that we hated the Selenium RC API and that was not going to happen. So I started looking at the WebDriver project and said, it would be great. It would be really, really great if this project actually had cool .NET support. We could actually use it for .NET. And I contacted Simon and said, hey, is anybody actually working on this? Let's see what we can do. And I started submitting some updates and patches, some .NET code to try to get that code into shape to have it actually work with the WebDriver project. And this was in about 2009. And Simon looked at my code and said, yeah, that's great. Bring it on. And so I started looking at the, and creating the .NET bindings or filling them out, finishing them up, getting them to work. My motivation for this, the idea was, there's a great guy named Yari, Yari Bakken, who Simon mentioned in his keynote. Yari did this great thing. Water at one time was an Internet Explorer only library too. But what Yari did was he said, let's do this. Let's take the Water API and we'll put it on top of a WebDriver core. So what that means is that you get the Water API, but all the stuff that actually is doing the driving of the browser and creating the browsers, creating the browser instance, talk communicating with the browser, all that stuff is done through WebDriver. Great concept. Fantastic. That means that the Water library itself doesn't have to know anything about browsers, anything about the specifics of any particular browser. So now, and now it's rolled into just the plain water project is based on Yari's work at Water WebDriver. So looking around, we got inspired by that. Well, by we, I mean, I got inspired by that. I says, here's a great idea. We can do the same thing for .NET. We'll develop the .NET bindings, we'll make them really first class, we'll get that working, and then we'll take the Wadden API and we'll layer that on top of WebDriver. No problem. That'll be fantastic. It'll solve our problems. We'll still get the code in .NET. We won't have to worry about anything else. All our problems will be solved. Well, I got halfway there. I did the .NET bindings. I never got around to doing the Wadden layer. Much to my disappointment, but it didn't, it didn't end up not mattering because we were folding it into our existing automation so we could swap out where we needed to. But that's neither here nor there. That first incarnation of WebDriver included an Internet Explorer driver, and Simon contributed greatly to that. He wrote a fair amount of that. He mentioned it again in his keynote. I encourage you to, you know, for those of you who are watching this later on, I encourage you to go listen to Simon's keynote where he talks about some of this stuff. And funny story, my first, the first, I had never, like I said before, my degree is not a computer science. I have not done C and C++ programming before at that point, had never touched the language. It only kind of scared me a little bit because, you know, when you do something like dereference a null pointer in a C program, your whole thing crashes. And it's not like it throws an exception that you can catch and move on to. It just ugly crashes the whole thing, and then you've got to start over again, right? So it always intimidated me a little bit. But nevertheless, I figured because I was running into this issue where I was running tests, the WebDriver tests for IE, and it would get slower and slower and slower. I mean I could run a dozen of them at a time and it would be no problem. But when I tried to run the, you know, 200 or 300 that were in the WebDriver's test suite for .NET at the time, it would get repeatedly slower and slower and slower. So I had to try to figure out something to do. I was trying to figure out why this was happening. And I was a little shy about looking at other people's code. So I got a whole assignment on the IRC channel and I went into and debug some things and what it turns out was happening was that there was a buffer, a text buffer, a memory allocation that was happening that was never getting freed. So every time we would travel through this particular set of code, we'd allocate more and more memory and essentially we were just chewing up all the memory on the system so it would get slower and slower. So I remember, I remember this very vividly. I was very timidly saying, so I think Simon, Simon, here's what I think might be happening here. Can you kind of check on this and maybe this is, you know, very, very, trying to be very respectful because it's somebody else's code. And he says, I don't know. Take a look at it. You fix it. So thanks, Simon. So I've tried to figure out how to debug C and C++ code having never done it before. And eventually fix that bug in that version of the IA driver. And so, you know, we started moving along swimmingly. The other problem with that version of the IE driver was that with IE 7 on Vista and above, you had to elevate. You had to elevate your permissions. So that means you had to run as an administrator like you could do on XP without any problem or you had to actually have an interactive prop that you had to sit there and say yes to. And you couldn't automate that away by design in the system. I mean, if you could do that, then what's the point of having, you know, if I can as an automated system click yes on that button, what's the point of having it as a user must handle this kind of thing, right? But again, we were kind of ignoring Vista because nobody was really using it or it wasn't as popular. But that was one thing that we really didn't care for about that version of the IE driver. And at the same time kind of could currently with this in the WebDriver project was sort of a unification effort that started happening, where the remote WebDriver instance and the Firefox driver instance were really similar in the way they did things. They talked over HTTP to a server component and they passed messages back using JSON over this HTTP component. So there was a movement in the project to sort of unify that approach and that was the beginnings of the WebDriver JSON wire protocol, which you've probably heard mentioned here and there, which actually is the basis of what is now the W3C spec, more about that in a little bit. So that was where we were. We kind of ignored the problem for Vista, but then the bombshell hit with Windows 7 and IE 8. And that was a hugely popular operating system. Windows 7, I mean, knocked the ball out of the park. That was a great success for Microsoft. And IE 8 shipped with Windows 7, right? It was the browser that came on Windows 7. And all of a sudden we couldn't ignore the problem anymore, because everybody was like, well, how do I get IE to work? So and I don't know, I honestly don't know what caused me to think this, but I said somebody should really look into solving this problem with the IE driver and IE 8 and with the elevation. Somebody should look into that. And I hear pretty much silence in the room, which was pretty much the response I got back when I mentioned that out loud at that time. And I also said, hey, you know what? Somebody should look into maybe using this Jason wire protocol thing to talk with IE too. And that deafening response that I just got back from all of you guys is very similar to the deafening response I got back from the rest of the community as well. So the somebody that had to do it, I guess, was going to have to be me. So I decided that I would embark on this tilting it windmills, quixotic, foolish errand of rewriting the IE driver from the ground up, which I did. You know, we did that. It was I made the decision. We started writing it in 2010 in August 2010. And the thing finally landed in December of 2010. We managed to get done in, you know, about four months of stuff. And this is despite, again, me not being a C and C++ developer. I remind you of that. I had never used the language before. I didn't know anything about it. So there was a big learning curve for anybody involved. But that's going to lead me to my second big takeaway point, which is that if you have a passion for something, if you have a problem that needs to be solved and you're passionate about solving that problem, don't sit around and wait for somebody else to solve it for you. In the software world, we have open source software projects. Find one that's that's similar or working in a similar problem space and just jump in. Take the code and start working with it. It's really one of the one of the only ways that open source software matures and evolves is by people just deciding, hey, wouldn't it be cool if it did that instead of this? And then taking the code and making it do that instead of this. But the thing is, you've just got to jump in and do it. You can't wait for somebody else to say, oh, well, yeah, I'll do that when I get time. Just take it and do it yourself. That's the important thing. So the first Selenium conference, San Francisco 2011, was one of my first conference experiences ever. It was fun. I did not speak at that conference. But it was clear at that point that there was a trend in the industry now because we had the JSON wire protocol that started to become standardized and it started to get a lot of uptake. And the trend that we started to notice was that browser vendors themselves were ready to start taking on the challenge of providing their own driver implementation. And the opera driver was the first one that was delivered. And then I remember very distinctly at the Selenium conference 2011 when the Chrome driver was announced, that was to be owned by the Chromium project, which was a revelation. So at this point, the IE driver had been rewritten in about six months. And I was starting to understand what it meant to support a project that was used by thousands of users around the world. A little overwhelming. But now that there were vendor provided web driver implementation starting to pop up, I started to say, hey, wouldn't it be great? Wouldn't it be fantastic if Microsoft provided us with a web driver implementation? That mean I wouldn't have to do it anymore. That'd be great. Then everybody who yells at me when it doesn't work can go yell at them. So I started writing a blog. I don't update it very often. But in the first post, I started to answer some of the questions, commonly answered questions about why certain things didn't work in the IE driver. And in that blog and on Twitter, I started to kind of suggest that Microsoft should start to create a driver. I joined Salesforce in 2012. And Salesforce had already had a huge investment in Selenium tests by the time I arrived. They have a three to two ratio of developers to people working in the test environment. They have millions of dollars of infrastructure and data centers that run VMs for automation have really, really bought into test automation. Here, I'm going to throw some statistics out at just some numbers. More than 500 commits a day to the code base, about 120 engineering teams, 50,000 unique Selenium tests that run about 7,500 unique web driver tests running against IE 6 through 11 as well as Firefox and Chrome and Safari. And we're actively converting our legacy RC tests into web driver as well as there's unit tests for all of our JavaScript. Salesforce has come to love web driver. And I'm not going to talk a whole lot about that because there's another talk coming up later that I would encourage you to go see by one of my colleagues from Salesforce, David Tolle, who's going to be talking a little bit more about how we do web driver at Salesforce. But it's one of the few tools in our arsenal that truly mimics the end user experience. That's the great thing about end user, UI based browser testing. And it catches things in that other levels of tests just don't catch by using those. But part of the challenge that we have at Salesforce was and is the stability of our automation against the various versions of Internet Explorer. And it was clear to me even more clear in Stark Relief that it'd be really much better and the IE driver would be much better if the Microsoft team that produced Internet Explorer would also be willing to produce a driver for Internet Explorer. So I started to reach out and this was with Salesforce's support started to use some of my old contacts from my Microsoft days to reach out to the IE team and try to figure out what we could do. With mixed degrees of success there was one kind of surprising event that happened is that Microsoft has its own testing infrastructure for testing, UI-based testing called coded UI tests in the recent versions of Visual Studio. And one interesting thing about that is for web-based testing for doing tests for executing tests against browsers other than Internet Explorer they use the .NET bindings as their automation engine for that, which was really interesting. I think that was directly came out of a lot of that. Now I want to talk a little bit about another thing that sort of led into this which was the worldwide web consortium and who knows who the worldwide web consortium is. Have you ever heard of it? Who hasn't heard of it? Who hasn't heard of it? The worldwide web consortium or W3C is a group of companies and the list is long of the companies that belong to it dedicated to creating standards for the web that we all know and love. Things like CSS and XPath and HTML5 and all these great things are all part of specifications that the worldwide web consortium puts together that browsers are able to do. This effort led by Simon Stewart and David Burns initially. Salesforce has been very encouraging of the working group. There was a working group that was created. It's called the browser testing and tools working group as part of the W3C. The mandate of which is to provide among other things a specification for the web driver API. Salesforce encouraged the working group is encouraged to think it's, it has two employees or two of Salesforce employees are on as part of the working group as invited experts to the working group. Myself and a man named Luke M. and Simaral. This photo here is actually of our face-to-face meetup in London earlier this year, us eating dinner on the side of the road because why not? And you'll notice that I'm there and Luke is sitting second from the right on this, second from the left on this photo and David Burns is center. One of the great things about the worldwide web consortium is that Microsoft is a big participant and as a participant in the W3C they have decided or they decided at the time to send a representative to the working group and have somebody be a member of the working group from Microsoft. This was a, this is a, I can't stress enough how big a thing this was. A guy named John Jansen started to became and he joined the working group and has been working ever since. The spec is taking shape currently. We've had several meetings face-to-face. We have work ongoing. Microsoft has been a huge help in working on this specification and making it happen and making the implementation. One of the bigger things to come out of the last year is that Microsoft has created a driver implementation. They created a driver implementation. They announced it in February of 2014 that they were gonna create one, that they were actually gonna go and create one. It was delivered in June of 2014 in the new Internet Explorer developer channel which is a new thing for them. You could put a new developer channel it would give you a new version of Internet Explorer side by side that was experimental for use with developers so you could try out new features ahead of time. The version of web driver that they released in June would only work with the developer channel. It wouldn't work with the full released IE and you couldn't set that version of IE to be your default browser. It had to be, you had to run it in isolation. And the implementation was preliminary. It was fairly limited. There were some things that were not implemented mainly because they weren't implemented or not documented in the spec yet. But I think we'll all agree that that's progress they had delivered a driver implementation even if used with a different form of IE. And Salesforce has allowed me to work with this particular to branch my work on the open source project and work to integrate their implementation of the IE driver with the existing IE driver server executable. This work has been done in a branch, it's done in a fork. I've been working very closely with the team at Microsoft so we could prove the concept of that integration so that you could use it and not have to do something different. Not use a different executable or anything like that. You could use one IE driver server and be able to do that. Incidentally, Salesforce routinely sponsors this type of open source work. They're very supportive of open source software and it makes Salesforce really, honestly, a really great place to work that they allow us to do that. But in this case, having that new driver will greatly help the stability of Salesforce's automation because it'll be a more stable driver and it'll help everybody else's too. In August, a couple of quick things, Microsoft announced that, I don't know if you saw this but they announced that they would be dropping all support of all previous versions of Internet Explorer except the very latest one starting in January of 2016. So that was announced on the IE blog, the official Internet Explorer blog. And so it's important to stress the importance of people being up to date on their version of IE. They also delivered a beta version or they announced that they were going to deliver a beta version of their IE driver that would work with standard IE. And that was where we sat. And that's where we stand. But that leads me to my third and final key takeaway that if you want true change, you can go a long way doing it yourself, doing it just by yourself. But the real way, the true way to get true honest, lasting collaboration, lasting change is through collaboration. And that's the story of how Microsoft, we invited them in and they accepted our invitation and were able to work. Oh, and to quote the late Steve Jobs, one more thing. In conjunction with the Internet Explorer team at Microsoft, I am very pleased to announce that as of today, the IE driver server executable will support IE 11 using Microsoft's implementation of the IE driver. They have delivered this beta version. They delivered it just this week. You can see here, in this particular image, you see the GitHub commit to the Selenium project that enables this support. Right now it's gonna be hidden behind a switch, command line switch to the IE driver server executable, but we will, over time, it will become the default use or the default driver used in internet, for driving Internet Explorer over time as that implementation matures. So thank you very much to the Microsoft folks, to the Microsoft Internet Explorer team for all of their hard work. Thank you all of our users who have been so supportive over the years in creating the WebDriver project and helping it to become the force that it is. And for all of your time and attention here in the room and for those of you who may be watching later, I thank you.