 All right. Anyway, so where I have to introduce all the people on this panel. So this is the Committers panel where you can ask us anything, literally anything. We have to answer it. There are nine people coming up on stage. I'll introduce them very briefly so we have more time to ask them questions. If you don't know which one you want to ask, just send it to me and then I will delegate accordingly or take it myself. So first, from Sauce Labs, Bruno has worked on some Android stuff and Appium, so he may be able to answer some Android questions. Next, Christian Bram and also from Sauce Labs, web driver IO creator, sort of Appium related. Awesome product. Dan Graham works on the Espresso driver for Android, Android Appium desktop. Jason Huggins has succumbed to jet lag, and so he will not be here, but I did not leave an empty chair for him in case he wakes up. Next we have Jonah. Where's Jonah? Jonah. Oh. Jonah's. John. Yeah. All right. Well, perhaps in his place for now, Justin, come on up. Come on up. This is Justin Eisen. His contributions to Appium are varied. You can have Jonah's chair until he shows up. Next we have Kazukai Matsuo, who I believe has done the Appium Ruby bindings and the TVOS support and maybe the Swift bindings as well. All right. I got that right. Next we have Sai Krishna, who has worked on the Java bindings. And Srinni, where's Srinni? He's also worked on the Java bindings. And then last but not least, my partner in crime, the one and only Jonathan Lips, who is the architect of Appium and the reason why people can contribute more easily than they were in the past. Good. And then I'm Dan. I created something that Jonah's coming. All right. So Justin, don't get too comfortable. Okay. It's like Hollywood. We have seat fillers. Start. It looks bad on TV if the seat's empty. All right. All right. I don't need this anymore. So you're welcome to raise your hand and we'll pass you a microphone. While you're thinking of your questions, I guess I can start off with one question and I will let everyone answer this. But please, we don't want to get too many questions, so a minute tops or less. Tell me about the worst, nastiest piece of code you've ever contributed to Appium. So Appium is a product where in order to work around vendors, insufficiencies and things, we have to do things sometimes that aren't precisely kosher, let's say, in order to accomplish tasks. So I guess I will start and I will say that there was a piece of Apple script in the initial version of Appium that typed in your username and password whenever a username or password prompt showed up, which made Appium not great for security, but did make it work when you needed to authorize Xcode to access things. This is a hard question because I've written an awful lot of code for Appium. I'm trying to remember what the worst was. You can go last. We can start with that. Let's think about that for a while. Let's start on the other side because Jonathan is going to need to catalog things in his head. I had to unlock the pattern for Android emulators. I think I'm the only one understanding that code and I think it's broken right now. No one else can fix it. So mine is less code related, but image related. When I started working on Appium to get an overview about the project, I created, you know, this diagram where I put all, like, all Appium packages and how they are connected with each other. And I ended up drawing a lot of lines that at the end didn't, you know, help you to get an understanding, but it helped me to understand Appium, but it's still an Appium and I think, yeah, you can find it there. Yeah, at the top of my head, I think the hackiest thing I can think of that we did is we wanted to support Touch ID in Appium on iOS simulators and to make that work, we actually had to resort to using Apple script. So that was really unpleasant, but probably worth it. Two points for Apple script already. I was just talking about the hackiest thing. Well, hackiest or nastiest pizza code. The nastiest pizza code. You've committed. Oh, but I've committed? But you've personally committed. We can move to cause you if you need to. Probably there was some earlier stuff like before, like before we did the rewrite to async await stuff, where probably just like, I was like, probably there was an error and I really didn't like the error code. So we'd be like way deep somewhere in the process and you didn't know, I didn't know all the, I just started, I didn't know all the callbacks it would take to put the right error, like to come out to the top. So just from the very bottom, I would just like throw an error, but put the whole HTML result in the error code, then just like catch it at the top and return it. Worst code? Worst code is a straight touch ID in the XCR test because the framework doesn't provide such an API. So we must hack and the action also have many limitations. So we, maybe we must continue to hack, hack, hack for the other framework. With the Java bindings, after Jonas left the Java binding when I got in, I mean, I was the king for that. So probably a lot of interfaces. So Java binding is just interfaces, interfaces. And I was having a chat with Jonas, like, why the hell do we have so many interfaces? I know. Yeah. No, no, no. Backward compatibility with JSON wire protocol on the client side, Java bindings. I'm still struggling to think of what the worst thing was, but I would say that actually the original hack that made appy impossible, which was basically, with Apple, they gave us this one command that lets you run essentially a shell command from within their automation framework. And what we did is, it was slightly less hacky than the original thing, but basically we used Unix sockets to pass blobs of text from the Appium controller into this Apple test process by using Netcat on the command line from this little thing. And then we would eval it using JavaScript's eval function, which, as everyone knows, you should never, ever do in anything approaching production. And that was the very core piece of Appium and the only way that it could make it work. So that was definitely the biggest hack. And thankfully, with XCY tests, we no longer have to rely on that. Isn't it also like between the messages were plain text, but it was a sock with a stream in between the messages to mark where one message ended and the next one started? Wasn't there like just five lines of astrocysts, astrocysts, astrocysts? Oh, no, that was because, yeah, because there needed to be, the messages needed to be a certain length in order to flush out some element of the Apple reading the process so that it would actually return it. So we just, it was like star times 1024 or something like that. Right, right, right. Just bunch this up. Yeah. Yes, we actually looked at it. It would just be blobs of stars with the message now and again. All right. Please raise your hand if you have a question and there are rovers with microphones roaming. As we're still waiting for our first question, I can think of another terrible, oh, there we go. Thank God. I don't have to tell people what I did to the C-sharp bindings. Hi. I just want to say that I usually do the same thing. I see it in the committers panel for a Selenium project and I see more diversity here, which is something that I would like to highlight. So I just want to ask you, what have you done to, I mean, it's still only men. We have to improve that, but you have more diversity than us, which we're mostly Caucasian guys in the Selenium project. So what have you done to achieve that so far? Have you actually thought of that or what just coincides? I don't think that we should really be congratulated. Well, maybe there's more diversity than Selenium, but I still wouldn't consider our committer base that diverse in my opinion. So I don't know. I guess I wouldn't say that we've done anything good. I think we haven't done anything particularly intentional one way or the other, which is probably a bad thing. So I don't know if anyone wants to make a different point. I might take this. I mean, I take the point you're making. I guess what I feel like, and this is kind of, I can tell my C sharp binding story now. So when the project first started, I was writing the C sharp bindings. And there were fields in the classes that were private that for Appium I needed to override and they were private. So you can't do that when you make a base class. So I needed to just mark them protected with all I needed to do in the Selenium code base. And then the C sharp driver, I could do what I needed to do. And I actually had one of my underlings open a pull request to Selenium, send several emails, several tweets to people, and no one looked at it. So finally we used reflection to insert values into those fields. And that was in the C sharp bindings until maybe a year or two ago when Jim Evans found it and saw the code and sent me a very loud tweet about how wrong it was what we did. We sent him a link to the pull request showing that we tried to do it the right way. But I think one thing that we do is that we're very responsive and collaborative and we have a very good process for reviewing things quickly and not letting pull requests stay stale and that sort of thing. And being more active does encourage more people to join. I guess having more people eventually you'll get diversity out of just like large and large. Yeah, I mean we put a lot of effort at something that we've talked about as maintainers when we've had the opportunity to really help people through the process of contributing no matter who they are and to kind of, especially if it's their first time to hold their hand and maybe jump in on their pull request and write code with them and not just say, well it doesn't meet our standards and therefore we're going to close your PR. Sometimes we actually get in there and write the code that will help it get over the goal line so that they can get that contribution and that is really motivating and inspiring and I think it does help open the door for people that might be a little more intimidated. So we're doing stuff like that. Yeah, I mean in general as an industry and as a project it's not super diverse but that's kind of sadly part for the course for a lot of these types of things right now. And I guess I should say if any of you have ideas about ways that we could make the project more inviting and more open. I would love it for it to be more diverse than it is. I think we'd benefit from that. So please let us know, certainly open to talking about that. And speaking of encouraging participation, please participate. You're all invited. I really think our community, especially in GitHub, is really as friendly as we can be. Even on days when I'm having a really bad day, if I'm answering a GitHub issue or going on a pull request side, really I set aside all of my own personal grumpiness and I'm like, all right, let's do this. And we'll really, we never close an issue on Appian or close a pull request because we, due to keeping out that sort of addition, right? Like the only time we ever close a pull request is either it's merged or someone has opened another one that does the same work better or in a different way or to receive the same feature or the person most often has just gone kind of unresponsive. But we do a lot of like, come on, are you still here? Like you can keep coming. So all of you are very welcome, like please submit your first pull request and no one has any judgment on you. But you don't have to feel like it's really like when you put something online like that, like especially like on GitHub, sometimes you feel like the whole world is watching. But like, I'm sorry, like actually, you know, like, you know, Appian is not the biggest thing in the world. We all care about it a lot here. But most part just, yeah, just try it out, put it out there and we'll really help you like make sure that your code gets in there. And we're willing to explain it as many times as it takes to, you know, figure out how to get your contribution into the system. Next question, unless you have. Yeah, just want to emphasize what Jonah has said. From my experience throughout my career, everything where I am right now, I thankfully got it through working on the WebDivo project. Like I approached or a former head of engineering from Saas Labs, like four years ago, and he got me this internship. And throughout some other things, like the OpenJS Foundation, all the things I was able to participate in standards. And a lot of other things that are not really work related. So from there, I would really recommend everyone to just take an hour or two every day aside or sometimes a week to just contribute to open source and learn throughout this process that can really help to boost the career overall. Next hand, I'm going to have to come up with a question to ask people. There's one. Actually, I want to understand what kind of test cycle you go through. But any new mods, yeah. So what kind of test cycle the Appium project goes through to make it a release of Appium? That sounds like good. Yeah, so we use Travis CI and we use Azure Pipelines to do our testing. So all of the different drivers for Appium, whenever they go through a pull or request, they go through a fairly rigorous end to end testing process and a unit testing process. I would say the coverage could probably be better, but it's still a pretty rigorous process and we go through code reviews, of course. And then, yeah, during what we do a release, we do a release candidate. And we run some tests on that. We release that to like a limited group of people. They try it out and once we've decided that Appium is good to go, we put a bow on it and make it generally available. The average length of testing for drivers varies quite a bit. Some of them it could be done in like five minutes, less than five minutes. Some of them it might take, I think the XUI test drivers are the longest one. That one has about six different parallel tests and on average, it takes about like 40 minutes each. So there's, Justin's got a question, now that you've left the panel. Can I come back up there? You'll have to take down one of us. Yeah, no, that's okay. No, I just want to ask is, has there been any work or collaboration with the vendors like Google and iOS? Have they been more receptive? Well, Dan can not comment about Apple. And in terms of vendors, the two that have been collaborative, first of all, Microsoft with their Windows driver. They're obviously not responsible for Android or iOS, but they looked around at the kind of best in class automation stuff when they were looking at improving their own developers experience and settled on Appium and WebDriver. So as far as I know, that is still working really well for the people that use it. So that's kind of our first feather and our cap in terms of vendors getting on board. And I hope to see that continue. And then obviously more recently with Samsung's Tizen driver that they released, and again, I'm not sure how widespread that is. And whether you all need Tizen automation support. But for those that do, it's officially maintained by Samsung folks. So they're a vendor. But in terms of the big two, I guess I can say that I've had some conversations with folks at Google. And Google is a big company with lots of people and lots of teams that are doing different things and overlapping things and have different opinions. But certainly there is an openness and in some cases a desire to do WebDriver based stuff for mobile. But no official progress or effort that I'm aware of. Sadly. Don't see any, so I'll ask a question. Sure, maybe one for everyone so we can all talk again. Tell me about what you've contributed to Appium that you're most proud of. Sorry. What I'm most contributing to Appium is adding all these new emulator features like the, when you can emulate all the hardware stuff like battery, network, phone call, text SMS. And yesterday in the talk I had the live sensor that I could start creating a lot of VR for you guys next week. That's it. I haven't worked long enough full time on Appium that I could think about something significant, but I would put on my HPVTV driver as like a showcase that you can automate everything with Appium if you want to. Appium desktop is definitely my favorite contribution. I started that over two years ago. It was just, we had worked on it internally. Jonathan and I, and it was exciting to see when it got released how quickly it got picked up and how many people use it and how many people are interested in it. And it seems to have helped a lot of people writing Appium tests. So I'm glad you asked this because I remembered a super hacky thing I had to do and it's also what you're most proud of as well. It's also the one I'm most proud of, but no it is, it is, it is, because it was, I've always, when I was in school I was getting a computer science degree. And one of the topics I liked the most was compilers. And so I liked the analyzing languages and building compilers to take code and make it be other code. And so that was just one of my favorite topics. And then I think it was when I first started as one of the first projects on Appium that Jonathan gave me. And it was like for Java, it was the Android client, the Android driver. And one of the locator strategies is where you pass in a string of Java code, right? And then that, it uses those locators in the native UI automation framework. And this is crazy actually because in JavaScript you can just take any string and do eval and it runs it like it's code. That's not the case for Java. Java does not work that way. But you can still say like driver.findElement by, I forget what it's called exactly, the Android UI Automator. And then you pass in a bunch of Java code. And so I actually wrote like an actual Java parser that takes the code. And it splits it based on the dots or the new lines and the semicolons. And then it makes sure all the parentheses match up. You can do nested like things in that. You can do like new finder, I think. And then it's inside that like next chain window or whatever. And like scrollable UI and stuff. And then so it parses the whole thing to find out what you're trying to do. And then it uses reflection to like create those classes. And then it calls those functions and then it changes the commands. And so I'm like pretty proud of that because it works. I think it only broke like once. And but also it's super hacky. Like you should not do that. Also it's not all of Java, obviously. Like you can't do one plus two. It doesn't do math. It only likes the functions that are for finding elements. But I'm insanely proud of it. Proud thing is maybe restart maintain the recurrent first. Because I heavily use the recurrent. But that was became the colorful maintainers. And the recurrent was the class-based one. It means everything is global drivers. So we can't do run the test parity on the same re-script. We must split the process level because everything is global. So that was a big obstacle to run testing parallel. And that was a big thing for me to be proud for the commitment. And recently is the TVOS or something for the XCU test. Micro, actually he improved the many code. And I read the code. But very difficult, very complicated. So I need to use my brain to understand that. But Michael also very struggle with how to hack and how to make there are some actions available for iOS. So I understand how heavy to achieve that. But that worked also very proud for me. For me, the problem was when we wanted to deprecate the driver dot swipes and scroll two stops in the Java binding. Because it was completely abstracted. And it's acting really crazy. And that's when we wanted to just deprecate that and bring in touch actions. Yeah, that was a problem in to bring in touch actions. And I still see people using touch actions now. Yeah. Just to add on to Sai, there was one moment in time he cleared out all these methods. And these kind of methods internally used touch actions again. And it became super flaky. Yeah. So a couple of the ones that I am proud of when Simon and Jonathan came up with and other folks came up with WebDriver protocol. Simon released the initial version of initial support for WebDriver protocol in Selenium Java libraries. I reported that to Java client. For me, I think the thing I'm most proud of is actually the architecture of Appium that we kind of rewrote Appium several years after we'd started. And we put a lot of thought into the architecture. And I feel like that was sort of my biggest contribution. Because we've been able to stick with that architecture. And it's served us well. And we're not seeing much that we need to change. I think with Appium 2, we're going to add the ability to have some plug-ins or something like that. But by and large, it will just still fit into the same architecture. So that was a lot of fun to do that. All right, for me. Well, contrary to the jokes we always make, I have actually written some parts of Appium, like the old applications, and the old iOS implementation, and everything was old in front of it. And the Mac driver, which hasn't been deprecated yet, but I'm sure my Mac driver will be. But I think my product. Somebody asked for an update. What? Somebody asked for an update. I saw. It took like five years for it to catch on. But yeah, it's like Jason. I'm ahead of my time, right? Now, I think my proudest contribution actually isn't any of the code I've written. It's more just like, and it's kind of cool. I can say raise your hand if you know what Appium is, like, in this conference. And everyone will probably raise their hand. But I do a lot of traveling around. My job, like, I'm not allowed to commit open source in the moment for the last few years. But I've taken on a lot more conferencing and advertising. And I've sort of made myself the unofficial mascot of Appium lately. And so I guess my contribution I'm most proud of is like raising the awareness around. And then now when I go to conferences and I ask, how do you use Appium? It's like maybe a third of the room or like half of the room. Whereas then I ask Selenium and it's always double that, which there's still some work to do. But I know that when I started doing this two or three years ago, I could go to any Dev conference. And it would be 10% of people. I could go to any test conference. It may be a third. I even heard of it. And now I go and it's more. And I guess the story I want to tell is I was in India last year for the Selenium conference. And this is in the interview, if you guys read it. I was walking from the hotel to the venue, which was across the parking lot. And this van pulled up in front of me. And these two women got out of it. And they asked to take a selfie with me. And you know, whatever, we took a selfie. This is India. Apparently this is like a huge thing here. This doesn't happen anywhere else I go. Or at least not more than once. And so then they went. And then I'm still walking to the venue. They've gone in. And then the guy in the van rolls down the window. It's like this 40-year-old Indian man. And he's like, are you Appium, Dan? And I said, oh, yes. And he's like, oh, my daughter's got great jobs now, because they learned Appium. You can come to my house and eat dinner. Do you want to come? And I said, oh, well, I'm kind of busy. Bye tomorrow. But thank you for the invite. I sort of regret not going, actually, meeting this guy. But I always think that someone else would have created it. It actually can tell you his name if you want to know. I won't name him now, but there's a guy who lives in Switzerland who, if I didn't create Appium, probably would have. But it's good to see, regardless of whatever, that the work that all we've done has had an impact. And there are people here that, there are a lot of people employed writing Appium tests full-time, which I think is work that, with the existing frameworks before Appium, would have been too challenging to write or wouldn't have gotten effective enough results to be justifiable from a cost perspective that the business is hiring them. And so it's glad to see that because of the work that we've all done, that a lot of good things are happening for people here. And so that kind of drove it home for me. That strange man, maybe his daughters are here again today. Maybe you guys know who this was. I don't, but anyway, I'll say that. Any questions? Ah, there's one. Last question. That'd be a good one. My question is for all of you, if you could change one thing in Appium, what would that be like? We'll start from the end. If you could change one thing in Appium, what would you change? Maybe we'll start from the middle. Let's start with, all right, Stringy was nice. Maybe I would rewrite the entire Java client. Probably the best thing to do now. And I would pay with him to do that. From WebTable, I know that moving to learner has provided me so much more speed and velocity and development. I think someone similar has planned for Appium. And I'm excited if we get there at some point. I think XUATest is really hard. XUATest drivers really have to maintain. You have to do a lot of hacky things to automate iOS, which is the most important platform. At least one of the two most important so we'll be good if we can find a workaround for that. I think along with what Christian said, I think I would have kept the new architecture of Appium without splitting everything into 30, 40 different repos. I think that's made development a little more difficult as those of you who are in the workshop with us can attest. I think the architecture is good, but I think the way we chose to separate things out, I was a little bit overkill. So that would probably have saved us a lot of time. Dan, Jonah, and Kazoo. I think I would probably add types to Appium. I think that would, like I would still keep using JavaScript, but I would add typings to it because I think that would catch a lot of errors early on. Jonah, Kazoo? All right, I can go. I have a mic. Yeah, I don't need, but Kazoo ready to go. I can change is hopefully make more PR public. I mean, when someone tried to contribute to Appium, then the guy maybe probably have iOS and Android knowledge more to implement Appium. So my making up PR open means that hopefully hopefully engineers who were known the Android and iOS can easy to, I want to make easy to create a PR for the Appium. Yeah, deep understanding is necessary to make test more stable. I think, can I say that I wish Appium desktop were better? Does that count as part of Appium? He's right next to you. No, it's, what? No, it's great. You should have seen what it was before. I can test it. Oh, yeah, yeah, yeah. But what I'm saying is all of Appium is so great, but Appium desktop could like, it could become more of like a gigantic tool, which is way more than that. Yeah, more of like a full-fledged development. I agree with that. I just, yeah, if I had more time, there's a lot of stuff that we would do with Appium desktop for sure. Of course, but that's a whole thing. That's a whole thing, yeah. Man. All right, well, I guess I have to go last. So for me, I kind of go back to the beginning and I would sort of rewrite history a bit and that like, when we started this, I think there was this idea that this was part of the Selenium project and it sort of formed its own project. And I kind of, I jokingly took a shot at like getting things reviewed by the Selenium project. Like that's my one experience. Other people have wonderful experience with them, I'm sure. Not my only experience, but it's like one of a few I've had. But anyway, I think it would be great if like we were in the web driver W3C spec with all of the mobile stuff from the get-go because that was so much fucking work. Like for Simon, it was years of his life and it would have been nice to sort of leverage that so that we were also in that. And I think like we don't have a feud with the Selenium project or anything like Simon and I are friends. We live near each other in London but I think it would have been great if like this was all kind of unified a bit more. But that being said, I think it's worked out well the other way as well. But one day we'll want a W3C certification and I don't know if Jonathan didn't cut his beard between when we started and when we ended, he would look like he looked like last year. Maybe. I guess that's true. Or longer. Yeah, I didn't finish that in my head. Anyway, I think we're done now, aren't we? Unless anyone else? Oh, can we take one more? It's a quick one. Quick one. Yeah, it's quick. Are we to expect a Appium conference in 2020? And where is it? Unlike, we copy much of the Selenium conference format as you've noticed. The part where they announced the next conference at the end is a part that we are, we don't have the infrastructure yet to, you know, to deliver that sort of thing that quickly. So I hope that there's one in 2020. All signs point to yes. But that being said, there's a lot of, like Noresh can tell you there's a lot of work between like the idea and then the event. And so we have not started any of that work yet. But yeah, I hope so. And I believe there will be. Oh, no, I think we're done. How do we keep the work-life balance with an open-source project? I can, I'll take one, if anyone else wants it as well. I guess like, I once had a boss that was pretty lax and let me work on Appium on the clock. That was like six or seven years ago. And you'll notice my contributions have decreased since then as I've had other jobs where I was paid to manage people and do other things. And so I guess when it stops being fun, I clock out. And I think that's how I do it. And yeah, like I said, like I have no children that are fed by Appium. I make no money off of it. So like if I just walked away one day, it's in completely capable hands without me. And I think because of that, I'm able to just like turn it off. But maybe that better question for some of you who actually spends more time these days than I do. I mean, I do a full time for work. So I don't need to balance it off with work and life. Yeah, I just do, I would contribute to Appium as a job. Well, sometimes I just slip two hours of open-source work into my regular work without telling anyone. And it's fine. No one caught me so far. So we'll see. You being recorded, you know that, right? This is going to be live. We can peep my face, right? We'll fix it in post. All right, I think we're actually done now. That was Nuresh. We didn't get Jonathan to answer this. I feel like he spends a lot of time working on Appium. He might be a good person. Yeah, I mean, it's really important to have a balanced life as Anton was saying yesterday. You know, don't do too much of any one thing. Open-source is fun, but it can also suck you in in weird ways and you can get like over emotionally invested in it. So definitely it's important to keep a balance. A lot of people don't have the luxury of their company supporting their open-source work. And you know, don't feel like you're obligated to do open-source work on top of the work you're getting paid to do. Everybody's life circumstances are different and contributing to open-source is not like something that you have to do in order to be a good person or to be a person that's even useful to the Appium community. As Appium users, if you use Appium at work, you can be super helpful by finding bugs and just using it and coming to things like this. But I do get a lot of, I feel it's very rewarding to work on open-source and I do work on it outside of my job and I try and contribute to other projects that aren't related to Appium when I find things that are wrong with them. But I'm also like Dan in a position where I've been really fortunate between Sauce Labs and now my own company where my destiny is sort of aligned with Appium. So I've been able to use my quote, work time to do work on Appium and otherwise I certainly wouldn't have been as prolific a contributor. So yeah. All right, thanks everyone. Can we have a big round of applause? Thank you for making Appium awesome and all of us.