 All right. So for those of you who don't know me, I'm Dan. I created Appium, which is mostly what this talk is about. I'm going to do something dangerous here. Show of hands. Who in this audience uses Appium more than Selenium? Okay. It's almost to the point where we can rename the conference. Maybe... Anyways, at one point I had a bunch of jobs. I put them on the slide. And a long time ago I got a computer science degree, but I'm mainly known for creating this thing called Appium. And so, first things first, I made it this time. I'm here. Through no small miracle, I am here. Apologies for what happened last year. There's a serious bug with American passports. So you may notice in that very small writing on the top of the left-hand side, you'll see the word visas written on that page. And on that blank, empty page where an Indian visa stamp would look really nice, it doesn't have that word written. And apparently this actually matters. So if you've ever had an American passport, the last three pages of it cannot be stamped. And so I learned that on my trip here. I got very close, as you can see. I made it to Dubai for my connection. I saw the Burj. I hung out with the locals. I saw the ski resort. I like to do the Emirates. It's like the kind of country where the lack of precipitation, cold weather, and topography, don't prevent them from having a ski resort. That's the kind of brute force thinking I just like to see. But anyways, then when I tried to board my connection in Dubai, they informed me of the problem. And the repro steps look like this. Fly to Dubai, going to India. Have someone mischeck your visa in London and say you can go to India. Then get on into Dubai and have it be a Thursday afternoon during Ramadan where everything is closed for the next three days. And not be able to get a new passport without going out of there. And you're having to go back to London because you can't fly anywhere because there's nowhere they can stamp. Anyway, I won't get into it, but it's our subject. Meanwhile, you guys went on without me. And is this guy here? I would give this guy... Is that you? No. He is not here. All right. Anyway, I like this. This is brilliant. This is my tombstone when I die. So let's try this again. So let's start with the beginning of Appium. It all kind of started when I took a job in California working at a dating site. And I was confronted with what I consider the most terrifying words in software testing. And I've done this talk enough where you guys already know what this is. It's these words. And basically what this meant is it was the end of the era of move fast and break ship that we'd gotten used to with Web 2.0. Now we actually had to test stuff before we sent it to customers because Apple had a very lengthy review process in place at the time that meant if you made a mistake, you'd have to live with it for several weeks on average. So testing became a lot more important. And I thought back to something similar I'd worked on earlier in my career. How many of you know what this is? Oh yeah, Simon. The elderly crowd here is like... All right, Marcus too. I know what it is too. I worked on these things. That's actually a DVD which is Eons Beyond all the other media that came before. Like CDs or floppies or double density discs or I don't know, tape drives, whatever else. Anyway, similarly when you made a mistake on something like this, it got printed and sent around the world and it was problematic to fix that mistake to say the least. Windows update was not as advanced as it is now. But anyways, so I took a look around, said how can I get our testing situation better for our mobile app that we have? And everything was not awesome to say the least. There were a lot of frameworks out there. I won't name names, but you know who you are, probably not here. But anyway, there were a lot of bad frameworks out there to do testing with and so I wanted something like Selenium, what I was used to when I worked on websites, when I moved fast and I broke shit. And nothing like that was available. There were things that required you to write a piece of JavaScript and then run it inside the, I guess, performance profiler. There were things that gave you very, very low level access to things. But there was nothing really good where you could sort of come up with strategies to identify elements and then interact with something in real time. Or even Selenium ID style record and playback. There really wasn't a good solution out there that did all those things. And moreover, like Selenium let you work in the language you wanted to work in, a lot of them required you to learn something terrible, like Ruby. Or sorry, Ruby. Not sorry. Anyways, I'll move on for this, but suffice to say it was bad. And so I thought the one thing that I always tell everyone I managed never to do, don't do it yourself. Usually there's some open source software out there you can use, or something you can buy, or there's a better way. Usually you don't need to write the thing. But in this case, it was that one moment in your life when, like, you know, you're at the wedding and they say, you can actually raise your hand and say people shouldn't get married or something. It's like that one time in life when you, like, can do the one thing you're not supposed to do. So I did it. And it looked quite terrible, to be honest. So it all hinged on this hack around Apple Sandbox had this idea that you could run shell commands on a host machine with this very long-named method. And from shell commands, you can do pretty much anything. So I chose to invoke the shell command called Python and then write an actually decent automation framework with it. And so that's what I did. And with this little magic piece of code here that basically has a read loop where it sits and uses the cat command to see if a new sequentially ordered command has been put in a folder in the form of a text file, then takes the output on standard out of that, runs eval on it in JavaScript to actually run the code in the file, and then prints out a text file with the response as sort of a handoff mechanism for a web driver client. So it's quite a terrible piece of code, but the idea was solid. And that was the best way I could figure out how to implement it on my own time and without help. Moreover, there were other parts of it that weren't pretty. I highlighted and read the very interesting part of this script that ran with the initial version of Appium. For those of you who don't know how to read Apple script, this is a script that launches a loop that answers your username and password any time you're asked for permissions. So while you were running Appium, if anything needed permissions, it just got them automatically filled in for you. So obviously not the right way to do it, but nonetheless, I think the point was there that this hack as bad as it was was better than using the tools that the vendors were providing at the time. And any of the other tools out there, which is to say something. So what is Appium? So I think most of you know, so this slide is probably pointless, but it's a very popular app automation framework. It supports iOS, Android, Windows, and Mac, and more. It supports most programming languages, and namely anything Selenium supports. And it's based on Selenium, which all of you here should know, or you're at the wrong conference. So it's all based on the WebDriver protocol, which is now a W3C-recommended spec. I keep updating the site every six years as the status changes. And I think we're currently at recommended level. So I won't tell you how it works, you already know. But this is what it looks like. You have your script, and it's sending commands over HTTP. Appium is then converting those into some form of API request in a test automation framework for that device, and then converting the response back likewise. Moreover, it's kind of a broker for different automation tools. So in the case of a hybrid app, Appium can use XCUI tests, or it can use UI Automator 2 for the native layer of your application. But when you want to actually deal with the Web content, it'll invoke Selenium. So it acts as sort of this middleware between you and a bunch of different automation frameworks. And that provides a lot of benefits, mainly around forward compatibility, backwards compatibility, and sort of working around all the different variations and different versions of different devices with different frameworks and so forth. The idea being that if Apple breaks something with a certain version of Xcode and instruments, Appium, in theory, knows about it, and it hasn't fixed. And then when you upgrade to the new one, you don't have to go change all your code to work around it. Appium will just automatically sort of do the right thing for you. So anyways, it has a pretty simple philosophy. Number one, we wanted to use the standardized tools and techniques from the get-go, so no private API calling, no buffer overflowing to get privileges, nothing like that. Not that I think there was a tool that did that, but we wanted to build a code in language of choice. We didn't want you to learn some silly programming language like Ruby just to do something. But if you used Ruby, we wanted you to be able to use it to write Appium tests. We also didn't want to modify the application under test, and I think most of you who work in testing know that that generally is going to give you different behavior in one way or another from what your customers will actually see. And it's just sort of like this thing sitting out there that one day someone will have the debug flag set and then ship something and then you open yourself up to all sorts of bad things as well. And then lastly, we wanted to keep something free and open source. We didn't want Appium to be for the rich and the wealthy, we wanted to be for the people. So I'm going to talk about a bunch of different lessons I learned working on this, and so the first thing I'm going to talk about is the growth of Appium, and to talk about the growth, we kind of had to talk about where it all began. And it was actually a long, long time ago, I think seven years at this point at a Selenium conference far, far away in London. What I'm going to show you here is Jason Huggins, who you all may know, is almost killing Appium. So here I'm about to give a lightning talk about Appium. Oh, I need to plug it in. Nine. Eight. Seven, six, five, four. All the gods must have been watching. Three, two, one, ready, go, start. All right, I'm here to talk about the native app driver. It all came and it all worked. And the rest is kind of history. So from there, from the Selenium conference, I did a lightning talk about it. There were exact words Mark used to use the reaction, but suffice to say people were underwhelmed with it, except one person, which was Jason. And so he invited me to a bar like six months later after telling me nothing. He just called me out of the blue. I don't know where he got my phone number. It's kind of creepy, but we're friends now, so I'm going to let it go. He just called me up and said, hey, meet me at this bar, bring your laptop, show my developers that thing you wrote. So I showed him that thing I wrote. I'm going to talk about it in less than a second later. But eventually I showed them a Python version that I prototyped it in, and then they kind of went away with it and didn't talk to me for a while. And then the mobile test summit came, and this was kind of a summit where all the big automation tool makers came together, and the idea was to get the community together to sort of solve the mobile problem. And so I brought my thing. I was thinking I'll show it to people, but then I met all sorts of really cool people there, like whatever the guy's name that makes Sikuli. I can't remember the name as well, the tools have been too long. But everyone who was anyone in the mobile automation space was there. And so I showed my demo, and people were like, oh, okay, that's kind of cool. And then unbeknownst to me, the good people at Sauce Labs at the end of the conference showed it working in their cloud with the name Appium, and sort of the rest is kind of history from there, but we'll kind of get into it a bit. So I guess the most important thing when you have something cool, a good idea, is to tell people about it. Jonathan and I would at 7 a.m. in the morning every day read all the questions on our forum and we'd answer them. And this is really important, because when you have something new, people need help with it. And they need qualified, smart people there to get help with it. And when you're new, you don't have Google to index all of the answers for you, or Stack Overflow or something like that. So you need to actually be the one that answers that. And Jonathan and I did that for about a year, year and a half. We literally answered every question, even if it was to say I don't know either. We also spoke anywhere that would have us and also to get into that in a second. We had a clear mission and philosophy from the get-go, which I think is really, really important. Whenever you have disputes within a project, it's nice to have already agreed to something that shows that I'm right. And so that was really helpful. We also talked to any companies that were interested. I think I got an offer from some company in Florida for like a few thousand dollars to buy it. I emailed them back just out of interest and then they never got back to me. But anyways, Appium could have been sold for like a thousand dollars on real story. And I guess lastly, someone went to social media and created a Twitter account. I don't know who it was to this day. I think it was the Sauce Labs marketing people. But no one knows actually. But it's in our control, don't worry. So like I said, the next part of the story is the part where we go around the world to anywhere that would have us. And I've sort of put flags to sort of name and shame the people involved in this. But yeah, Jonathan and I spent lots of our vacation time. I spent probably three years worth of vacation time that I didn't actually go on vacation. Just going to talk about Appium. Jonathan did something similar. These are sort of my shots. Jonathan has a probably more posh set of locations that he's been to. But nonetheless, it was a lot of fun. So we went to anywhere. We even went to some strange places. The one on the upper left, this was this military-themed conference where there was actually a costume code. And so I had to get dressed like a general, which I'll show you in a minute. I think Poland actually is punching above its weight in this deck. There's a lot of China, a lot of Russia, but those are big countries. But I think there's like seven shots of Poland coming up. So I don't know what it is about that country, but it's very interesting. You see, there's some people discussing something. There was like an art auction going on at the same time as our conference. And there were like Mer people behind us. I don't know. There was actually in China, there was like a raffle going on. And they were giving away prizes and throwing away large stuffed animals while Jonathan and I were talking. I think just to keep people awake. I don't know what's up with that restroom in Portugal or that gnome with the butt plug in Holland. Or if you have an all-you-can-eat buffet and you want people not to eat a lot, definitely put that wallpaper next to the all-you-can-eat buffet. Nothing was really beneath us. As I mentioned, I wore costumes. Jonathan entertained people like a common busker. I even pet a sheep in Russia. But honestly, all it really took was free food, right? So, you know, giant kebab. I think that tiki drink, that's a real like taxidermied bird on there, which is a bit weird. Anyway. Yeah, and a flight to somewhere exotic. So just food and a flight. Or, you know, it doesn't even have to be that exotic. Actually, I'll go back. You know, these are nice places. This is Chernobyl. That was also fun. I totally recommend it, by the way. But anyways, actually a tram will even do it. Here's Poland again. So this was a mobile conference and they thought they needed a mobile party. So they rented a tram, filled it with booze and speakers and people, and blasted the music for four hours without a bathroom break. And then when they finally gave us one, I don't think that was a bathroom. I think that was someone's house. But nonetheless, we went a lot of places and the whole point was really just to sort of experience new things. Like when you go to a country where you don't know which bathroom is yours. Though, good case for deductive reasoning. I assume the dirtier one was the men's and I was right. And if you're ever in Lithuania, the up arrow is the women's. The down arrow is the men's. And we also took a chance to learn from others. Taking completely out of context, one wouldn't know anything about the way Simon thinks. Anyways, moving on from the slide show that you awkwardly show your family at Christmas. The interesting thing about open source is it's not like working at a company. When you work at a company and you do good, they sort of give you more responsibility. Open source is the total opposite. Like the better you do, the more people that get involved and sort of the less control you have. And at first this may be alarming, right? But you realize it's a good thing. So in this case with Appium, one day a website and a Twitter account showed up. I have no idea who did it. One day someone made a pull request to add Android support. Never really a goal of the project as the tools Google had were quite usable, but nonetheless cool. One day the project ported to JavaScript and just simply outvoted on that like 6-2. I didn't know JavaScript, but what the hell? People want to write my project, so awesome. At one point I lost the commit bit to the repo as back then GitHub had either admin or not admin as privileges and someone was made admin that didn't know who I was. And then like a month later they're like, who is this guy? And they just deleted me. I think that's what happened. I hope it was nothing more malicious. I've got it back now if you need anything sort of like slipped under the rug for Appium to buy me a drink first. Anyway, and then I guess lastly I had a conference proposal rejected and I was like, it was the perfect conference. I won't say which one it was, but it was like totally relevant to what I was doing and it was in like a nice tropical location where I wanted to waste my holidays for work and they rejected me and then so I emailed the guys back saying what on earth? Like this is perfect for your conference. Can you reconsider? And they said, oh we've already accepted two other Appium talks. And I was like, I didn't know Appium had two other users. Like that's really cool. So anyways, it's a bit different than the real world. My day job. I would never look at losing responsibility as a sign of like doing well. Pro tip to any of you out there who need career advice. Also scaling becomes a challenge. So eventually you won't be able to answer every question. So when it was 20 or 30 questions a day, Jonathan and I could spend an hour and a half answering them. When it became hundreds of questions a day, that became problematic. And I guess I'll talk about sort of a strategy for doing that later. You also won't be able to look at every commit. Eventually there's just too much going on for you to like actually look at it all. So I recommend unit tests for that. So if you have a nice unit test policy, unit tests will tell you a lot about the quality of what's going in there I think. Because generally people who make bad quality code don't know how to write unit tests. Also you won't know what's going on. And release notes and commit messages can be very helpful for that. But anyway, another interesting sort of deviation from what is normal I think is how you deal with conflict in an open source project. So normally like at a big company, there's like a chain of command, right? Where there's someone in charge and if you disagree with me, you just talk to my boss and that sort of thing. But it's not necessarily the way it works. You kind of have people with commit privileges and that sort of thing. But when they disagree, there's really no higher power to go to. And so I found that having the philosophy was a bit helpful for that. I also found that having the fights out in the open was helpful because then people sort of came to a shared understanding of what was going on. And people became sort of more informed with what they're arguing about. But sometimes it just came down to, well, no one really else has time to do this and here's a patch that works. And it's like the third of the 10 options on your list. And so you kind of just let it go. But also losing contributors is not bad and there were definitely sort of more important decisions where compromise was really not an option. But the nice thing about open source is they're still going to do free work for someone. And if you're interested in it, you can still look at it and use it. Multiple projects doing the same thing isn't also a bad thing. From choice comes about innovation and having a lot of options is good for end users, especially when they're all free, I guess. So in the end, you just have to trust the most awesome thing will win and sort of let go of it all. So in general, this side seems kind of stupid now, like seven years later. But for someone who had worked at Microsoft where open source at the time was like a dirty word, like I think you might get fired just for saying the word open source. And now that Microsoft writes their own edge driver and their own Windows driver. But anyway, don't use proprietary tech. I initially wrote Appium in Python, but then I converted it to .NET to work better with what I had where I was working. And if you want to start a .NET open source project, you know, it's 10 years ago, you weren't going to find a lot of people doing that. So I was sort of trying to blaze, trailblaze a bit too much there. So try and use open technology, so languages like JavaScript, Python, Java, open languages. I used to email people around code for stuff. GitHub is a much better place for that. I know this sounds stupid. Documentation is helpful. Putting my slides up is helpful, and I'll post these probably. Though I don't know how helpful these would be. This talk is like totally useless. This is like the keynote, right? I'm just supposed to like entertain you guys and set the mood and sort of like relax you. So there's not many code snippets in here, other than those ugly ones I showed you earlier. And then lastly, post all your responses to Google, read them, Google will index them, and you'll get a lot less questions, which will be helpful. So as we evolved, it started out as I want to automate iOS applications like automate things with Selenium. I like Selenium, so let's just add a web driver client for UI automation. And then it became, well, maybe I don't just want to automate iOS applications. I want to automate all the mobile applications. So we added the Android support and we moved it from being sort of a different version of the client server that then talked with normal Selenium clients. But then after that, it sort of was like, well, it kind of caught on. And people were like, well, automating Windows and Mac sucks too. Why can't they just be like Selenium? And we realized it wasn't actually a lot of work to like sort of wedge in like mobile application support. So it actually wasn't that much more work to wedge in Windows and Mac support. And fortunately Microsoft did all the work for the Windows and then for the Mac, I did a lot of it. Mac support is like, you know, I wrote it like four years ago, it may not work. But in theory, someone could pick up that project and make it viable if anyone wrote Mac apps anymore. Then this idea was proposed, the Star Driver vision. Well, what if I could automate everything using the WebDriver protocol? So we had no trouble wedging Windows and Mac and Xbox and all these other things in there. Why can't we just automate everything with the WebDriver? Simon's already scared by this. The thinking of the meeting is the W3C to automate everything. I don't know if you heard that. Anyway, but now it's sort of like we're in year seven of the project. We have hundreds of contributors, hundreds of thousands of people that use it. We've got over 7,000 stars on GitHub. We're inching up on the Selenium project. I think you guys are at 9,000? Don't know. We'll change the conference name and get the star count. It's going to happen. But I think we're making progress at this conference. I think I'm the first Appium person to do that. Am I right? Or has Jonathan done one? Yeah, I've been on stage, too. Anyway, we're at a good point in Appium-Selenium relations that we have so many talks at this conference. And we had our own conference, actually. I'll show you a bit from that later. Anyway. Anyway. So where are we going with Appium? So, as I mentioned earlier, this is sort of a community-driven project. There's no rigid chain of command. One could tell us where you're going. So this is my version of where we think we should go, where I think we should go. And it kind of starts back to the future a bit. So bear with me. That movie was released here, right? Like, you guys know about this movie. Oh, okay, good. I was worried about this. But you know about this guy. Does anyone recognize this man? Jonathan? If I had something to give away, I would give it to you right now for that. No. No, it's an Italian man named Guido Di Arezzo. And do you know what this man contributed to society? It's right behind him in this photo. So he's the one that came up with a unified form of representing music across every different instrument. And so you can think of musical notation as similar to what I'm going to propose here for a star driver in Appium. The composer doesn't know how to play very many instruments in the orchestra. He may know how to play the piano. He may know how to sing. Maybe he knows how to play the guitar. But he certainly doesn't know how to play the bassoon or the oboe or the recorder or the clarinet and nothing like that. But he knows how to control them with what he writes and what he gives people, right? And he sort of knows what each instrument can and can't do. So he basically says, I want that sound to happen at this point in time. And that's sort of his extent of that relationship, right? He doesn't need to know that that involves like pressing the tenth button and blowing through it some frequency or something like that. Or that involves finger on the tenth string or nothing like that. And that's the way automation really, really should work. So what if we were to make a web driver for musical instruments? Just bear with me. I hope you don't do this at the W3C meetings. This would be a nightmare. But you can think of a piano as sort of like a kind of thing you could automate. And it would have certain capabilities. So it has a phonic range, right? It's actually A0 to C8. There's 88 keys on it, right? You can play all the tones at once. I granted with only 10 fingers, maybe more like 12 or 13. You can't really bend the pitch unless you stick a wrench in the piano. So I'll say that it doesn't have pitch bending. And it has a sustain sort of all on, all off. But immediately you're seeing some things here. So the way web driver currently works with its capabilities, you can't represent some of this stuff necessarily. So look at a guitar. You can only play six notes at a time. A string can only produce like one of 25-ish tones. And some fingerings aren't really possible for people to do. And certain notes can't all be played at the same time and that sort of thing. But how would you represent that sort of, if you were representing a range of notes you could play? It probably looks a lot more like a lambda expression or a function or something like that. Which currently isn't supported in capabilities at all. Piano also has sustain, but there's several different configurations. So there's the sustain pedal, which will sustain all of the notes. There's another one called the sustenuto pedal in the middle which will sustain, I believe, it's only the lower half of the notes and only the ones you've played when you hit the pedal or something like that. And then there's another one that just sort of makes all the notes quieter, but that's not really related to that. Anyway, so how do we start representing this complexity in automation? And I think, I'm asking a lot of questions here. Like I said, there's nothing useful in this talk except a lot of questions. Or each finger, each foot, like how does it work? I actually don't know. But anyways, we're not actually trying to do music with WebDriver, thank God. We're trying to do, I want to automate everything the same way. So using what we learned from creating Appium, we know that automation is highly generalizable across many different contexts. As you've seen with several things here, we do web, we do native, we do all sorts of things with Appium. And there's really not that much difference between Appium versus Selenium. Anyway, so getting ahead of myself, Jonathan's, you know, taking the lead on this. And at Appium conference this year, he put together a BAM, which is all being controlled by Appium. And this always answers the can you do multiple devices at once question. I like to use this. We have a lot of you on this. This sounds, trust me. I believe things I've heard. Those I've said are better, sir. Scanning my whole brain. Anyway, so sort of taking that a bit literally now, like what does this look like? And this is what I'm going to finish the talk with a bit. So there's some quirks of Appium because it's based on WebDriver. So number one is we have the idea of WebElement, which is kind of overridden with this mobile element thing. But nonetheless, it's sort of a weird thing to call if you're going to automate anything, call something a WebElement or a mobile element. It doesn't really make sense. Element.click. On Appium we don't click things very often, as most of the things we support don't have mice. Getting the page source is sort of a Web concept. XPath is an XML concept. Driver.executeScript is also kind of like a JavaScript Web concept. And things like browser.windows, like that. So what do they look like when they can't abstract them or generalize them a bit more? So maybe WebElement, maybe that's a UI element now. Maybe clicking is something more generic like pressing. Maybe instead of page source, we're really talking about like the UI hierarchy. Or XPath is really just like a search expression, right? And so forth. Like I said, I don't have the answers. But thinking about it at a higher level, how can we think about automation for anything? So devices have operating systems, right? And operating systems have applications. They have outputs. Applications have user interfaces, and user interfaces have elements, right? And you can manipulate those elements with the different inputs and outputs that will really the different inputs. And then you can sort of perceive that on the different outputs. Also, devices kind of all have different capabilities. So in the case like hardware buttons, volume up and down, devices also have the ability to turn them on and off, that kind of thing. But an operating system lets you do things like launch applications, check if they're there, set the date and time, access your inputs and your outputs, execute a command. And at the application level, you're talking about things like settings, user interface hierarchy, and so forth. Inputs and outputs, press gesture, get screenshot of a graphical interface, use the mouse button, type on a keyboard, speak into a microphone. What we're trying to do here is sort of separate like the actual code and the application and the device from the things you use to control it. Because as you've seen in the new world, we have all these different ways. So you can have AirPods that are the microphone to your phone, or you can have a robot that's actually using your finger or so and so forth. Anyway, let's take a look at an example. It's a bit abstract. So an iMac is a device. An iMac uses the Mac OS operating system. Mac OS has the Firefox application, a mouse, a display and a keyboard. And the Firefox application has a user interface. It's a web-based interface. Or an iPhone. It's a device. It has iOS as the operating system. That has Facebook as an application. And Facebook has a user interface. So if you look at it like this, it becomes a lot simpler to sort of make something that can then work across a bunch of different things. Now, I won't get into the question of like, if you're doing end-to-end automation across like 10 kinds of devices in a test, you probably should rethink the way you're testing it. But nonetheless, you shouldn't have to learn something new to automate a new kind of device or a new category of device every time one comes out. Because as you've seen, new things are coming. I don't know what they are, but they're going to be new things. And how do we deal with them? And also, how do we deal with things that talk to other things? So like Bluetooth headphones or wearables or so forth, right? So anyways, I'll skip the robot slide. Anyways, it should all really be a plug-and-play. With adapters for any device or operating system, you can really automate anything new. And if you made it a spec, then vendors could implement it, and they could give you a device off the shelf that would be automatable out of the box, much like browser vendors do now. So I guess what I'm really getting at is a world where something new comes out and I can automate it on day one and people don't have to like work on open-source projects to do that. There'll just be people sort of working on committees trying to iron out the specs for what that looks like so that they can all play nice together. Not that I haven't enjoyed working on Appium for the last six years and not that I think a lot of people don't enjoy working on Selenium, but if you think about it, the right way for this to be done is sort of by the people that make the things. Or at least I think a better way of getting it done is that way. So anyways, I have a little bit of time left and so I have a really long takeaway section here. So the most important thing I learned is that developers want to develop their way. They don't want you to tell them what to use. So you should always be open and inclusive and try and support as many kinds of development as possible. Let them use their programming languages. Let them code the way they want to. Appium is largely successful because it was based on something that people wanted to do. Selenium is something people chose to do from a number of different tools for websites. And obviously I don't think most people looked at like how it's a mobile device. Everything I enjoyed for web is no longer enjoyable to me. I don't think anyone thought that. And that's, I think, the largest contributing factor to the success of Appium is that we based it on something popular that people already knew. So the barrier to entry was non-existent. You know how to automate a website. In two minutes, I can show you how to automate an iOS app. So like I said, be inclusive. So we support all these wonderful languages. Ruby's on that slide, I'm sorry. We support all of these languages. We support these lovely operating systems. From a long time, we've had documentation in English and Chinese and the site translated into a number of different languages. And I went to a lot of interesting places to talk about it. Jonathan, once again, would have a much cooler slide with much more tropical destinations, I think. But nonetheless, it's been good. It's been a lot of fun. So I've learned a few lessons from this and that's more what this talks about. Like I said, I'm not here to teach you anything. There was already an advanced Appium workshop yesterday, so there's nothing I could teach you up here that wasn't in that. But I can sort of share with you what I've learned in the last sort of six years working on this. And number one is share your ideas as often as possible with everyone. Even if they involve horrible hacks like the one I show you. And I guess sort of what comes from this is like sometimes the least bad idea is the best idea. I think by definition, the least bad idea is the best idea. The initial version of Appium was definitely a least best or the least worst way to do something. Also listen to everyone else's good ideas as they can really come from anywhere. And I mean that is like, I was just a guy at a dating site who had a boss that was yelling at me because our app always broke when we submitted to the App Store. I don't work at some fancy company or I didn't work at some fancy company. Like I'm not the kind of person that's like having cars drive around cities without people in them or landing rockets on boats or whatever cool shit they do at SpaceX. Like that's not what I did. I worked at a dating website. Like literally we just take people's money to let them chat with other people. It is not rocket science. So anyway, good ideas can come from anywhere. Also try and be as inclusive as possible. So to this date, I'm not sure I've ever said no to a conference for a reason other than a scheduling conflict. So I never said no to go anywhere. I tried to come here but the government wouldn't let me. So I encourage you, don't close your mind to things. The world's a much nicer place than you've been led to believe. I don't know about India but in America we're sort of taught that the rest of the world is crazy or it's dangerous or it's unsafe. And even in Europe I sort of hear like oh that country's like no go or that kind of thing and I have yet to find anywhere really like that. I'm sure I could if I really really wanted to but nowhere that's hosting a conference where the Selenium is that kind of place. And maybe that's a tribute to the Selenium project. Maybe it's like the world's peacemaker. I don't know. But anyways, the moral of the story is it's a nice friendly place out there despite what you've heard. And then lastly, never say anything bad about anyone in public. Especially if you're being recorded. The world is... So I'm being recorded today. If I wasn't being recorded and if none of you were here this would be a very different talk. I tell the story about the time I flew 12 hours to go to Australia from or 14 hours from San Francisco and literally 12 people came into my talk. And I was having a week where someone had said something bad about me and someone else on the Appian project. And then I intern at my time my big pulpit. I said something bad about this person. And lo and behold one of their good friends was one of the 12 people there. Never mind that this person is not from Australia or anywhere within like eight time zones of that. So anyways, lesson learned. Always be nice. I also will give you sort of more philosophical quote from Steve Jobs who said, I used this one last year but I'm using it again. Life can be much broader once you discover one simple fact. Everything you call life was made up by people that were no smarter than you. You can change it. You can influence it. You can build your own things. Once you realize that, you'll never be the same again. You know what this basically means is have no reverence for the people that came before you. So everything you've heard at this conference take it with a try and buy attitude. Treat it like shareware if anyone remembers what that was. Use it a bit. It works for you then invest in it. But what I'm telling you is that this is a conference where just because we're up here speaking doesn't mean we're experts at anything and that you don't have better ideas. So I'm going to I would encourage you all to go and share your ideas with as many people as you can. So work on open source. Publish blog posts. Go talk at conferences. Call your mom and tell her about Appium. I don't know. Make a better project. I've had a good run. I've got to go to some good places. I make no money on Appium. There are no children that will starve if one of you creates the Appium killer to be a lot better, to be honest. So what I'm saying is don't be afraid to try things and share them with people and fail. I lucked out in that I had one good idea and six years later I've gotten to go to a lot of fun places and we now have a working solution for mobile automation, which I guess is more important. That being said it won't always be like that. Your mileage may vary. I've had other ideas that have been less successful. Some before Appium, many after Appium One of them might have been this presentation today. So anyways, don't let that scare you away from persuading and if you see something out there question it. Take it home, be a skeptic just like you would as a tester. And if you find something that you don't like or that doesn't work for you it's probably a bug and you should come back and you should fix it because that's what you want done with your bugs, right? As people who log bugs, you'd like it if someone went and fixed it. So please come and fix it in general. Just test everything and that is it for me. I guess we have five minutes for questions. Indeed, you have six minutes for questions. Six minutes for questions. All right, your lucky chance. Hi Dan, it's a wonderful it's a wonderful presentation actually. And this is the first time I'm seeing Simon Stewart and Dan together. It's a very good, very pleasure moment for me and I have a requirement kind of like it's a payment kind of app. It has to generate a random number, a kind of pin number and it will be transferred to the watch, iWatch, and it has to be captured again by the user and it has to be pinned or voice over by the user to the iPhone and it has to be approved for the payment gateway. So can we control both these two devices in a single session via Appium? I believe Appium currently supports the Apple Watch so the answer would be no. But in general with this vision I presented for a world where everything is automatable out of the box then you could. Okay, thank you so much. Was it an Android Watch? Because then I think it might work actually. Oh yeah. Hi sir. One small line about my life. First time in my life I am seeing two gods, one is Simon and one is yourself. Because from the last four years I am following Appium and I am providing training to university students and all and Selenium and Appium. But recently I saw that video, guitar automation using Appium. My wife asked me one question when Don and Simon can go to work on washing machine automation using Appium? I heard washing machine and Appium. Home appliances automation when they can try. Because every husband is saying I am in automation I am in automation, I am in automation house so every wife is asking when you can automate my house related things. Oh okay. Also another maybe we should get the house wives on board. Thank you. I didn't even think of this. Or maybe you should do the washing. Or you have children right? They need to earn that allowance right? Basically he is trying to avoid washing so he wants you to automate his washing machine. Cool. Any other questions? Going once. Hi, I am Mahesh Kulkarni. In one of the slides I saw about Viniyam actually. Since I am from Windows world I am interested in knowing what will be the progress in Viniyam world. Viniyam is the one of the framework that you run on Windows desktop machines right? So I wanted to know. What is the progress of the Viniyam project? I don't think I had that in my slides but Microsoft makes something called WinAppDriver now which fulfills most of what Viniyam did. Viniyam will support some older versions of Windows that aren't supported by WinAppDriver. But the project has sort of been replaced by the official one from Microsoft which as awesome as the Viniyam project was and the cool guys that worked on it in Russia. I think it's the right thing to have the actual vendors themselves building it. So to answer your question github.com. Microsoft. WinAppDriver will work for all Windows apps Windows 8 or later I believe? For phones as well. Didn't Microsoft kill their phones like several years ago? They killed actually. Now Windows 10 is the operating system for both phones. So in that case WinAppDriver will work with that. Is it open source or? So it's on github but it's not open source because I don't know if they've actually open sourced the internals of it yet. I don't believe they have. So you can download it and use it and there's some stuff on github but in general it's not fully open source or it wasn't last time I looked at it. So yeah. Last question. WinAppDriver from Microsoft so it's only with .NET works with .NET languages? No, it will work with even WinForms and WPF and WinJS and all those old ones. VBScript based like anything. Thanks. One last question and then we have something. I just missed one more question. I'm just following this Appium Studio and what is the huge difference between Appium Studio and this Appium normal version? Appium Studio are you referring to the Appium Appium client like the GUI that records stuff? Yeah, the new one Appium Studio it's controlling kind of multiple devices and all. I haven't seen it yet. I wouldn't know much about it. We have a GUI now that we release it's written in what is it, an Ember or something? It's a JavaScript thing and it runs on Linux and Mac and Windows. I'm not aware of I don't know anything about Appium. It's developed by Xperia Test. Oh, it's a paid thing. Oh, okay. So how are we just getting I don't think we should dedicate any time at an open source conference to a paid product. So I think we should sort of Oh. But feel free, XperiaTest.com maybe? I don't know. If it gets you using Appium, I guess fine. How Appium is good in automating the apps developed using AngularJS? There is a talk by Wim cells on that exact topic. Isn't there at this conference? Am I not mistaken? Oh, it's React. It's not Angular. I've done a little bit of that not in a while. I can give you a two or three year old answer and that it was sort of buggy before because there were some things in the Angular logic that Appium sort of threw off and Selenium didn't work with Appium. I don't know the latest on that specific scenario but the message board is a good place or the form is a good place to start with that. Or maybe ask Wim. He's like an expert on React. I'm sure he probably also knows something. Is he around? Oh, he's right there. That guy. I think we have reached our end. Thank you so much for inviting me. It's been a pleasure to come. Enjoy the rest of the conference.