We're going to talk a bit about over-the-air updates, so this is typically how people develop connected devices or IoT devices. So you start off by prototyping, production design, and then you get into some kind of release deadline panic towards the end before you get into mass production. And this is also where you typically start thinking about over-the-air updates. And because you know that during this critical phase where you're almost there, you make some mistakes, and now you need a way to fix them. Of course, this is where you should be thinking about over-the-air updates and how to resolve them earlier in the process. So when you have a prototyping stage, you might want to test it out a little bit, or especially when production design, what kind of update strategy should you use for your application? It's really hard to retrofit these things. So when we see a lot at Mender, obviously, we'll make open source over-the-air updater. But what we see a lot is that people build their own, and I've divided them into three categories. By the way, how many of you have built your own over-the-air updater? Just raise your hand. It's kind of like one-third of you, and how many would like to do it again if you had a chance? One. Okay. So this is generally also what we see. People make it because they have to, and it's a panic, and things go not as expected always. It seems like an easy problem. But the first version is what I call the bricker, which is, it's very short in development time, and then you start to very, and see the effects of it afterwards. So you see that when you update devices, they lose power, they never come back online. They get shipped back to you and you have to resolve this as a support case, for example. So you start out with some bash scripts, maybe, and you work your way from there. Then you have the Honeypot, which is more security-related. So in this case, you might not be thinking about authentication when you download the update, for example. So if somebody is nearby, they're able to inject an update that was not supposed to go there. Maybe there's plain text protocols, and there's no signatures. Actually, the Tesla had partly this problem until 2016, when they got hacked by some Chinese research company. They did not have signature validation of their updates. So they were able to take over a Tesla. But it sounds like a basic problem, but even Tesla has this problem. And then you have the Needy Updater, which is the one that needs a lot of attention, because you need to do it one by one. So you have a device, and then the only way to get software to it is through a USB stick, and then maybe run some rescue mode and a shell script there. So obviously, this doesn't work that well. It doesn't scale that well. So it gets done less frequently than it should. And then why are these so hard problems? Well, it's basically because we work in a very rough environment in embedded space, as you're probably familiar with already. Devices are remote. They are expected to live for a very long time in the field. Maybe five, 10 years. For cars, it's even longer. Maybe 30 years. And then you have these factors that make it hard. So it has to work every time because it's remote and long lifetime. But then the power is unreliable. Maybe it's running on battery.  Why would he ever do that? And then what happens when the device boots again after that? And you also have unreliable network, a public network, often wireless networks that are insecure as well. So it's a pretty harsh environment, as you know. And based on this, we found some criteria that you should have as part of the update process. So it needs to be robust and secure. Integrate well with your existing environment because you probably have some way of building your software and developing your software already. And you don't want to replace all that just to get over-the-air updates to it. Easy to getting started again because we're often in that right bottom box there where you're in panic mode and you want to enable updates somehow. And you don't want to spend too much time on this. And then, of course, you have bandwidth consumptions, especially for 3G networks. Downtime during the update, this varies also by application, how long are you allowed to take your devices offline? If it's part of a telecom or a router network, this is very important, of course, to have it very short, but it varies a bit. And then lastly is the update server. So being able to manage updates across a lot of devices is also important in order to make it cheap to deploy a new update. So this is over the years after we've worked on this problem. We released the first version of Mender last year, so it's just one year old, the first version of 1.0. But we've developed this workflow that you should follow if you're doing over-the-air updates. So firstly, you do some kind of detection that there is an update available through a secure channel. You do compatibility checks to make sure the update is for this device. It works on this device, write architecture and so on. You download it, do integrity check, make sure nothing is corrupted. Check the signature, make sure it's authentic. You might also decrypt and extract it depending on if you need confidentiality in your updates. And then usually you have some pre-install and post-install actions, but the most important one and the one that you only think about when you're in panic mode is the install, because you can see it's actually quite a small thing compared to all the other things you have to do. But after you're installed it, you need to restart it. You need to do sanity check. Does the device work after you did the update? So one thing is if you get Linux to boot but do your applications work as well. Because otherwise it will be pretty useless to the end user. And then lastly is maybe most importantly what do you do if it doesn't work? So there will always be some way to resolve it. Maybe ship the device back, but that's a quite expensive way. So what we advocate at least is to have some way to do automated rollbacks. But that depends again how you do the installation. So some ways of installing, for example, RPM packages and things like this, you cannot rollback in general. So quick intro, how many have used Mender, although you, oh it's quite a lot, four, five, six, maybe one third. Sorry, you looked at it. How many are aware of how it works? Maybe half of you. Cool. Welcome back and welcome to the rest of you. I'll give you a short intro, what it is. So it has a client on a server. So you have this management server at the top here. And you have the devices might be a bit small for you, but it's on the right answer. I guess for you as well, yeah. So it's on the left hand side, the devices, and they will regularly pull for updates to the deployment server. And they will, if there is an update that's ready, they will get the answer, get this update. And then they will install it, as you can see at the bottom here. We have several partitions. So this is to enable the rollback that I mentioned in the previous slide. So we have one partition that's active and running. That's where your system lives currently. And then we update the other one. And why do we do this? So this is because if you lose power, for example, in the middle of the update process, you will still get back to the running partition. You wouldn't have altered anything of your existing system. And then you can try again to install the update. But if you have only one partition, then when you install the update, it might get half done, and then you cannot boot anymore. So this is to enable robust updates. And yeah, you can update anything you put on the root file system, including the kernel device tree applications. So maybe we should do a quick demo. Now I have not started it, so it will take a little bit. But you can also try it yourself if you follow the getting started. We say it will take less than one hour to test it out. And so far it's held through. So you can create an account. Okay, so it's starting a virtual device here. You can see there's another client there as well. So right now it should be running on my local machine. Right, it worked. So this is the user interface that we have. It's running currently in demo mode, which means that you cannot use it in production this way because it uses a shared key among other things. So it's very insecure. I hope you cannot connect to mine right now. But we do also have guidelines how to set it up properly. But there's a couple, there's three main areas to look at. So one is the devices, then you have the artifacts, which are the software basically that you want to deploy. And then you have the deployments where you kind of combine the devices and the artifacts. Let me see if I can upload one. So how many of you use Yachto project for, okay, a lot of you, maybe 70%. So we do have a meta layer for Yachto. So if you add that to your Yachto build system it will output a couple of extra files. So one file has the suffix.mender and this is what I just uploaded. So you can see it here. But this is basically a read file system and it contains some additional metadata, like your checksum. The checksum, we need that in order to be sure that we got all the bits, the build date, the size and if it's signed or not. So it's basically a raw read file system with some metadata around it. And this gets automatically built. If you use Yachto, we're looking to expand that. I'll talk a little bit about this later. But there you go. Okay. So there's one device. This is started as part of the demo setup. It's asking you to approve it because I haven't added any trust about this device before. So the device has the key of the server, but the server doesn't know anything about the device. So there are other ways to approve this device. You can preauthenticate it also, but if you haven't it will just ask you. So we provide some inventory information, but most importantly the current software that is running. So it's got a name, the software that you have on the device already. You can think of it like a version, but you can put any string there or revision. And then we also collect some additional inventory about the device. And this is completely configurable. So now I have a device and I have an artifact. So the last thing, you can see this pop-up side, just ignore them, but they will try to help you. What to do next? So we can create a deployment. We can use the artifact that we just uploaded, the root file system. And we do support grouping. So you can either do it to all devices or you can create a group. But it doesn't matter much right now since I just have one. But this is the basic workflow and you can see the reports as well afterwards and the status while it's ongoing, what is happening. So we'll tell you how long it takes. So this will probably take a couple of minutes. So we can resume. I guess it's not that interesting to watch a progress bar. But I'll switch back to the... We can resume here. Do you have any questions by the way so far? So you're asking about tiering the updates. So you have an internet connection down to a building, let's say, and then you have fast connection within the building. Yeah. We don't have anything specifically to support that, but we use HTTP. So it should be quite easy to set up a proxy, HTTP proxy there. I haven't experienced or experimented with it myself, but it should be quite straightforward. Okay. So the question is how much additional overhead is required on the client side? So part of this is shown. I can maybe submit in. So I would say the biggest overhead is that you have to have two root file systems. So there is some storage overhead. It depends how big your root file system is, obviously. We also have a data partition. So your root file system could be 50 megabytes and your data partition like a gigabyte or something. So it depends on what you want to update. But I would say that's the main thing. And then the client itself I think is about eight megabytes or something like that right now. Right. So if you already have an updater, is there an easy way to transition into Mender? So it is not trivial because we use this partition layout and that's the hardest part. And if you have a live system running and it doesn't have the partition layout, it is a bit tricky. I've heard about, I've not tried it myself, but there is a tool for this where you can actually change the partition in a running system, but it's risky business. So unfortunately, it's a bit tricky at that stage. Then you're good. Okay. Right. So if you only want to do updates, say at night or something like that, how can we support that? So we have something called state scripts, which is partly covered, I guess. It's a bit simpler or more generic version of the pre and post install actions. But we have the ability to insert scripts between each stage here. So you can have a script before detecting the update. And then you can implement any logic there to say if time is in this interval, skip this or just retry later. Did I make any sense or? Yeah. Okay. Three months ago, it should have been there. I think it was in 1.2, so maybe around September. Yeah. So that's the first state script. So there is a documentation section about it. But if you're... Yeah. So there on the client side, there is some docs about it under artifacts here. But yeah. So there's a lot of states and then you can add scripts before and after the states. And one use case is to control when the update happens using the scripts. So that's one way to do it right now. We do want to look at also schedules of updates on the server side, which I think would be a better solution for you. But it's possible using the state scripts as well. And then you can also use the local time zone of the devices to know when to deploy the updates. So there's one like C specifically. You probably should do one before artifact or before download. I have to think a little bit about where exactly to place your check, but it's possible and it's documented here. Yes. Yeah. So there's a return code that you can... You can do that too. So you can... There's two ways or three outcomes. So you can say continue or you can say fail and then it will abort and roll back. Or you can say retry later and then you can configure how long until next attempt basically. So it's possible. Yep. We have plans to support them, but we don't do it yet. So the only way to do it currently is with this script. So you can couple like update to the Linux device with updates to other devices that are close by. But we are planning to implement better support for that probably next year, I would say. Okay. They are requested. So there's no open port on the devices on the clients themselves. And they go over HTTPS and they ask the server. They hit the specific endpoint and they check and they provide their identity and then the server will respond whether or not there is an update. A partial license. Yeah. So a partial license is for everything. So it's fully open source. Yeah. So it depends on how you structure the partitions. So we recommend... Let's see if the picture is here. Yeah. So you can update anything inside this root file system partition. How to do it? No. So just the one here. Yeah. And then what we typically do is to place the kernel there as well. So you can update that. We've seen some interest for updating a bootloader, but it's maybe like 5% wanted because yeah. They don't want to break it. Any other questions? Yeah. So how can we enable factory reset? So at least until now we've considered that more of a system integration item. So we don't cover that like you say in our docs or anywhere. So what you probably ended up doing is added another partition here that had the oldest or the factory image. And we don't currently have any plans to support factory resets directly in Mender, but we can talk afterwards and maybe there's a good path for doing that. Makes sense. Yeah.  So we try to be very generic and careful not to require any specific technology, but that's also a good point. And this is partly also why it's why we currently at least consider it more of a system integration thing that you know you're using over the FS and therefore you can use that. Yeah. Right. Yeah. Yeah. So it's still planned. So Delta up this right now. I'll talk a little bit about what we're planning in the short term, but yeah, we will get there. It's just a matter of priorities at the moment. Okay. Any other questions at this point? Oh, all right. Let's see if we have a failed update. So in this case, you will get a past deployment here, obviously. And then you can see what happened. I just had one device here and it failed, but the device came back up. So now it has rebooted twice. It wrote the update and it rebooted into it or it might have rebooted into it. And then it rolled back. So it's still in a working condition here and it reported to the server what happened. But this is quite detailed. You can see the log. Let me see if I can open this. Yeah. So this is the log from the vendor client. It's quite a lot of data, but let me see what happened. All right. Yes. There's the magic message. Yeah. So I built root file system that was too big. So I have to build another one. But yeah, this is how it can fail sometimes. And this is how you would figure it out. So each device would create a log and then upload it to the server if it fails. We don't upload logs if it's successful because they're maybe not that interesting. Let me see. Yep. Yep. So there are groups. Let me see. Yeah. So I put my only device in the test group. But you can obviously add more here and then have a production group as well. So now once you do it the correct way and deploy it to test first you should be able to catch this. And we only allow, this has been a little bit of a debate, but we only allow a device to be in one group at a time because if you happen to add it to both test and production it might have some interesting side effects. So some people would like that, but currently we've been managing to keep it like this. So a little bit on what we're working on right now. How many of you know YouBoot or have done some work in YouBoot? Okay.  Almost all of you. So we also work with some people that don't know YouBoot that well. And we do require some integration with YouBoot in order to handle the partition switching.  And it is difficult like if you're coming from a more application level background and you're suddenly in this YouBoot world. So we're working on simplifying this work. So we have some automated patching already. And then how many of you have integrated a board with Mender? Okay. And one thing we were thinking is that there are a lot of people doing this and there's nobody sharing it. So do you think it would make sense for you to share it back to the community or do you think it's more of a proprietary thing that you... So you don't think you would be allowed to share? Yeah. It's easier to maintain also. What about you? Do you think you could share your integration you did with Mender or... No? Yeah? Yes. Okay, great. And do you think other people would be interested in seeing what you did with Mender there or how you integrated that into your board? And do you think that would make sense to share that part? Okay. That's great. Okay. That's great. Yeah. But you are again the experts. So there's a lot of people. So okay, cool. Yeah. So that's one area we're looking to just create a separate set of documentation and readme where we would basically index the board, the Mender integrations that people do. And it's somewhat similar to the Yachto in a meta layer index. We're thinking something similar. If you put it in your Github, we would index it. And then do you think that would make sense or... Run? Yeah. Yeah. Make sense. We'll get something going there pretty soon. And another thing is that we're also thinking about CIs and maintaining these integrations over time. So having a way for the community to hook up to our CI server, so we would run all the tests on your integration. And then you would get an output afterwards. If it's failed, you'd get an email, you'd get a log, and you can maintain it over time. So yeah, that's a great idea. Cool. So you'll see something about this pretty soon. And then we're looking at other ways we can integrate with boards as well. We're experimenting a little bit with UEFI on how you can actually use that to do the partition selection. So you don't need to do any patching at all. It's quite technical. But you can... Uboot actually has UEFI emulator. So you can use that. And on X86, UEFI is supported pretty much everywhere. So you can sort of get one level below Uboot in that sense. And then if... But this is pretty early stage. So we don't know if it's possible. But if it doesn't work, we were thinking also about the POC mode versus production integration, where you wouldn't have all the robustness criteria, like atomic updates. So in this case, if you're just testing Mender out on some board, you can easily do that. But if you want to bring it to production, you have to do the integration. And then finally, we want to have some way to do binary post-processing also in order to support Mender. So if you have an image already, have some tool that can repartition it for you, insert... Make sure that you can do the partition switching. So if all this is binary and there is no need to do source patching, we can also build a tool that just takes your existing image and builds it into a SD image that includes Mender and the partitions that you need. So these are some of the things we're working on right now. Does it make sense? Or do you have any other ideas how we can do the integration easier? Yeah, that makes sense. This is actually a fairly common problem. You saw it in the demo here as well. So it's too big. Makes sense. Okay. And then in terms of platforms, we're looking at X86. So this is not that well supported by UBoot. It's supposed to work, but it doesn't always. So maybe we need to look a bit into Grubb. And then there's also other systems than Yachto, of course, that are in use on Linux. There'll be an UBoot to Raspbian are very similar. And then you have BuildRoot as well that we will take a look at. Yeah. So that's basically it. Is there anything? Does it make sense? Or do you have any comments? I have not. Right. Do you have any ideas on how we could support it better? Or? Yeah. I don't have any information on that. I'm sorry. I haven't worked directly on that, but maybe, yeah. Problem solved. Yeah. Oh, but thanks for the input. Okay. Any other thoughts on, yeah. I had a little bit hard time hearing, but yeah. Right. So what we were thinking concretely is that when you first would have to create an integration with Mender on your board. So there's some integration with UBoot in particular. And then we have a checklist that you can run through manually to make sure that that works. So then you're in, let's say, on your production device. You did this integration with Mender, and then you know it works because you did it once. So the idea with the CI is that then at that point you can take one board, one of your production boards, and you can put it somewhere. It has internet connectivity, but it's isolated from your secret networks. And then you can hook it up to our CI server. So then our CI server would control that board, and it will run the latest version of Mender and build that image for your board with your integration. Yeah. So this idea was based on Yachto. So you will provide the sources for the build to this. Yeah. Yeah. So we would build the entire image. This is what we do already for the reference devices. We have Raspberry Pi 3 and Bigelbon. We use the sources from Yachto. We start from scratch, build everything, and then there's some trickery to deploying an image on a running system, like re-flashing the entire device. So it's a little bit tricky, but yeah. Yeah. So right now we have zero people that are signed up, so we'll see if it scales up. Yeah. So yeah, I'm glad you're interested and definitely validates that we should continue to work on this. But probably once we, if we are at the luxury where we have scaling problems in the CI infrastructure, we'll handle that like some caps or maybe some paid version with more resources and so. Yeah. You'd rather us to provide the entire build. Yeah. So it would be the board that you probe. Yeah. So that we can do the integration on those. Yeah. Yeah. So we have a commercial offering there that you can hire, for example, to do it. We, so that's basically what we have time to do. Otherwise it's a bit more opportunistic. So yeah, you could, we haven't, I haven't had that request before, but it's something we'll, yeah. It's a good idea. And the reason we have, yeah. When are we out of time, by the way? Like is it 11? Okay, in three minutes. Maybe one more question. No, we only use groups for that. What were you looking for in particular? Okay. So you want to have more, so this is something we have on our roadmap that you can create more dynamic groups as we call them. So you can base them on attributes on the device itself, for example. And you don't have to put them specifically into a group. They would just show up in that group because they have these characteristics. So that's something we will add. Yeah, exactly. Yes. That will be part of it. So typically the term used for it is campaign management. Yeah. But that's basically you start with 1% and then 5% or these devices than that devices. And maybe one last question. Yeah. So we do full image updates and we do compress them. So they would be reduced. But this is what the gentleman over there asked about delta updates would be a much more efficient approach where you can reduce it maybe 90% or 80%. But right now with compression, you get maybe 50% reduction or something like that. So, but this is something we will work on. Yeah. And we're streaming it right now as well. So you don't need an extra space to store any temporary files or anything like that. It goes directly to your partition. But I think we have to end. But thanks so much for joining. And we have a booth as well and a couple of other events coming up. So feel free to join those and reach out to me if you have any more feedback or questions. So thanks a lot for joining.


So, welcome everyone to the Hello APM setting up your first APM test efficiently by Boro Singh. We are glad that they can join us today. Just a small reminder that below you will be seeing the chat I can please type in your comments over there. And if you have any questions then there is a Q&A section just besides that I would request everyone to type your questions over there and not on the chat window. And yes, without any further delay I would ask Boro to take it over. Thank you so much. Sure. Thanks a lot Nitesh for that wonderful intro. And good morning, afternoon, evening or night wherever you're joining from whichever part of the world. I'm really excited to bring this talk to you. And the title is very, I think, self-explanatory. This is like your Hello World introduction to APM, the first thing that any programmer will do. So we are going to basically walk over what APM is about, what are the concepts and how do you set up an emulator and potentially end by running an Android or an iOS test. So it's sort of like an end to end thing, lots of things for me to cover so I'll probably jump to it. But maybe like why this talk, what was the motivation for this. So a small backstory like I started learning APM in 2018 when I joined Gojek. And I clearly remember I took three days just to get APM set up with Android, emulator and everything. It was a pain and my whole intent with this talk is to save you that pain. So let's make sure that we can make getting started with APM a little bit easier for you. Yeah, so a bit about me. My name is Gaurav Singh. I'm an experienced software engineer in test, primarily in Bangalore currently. I'm currently an engineering manager at Gojek. It is one of the Southeast Asia's biggest ecosystem for on-demand services like ride hailing, logistics, payments, so on. And by the way, we are hiding. So if you are interested in a career change, feel free to check out Gojek careers. Apart from this, you know, I'm very passionate about quality engineering and test automation. I love building scalable automation frameworks for the entire stack and high performing teams. I pride myself as a polyglot programmer having experience in JVM languages, Python and JavaScript, and I'm a proud tester. I really like exploratory testing. I find that it's one of the best ways to catch bugs. I have some courses on test automation university and I have previously spoken at PMN City GameCon. A bit of housekeeping around this. You'll find all of these slides and code already there.  I also have a GitHub project where I'm showcasing the code that we use. So you can just go to my GitHub account and you'll see Appium fast boilerplate. This has the Java project with all the example code and you know, instructions on how you can run the test and everything. I'll update the talk video once it's out and you know, usually you can connect with me over the blog, Twitter, GitHub or, you know, all of that. So let's get started. You know, can we have, you know, a quick start, maybe like raise a hand if you're very new to Appium or maybe like one to two months into your Appium journey. So how many people here have are in that bracket. Okay, I see quite a lot of hands raised. Okay, wonderful, wonderful. So I guess you are going to get a lot of value out of this session. And even if you are moderately experienced, a refresher never hurts, right? So let's start with what is Appium. So if you are coming from a Serenium background or web automation background, you'll feel right at home because it's an open source library to drive mobile automation. And when I say mobile apps, it can drive native apps, hybrid apps having web views inside or mobile web, and it pretty much supports the most common platforms like Android, iOS, desktop and much more. If you're part of, you know, the state of the union meeting that we had, you already know that Appium is much more than just Android and iOS. There are multiple platforms to support. One of the core features with Appium is its language agnostic. So you can choose the language of your choice, such as Java, Python, JavaScript, Ruby and many more. And you know, you can write your tests with ease. Appium does not reinvent the wheel. It wraps automation libraries provided by Google and Apple such as UI Automator to an Espresso and for Apple X UI Test and UI Automation for Windows, it's a VINAP driver. So essentially, we are not, you know, creating something new. We are integrating with existing technologies and that is great because the vendors actually have a lot of knowledge about the platform.  Another core philosophy with Appium is it does not believe in recompiling the app or making use of any SDK. So it drives your apps as a black box and you'll see when we talk more about some of the concepts, right? Appium is compatible with WebDriver protocol. So if you are familiar with the WebDriver API, then you will find that Appium is a pretty much straight one-on-one port with some additional features, obviously. And it's cross-platform so you can run and write your tests in Windows, Mac and Linux. So before we move forward, let's understand some of the core concepts around Appium. These are terms that you will hear quite frequently and I have a sort of, you know, diagram to make it a little bit more easy. So there are four main actors when you talk about Appium. There is the client, there is server, there are drivers and then there is the target, right? So when I talk about client, what I mean is actually the library that you will use. So for instance, all the popular languages like Java, Python, Ruby, etc. will have a client available to them, right? And what the client actually does is it wraps the API that is provided by the Appium server. So Appium server, you can think of it as any normal backend server that you might have encountered. It exposes a REST API and the client basically provides certain methods with which you can hit this API. The protocol that primarily is used is called as JSON wire protocol. And internally what Appium server does is it interfaces with all the different drivers that are provided that we already mentioned. So if you have to run an Android test, Appium server will talk to a UI automator to driver or an espresso driver, which will act as a bridge and will convert your Appium command into native commands that these frameworks understand. Eventually leading to your apps being driven on the desired platform. And if you see like the same horizontal cut can be applied to all the different platforms that Appium supports. So I mean now it's not just desktop, it's also TV apps, right, as we saw. So these are like the common terminology, right? So whenever you think of Appium, just think of it as a server. You can expect a similar client-server interaction, make a request, get a response. Everything within Appium happens within a session context. So essentially when you start, let's say a run, it creates a session. And while creating the session, we actually provide some data, right? We tell how you want the session to be tweaked. And that is called as desired capabilities. So when you see desired capabilities, just think of it as a simple hash map or a dictionary in any language. It's a key value set of pairs where you say, hey, I want the timeout to be something. I want the app to be reset after the run is done. And there is like a long list of desired capabilities that you can go through. Understanding how these works would be very vital to your Appium journey. So probably you can find that in the Appium docs. As I mentioned, Appium server is just a Node.js server that bridges commands from your client to the native frameworks, right? And when I talk about Appium clients, it's again certain libraries that you will make use of. We'll see an example of this within Java context. Lastly, there is Appium desktop, which is a sort of server as well as an inspector built into one app. And this helps you to basically investigate the app, right? And be able to understand like different components of it. And we'll see an example to this. So I think enough about theory, I think we can get started. So like what is the basic things you will need when you are working with Appium, right? You obviously want to choose a language and ID and a build tool. So we are going to use Java, IntelliJ and Gradle. You can feel free to choose any other tool or language of your choice as well. But the basic concepts will remain the same. For iOS tests, we'll need Xcode with command line tools installed. For Android, we'll need Android SDK greater than 16 and Android Studio, right? And finally, you have Homebrew, which is a general package manager, right? And you have essentially the Node server, which is your JavaScript runtime based on Chrome V8. NPM is the package manager. So all the tooling that you need to install will get installed via NPM. We have the Appium server and Appium desktop. So I guess let's start with seeing some of these in action.  So primarily if you're on Mac, we will mostly be using Homebrew. So we'll use it to install NPM Node and then all the subsequent packages. So you can primarily just copy, you know, this command and run it in case you have not done it so far. Or if you're on Linux or Windows subsystem for Linux, then you can use Linux. If you're on a Windows platform, then there are tools like Chocolatey that also allow you to install Node and such type of tools. If not, you can always go to their site and just download it. So for my machine, I already have a brew installed. So I can just, you know, run this and you can see that brew is already set up on my machine. The next step is to install Node, which is the actual server for Appium and NPM as the package manager. So again, you can install using the Homebrew command. One other alternative could be you can go to the Node.js site and then, you know, download the LTS version for whatever platform you are on. And this could also be another way of setting Node on your machine. Mostly Homebrew is going to be very convenient. So after you're done, you just need to check the version. So you check Node's version and NPM version, right? So as you can see, I have version 14 and NPM version of six. Then the next step is actually to install Appium server. And if you want to install Appium server version less than two, which is the current stable version, then you can install NPM install hyphen G. And what this will do is, you know, it will install Appium globally. The hyphen G will install this package so that it's available everywhere. Make sure that you don't use Sudo because that causes a lot of problems. And this is how, you know, the Appium server looks like once it is installed successfully. So if I run this, you can see all the logs, but just for this talk, I am actually making use of Appium too. So how do you install that, right? So you just have the same command. You append at the rate next to it. And once it is done, you'll see an output like this. One key thing to note is like it says there is no driver or plugin installed, right? This is one big change that has come in with Appium 2.0. Essentially, you have to choose what drivers you want to install, right? And that is great because if you are not on, let's say, a WinApp platform, then why do you need to install a driver for it? So install the driver that we choose. Like we can actually, you know, install the XUI test driver and UI Automator 2. This one is for Android and this is for iOS. So I have already installed these ahead of time just to save a bit of time. But then there are a few things that we can check that. So you have now this sub command available with Appium driver list installed and it tells you what are the drivers you have currently installed. If you want to see what all drivers are available, you can just run it without this and then you can see great. So you have Mac, Mac 2, Espresso, so many different choices for drivers to use. Okay, so once you have installed Appium, the next step is actually to, you know, go ahead and start the server. So I'll just run Appium. And as you can see, we are running an Appium 2.0 server beta 16 version with two drivers already registered. I'm not have not installed any plugins, but I think that's a great new addition to the tool and you know you can subsequently install any new plugins that might you might care about. So we are using Java. We need to install Java from either the Oracle site or the OpenJDK site and set Java home. So you can either go here and download, you know, the versions, if you go for OpenJDK, you can download whatever version of Java you care about and then this will take care of installing it for you. Or you can alternatively just use Homebrew, copy this command and just run this. So you can find for Appium or you know the client to know where Java is actually hosted. So this is one common variable called as Java home that we need to set. So you can set it in your Z shell or a bash profile and then source it afterwards. This is very important step to do. If you're on Windows, you can still set it in your environment variables, the system environments that are there. You know, by this time, like if I just said I already have Java installed so I can just quickly do a check. And as I, as you can see I'm on Java 8 at this point of time. So the next thing to check is a very neat utility from Appium, which is called as Appium Doctor. And this is great for a couple of different reasons, it will tell you what are the dependencies you don't have installed. When you install NPM Appium Doctor and let's say I want to run run that currently. So I'll just say, okay, hey Appium Doctor what are the dependencies I don't have installed right so this is going to do a diagnostic check, and we'll check like okay all your dependencies are set up or not. So as you can say my machine is pretty much well set up and I hope by the end of this tutorial yours would as well be. You can see like there are some optional dependencies that I have not installed right so it tells what is not installed and then it also goes one step further and tells you. Hey, what is the use for this right so I mean this is great because you can just use it and then make sure that you install the optional dependency that you care about. Yeah, I think this slide is mostly about this there are a couple of more blogs around Appium 2.0 from Appium Pro that you can go through and aptly tools I've added the link here. So we are we are very close to you know set up for Android so like it's a couple of more things to maybe talk about. So like when you talk about Android, you know, we need the Android SDK. We need ADB which is the Android debug bridge. This is basically you know allowing you to do a lot of good things with Android. You need obviously somewhere to run the test so you either choose to run it on an emulator or on a real device and then like I'll show you how to set up an emulator very quickly. The best way to you know get all this setup is to just download Android Studio. So once you download it, it is pretty much similar to your IntelliJ sort of platform so if I just open that quickly. You'll you'll get a screen like this and essentially what we want to make sure is we go to SDK manager and make sure we download the Android versions that we care about. So as you can see, I've also installed Android emulator SDK platform tools and stuff like that. Also, it manages updates to this right so whenever you open a project it will say do you want updates to these or not so it will take care of that automatically, which is great. The other thing is you have this thing called as AVD manager. So if when once you open AVD manager, it gives you the ability to create an Android emulator. See, I already have an emulator created but then if you want to create one for yourself, you just need to come here, choose a mobile model. It's a good idea to choose maybe you know Play Store services because this will make sure that Play Store is available certain apps require Play Store services. So choosing a model like this is good, but you can also go for any other model. So this is the Android API level and also which image you want right so there are like multiple options available for the images. So let's say I just go with Android 10 for now, you can give a name and then you can also you know configure this as per your need, whether you want to configure the speed at which this emulator works or the latency and stuff like that. And once you're done just hit finish and you know it's going to create an emulator for you. So if you want to start an emulator, you just click on the play button and this is going to make sure that it launches an emulator for you, right. A couple of other things that you'll want to make sure that you do is once you have launched the emulator, go to about find the build number, right. So I guess you find the build number, you just tap on it multiple times until you get developer options enabled. And even for an emulator or a real device because it gives you the capability to go into developer options. And if I just search for developer, right, you can see developer options. The one that is most important is USB debugging needs to be enabled, right. This is similar for either your Android emulator or the real device. I'm going to just close this because I'm going to just make use of actual device to show you how to run the test, but I hope you know this gives you an idea. The one other thing that I have not yet mentioned is you know once you are done with installing Android Studio and everything, you have to make sure that your Android home is also set. So Android home is the path where your entire Android SDK will be present. So I've already given the most common path where it installs after you have done Android Studio. So you can just copy this, put it in your bash profile or Z shell RC and then source it or put it in your Windows system properties, right. So once this is done, one quick thing that you can check is whether adb is available. So I can just do adb-version and if you get a version of it installed then we are mostly good here. So I think, you know, we have hit a milestone. So we have set up everything that we need to actually run an Android test and maybe, you know, I can show you that. One other thing is all of what I've talked about is already captured in this, you know, slides. So you can after the fact as well go and just read through it in case you're interested.  So there is this utility called as Appium desktop. Appium desktop, you can think of it is if you if you're familiar with Selenium and we had an inspector available, right. So it's pretty similar in that in that sense, you can actually open up an app and then be able to inspect the structure and then basically find locators and everything, right. So you can go to the GitHub releases path to this and download this app. If you're on Mac, you can just download the DMG and you can install it. So this is how you know it actually looks like. So I'll just show you very quickly. So when when this Mac app is installed, it gives you the ability to specify an Appium server, right. And if you can notice I have actually changed the board from 4723 to 24 because I want to run two parallel Appium servers one for my test and one for just inspecting. So if you can say here our Appium server is running right. So you can start a server this way and this will start another instance and then you can open the inspector. So what this inspector does is you know, it basically takes certain desired capabilities and then launches a session. But I will not use the Appium desktop because quite recently, we had a change within Appium community where we actually in introduce Appium inspector as a separate standalone module. And that is great for a couple of other reasons. So let me just show you that quickly and then maybe, you know, we can discuss about it. Just give me a moment. Yeah. So quite recently, I showed you Appium desktop right which has a server and the inspector bundled in one single application but then we recently got a split wherein like the server is completely bundled out this reduces the size of this install significantly and also ensures that let's say I have a server running at this point of time right which is Appium 2.0 server. I can just make use of this itself and inspect my apps. So I would recommend using Appium inspector. It's pretty good. If you want to see how to basically find that you can just search for Appium inspector right and yeah I think you can find it within the Appium GitHub project. It's again a downloadable file similar to this. So yeah I think a couple of things maybe to discuss before we you know move forward. So like basically you have so far seen I mentioned desired capabilities right. So desired capabilities as I mentioned is a key value set of pair that tells okay what are the capabilities I want on the server right. So if you see here. Let me just open the real device that I have ready at the moment. So I hope everyone can see this. Just give me a minute. Let me probably collapse this. Yeah. So this is a real device that I have you know running I'm using SCR CPY which is a utility to screen share a real Android device right. And as you can see, I have actually an app here where it's called as API demos, which gives you the ability to probably practice a lot of Appium commands. So I'm going to probably use this itself to automate and one simple flow that I will want to automate is click on text, click on lock text box, click on this add button and verify whether this text is correct. Right. That's the simple flow I want to try. Obviously when you're trying to, let's say automate this for the first time you want to figure out what the IDs of this is right. So what we'll do is we'll start an inspector session. So just to start it you don't need to do anything else. You don't need to come here to decide capabilities and then you need to paste, you know, these capabilities, I'll just give you a quick brief of what they mean. So, if this is pretty clear we are saying Android, we are choosing UI automated tool as the driver of choice. What is the Android version, the name of the Android device that that I want to use. This is important if you're using, you know, if you're given name to your devices currently, I have only one device running. So this setting will not matter much. You need to give the path to the APK. So currently, if you want to, you know, take a look at where this APK is installed. So I have a path for that already. So you can go here under sample apps in APM you'll find this APK as well as the Mac app that we are going to use. Right. So yeah, you have the fully qualified absolute path for this and you have the app package and the app activity. If you are, you know, thinking how to find the app package or the app activity. I have some instructions on that maybe I'll just yeah. So if you just if you'll go to this path you'll find I've written a blog for this and you can actually read on how to figure this out. But this is mostly a one time setup that for any new app that you're automating, you need to figure out the app package and activity and then mostly we are done. So if you come here, you set this activity, sorry, this desired capabilities and you save it with some preset name, right. So as you can see, I have this already saved. And what I'll do next is I'll just start a session. So it says, okay, automation name can't be blank, which is good. Like it's one live bug that we found. It's actually not a bug. I just need to tell the, you know, driver name. So what I'll do is I'll just go here. I'll copy this guy, you know, and I'll update it here. Okay, so I am just saying I want to choose UI automation to ask the driver and I'll start the session. And it will take some time to, you know, actually start the app. And great. So I think now what you see is it has actually booted up the app, right. And this is the app inspector in action. So this will let you know. Okay, so if I want to basically click on this text element, I can click on this and then see what are the properties for this element, right. As you can see, it intelligently also suggests certain locators that you can use. So it gives a fully flashed X path that you can use. It tells other properties about it. Also, it has actions as well. So you can just use these actions to perform, you know, actions on the app. So I just performed a tap. Let me select log text box and again tap on this. Let me click on add and then again tap. And as you can see, I can go through a flow on my app and keep on seeing what are the different screens and what are the locators I might worry about. You can also send keys or, you know, you can clear and stuff like that. So there are like a couple of other options. You have this option called as get timing, which is interesting because it will tell you out of all the available choices, which ones would be the most fastest one. So as you can see, ID is always going to be faster than any other option. So you might want to prefer that sort of strategy to actually capture that. So great. I think we have a fair bit of idea about the inspector. Now, there are a bit of other things as well. So there are like additional capabilities you can swipe by coordinates, tap it. And you know what not even refresh source and take a screenshot, start recording. So there are multiple capabilities that this tool offers, which I think you can make use of. So let me come back to this. I think with this, you know, we have set up everything we need to run our Android test. So let's see that quickly. So as I mentioned, I already have a sample project ready to go with all of this, right, but I'll just explain the test structure very quickly. So you have a test, you know, that that is basically interacting with which inherits from a base test and the base test actually reads certain values from properties, you know, and I'll explain what that means. The base test is responsible for initializing the driver connection, setting up the driver instance, and for that it is basically reading certain JSON files and taking care of that action. And also the test, you know, just interacts with a page object and the page object inherits actions from a base page. So if you're thinking like this is maybe probably a lot more detail. So I'll just show you the code. I think that will make a little bit more sense. Right.  If you take a look at build or gradle, right, this has all the dependencies that we need. So it has the Java client, which is the client that I was talking about. It has Selenium server Selenium Java, and then it has test energy as the framework of choice. This is a run test method which basically uses test energy and then is able to run any test annotated by a group, right, so I'll probably show that in a test file and that would I think sort of make better sense. So if I go to Android test, you can see this is the simple test that I have ready, right. As a structure, it is coming under the Android group. It is extending from base test, and it basically creates an object of API demos on page, passing in the driver instance and then it just does the same action that I talked about. It opens the text taps on login text taps on add button and gets the text. Finally, it just asserts whether the text is expected or not, right. So if you go to base test, base test is like, you know, your common file that all the test file will share. And as you can see it has Appium driver, it has a properties reader, and it has two common methods around setting up your driver instance and tearing it down after the test is run, right. So if you see what we are doing basically is we are getting a target, which is basically what platform we want to run it on. And then we are passing it to a class called as new driver manager, right. So I'll just show you this class, and this will give you the actual hold on how a server instance is set up. So as you can see, I have an Appium server URL and one key thing to notice with Appium 2.0, you don't append WD slash hub. So if you're on on on a version lesser than Appium 2, you still need to append this to the server URL path. So as you can see, I have a get instance method, which basically takes a target platform, either Android or iOS. So if you go here, this is just a typical enum.  What these methods in a very quick nutshell is doing is they are reading from couple of capability files. So if you see search for Android caps, you can see in resources I have this Android capabilities file. And again, I have the iOS capability file as well. So depending on what platform you want to run the test on, it's going to read that file, and it's going to basically populate, you know, our desired capabilities. So if you see here, what it does is I'll not go in the details of this method, it basically reads that Jason file and then gives a hash map, and then we just set it to get drivers method. Here you can see we create an object of desired capabilities. And this creates a new driver instance with the Appium URL and the desired capabilities map that we have just read. Right. And finally, once done, it just returns the driver instance and its job is done using an abstraction like driver manager helps you to, you know, evolve this class independently in case you want to support a cloud device lab like browser stack or whatever. And it's a very common pattern that many people with Appium automation actually use. So, enough with this I think we have taken a look at the test, the base test driver manager, and you know also the capabilities file. The one final thing is basically the page object. So if you go to page object. You can see the page object extends a base page class. So if I go here, you see, this is another framework pattern to follow with Appium or Selenium in general, wherein you wrap the third party methods into methods that you control. This is useful because if tomorrow you want to, let's say move to a different library, you don't have to change in all your page objects you can just isolate the change in this base page. So you have to not overcrowd this class. So in case you are expanding this a lot. I would suggest to you know break it out into different classes and just compose them as an object into this class. Right. So as you can see, I have very common methods for click and get text is just a plain simple wrapper over the Appium methods and I have a couple of methods around waiting for an element. It's a pretty lightweight class and in a real project, you would actually iterate on it and add much more level of capabilities for swipe tap and all sorts of other actions. Right. But the core important thing to see is in the constructor, we pass a driver instance and that is set in a protected instance so basically any child class also inherits the driver instance. In general, I have given the two sort of locators, right, if you see there is a text button and the log text button that we saw on the homepage, right. And both of them are using the expat locator. If you see there is an open text method and a wrapper to perform click and all the other sort of action. Similarly, I have another page object as well, which which is again dealing with, you know, the, the other class that we had basically the exact logging screen that I showed you just second back right. Yeah, basically this screen. So as you can see, this pretty much completes it one additional good pattern that I would like to call out is you basically return an object of either the same page object or a different page object and what that enables is you can basically chain and write your steps one after the other this is called as the fluent pattern, and this makes your code lot more concise right. So now, if I want to just run the test right so you can, I'll just run it via greater so you can actually go to this project. I have the command here, so you can just run this whole command. So as you can see, it is creating a new driver instance, right, and it just performed what what we wanted it to and it quit. So, yeah, this is probably all about running the Android test. I have added the code for all of this in this itself and you anyways will have access to the GitHub repo that you can take a look at. With with you know all the sample code so I think moving on to probably you know I was there are a bunch of additional packages that you need to install so I'll probably run run through them fairly quickly in the interest of time. So you need to make sure that export select is installed, right, Carthage is installed this basically allows the X UI test driver to build any iOS dependencies. You need to install live mobile device which is used to communicate with iOS services using native protocols, right, there is this dependency called as iOS deploy that makes it very easy to deploy apps and everything. And then there is this iOS WebKit debug proxy that that you can install so I mean, if you think about it, this will basically proxy your request over a web socket connection. It's okay if you don't know the details to be honest is just think about it as some set of dependencies that you need to set up once to enable running your iOS tests, right. So, additionally, there is this IDB as well that you know allows you it's an equivalent to your IDB bridge that that needs to be installed. So once you're done, like, I would want to also run on the iOS app right so what I'll do here is let me kill this inspector and I'll show you the app very quickly. So I'll basically run the iOS app from here. And currently, if you see capabilities are pretty much similar, right, except for the difference of X UI test as a framework choice, and we gave device name as you know one of the simulator images. I've added a command for how you can basically find the name of any simulator or whatever. It's pretty easy to do. And as you can see, this is a very simple app where it's a sort of demo app where you have, let's say two controls, and you can enter certain numbers and you can compute the sum and that is what we are going to do. The Appium inspector is pretty much same. There are no differences, apart from you know, obviously iOS comes with its own set of way of organizing elements on the UI so you have X UI element type, X field, and stuff like that. So I'm going to basically close this and I'm just going to show you the test very quickly. So if you come here, right. Yeah, so I have an iOS test, and this is pretty much for, you know, following the same pattern. So you have a homepage, right, if I just show you that very quickly. So that's the two controls that I had and a compute sum button, and I have written some methods to type in the text, right, for the two numbers compute the sum, and then finally, you know, return it. Also, one more practice that you can follow is, while you write these individual small methods, you can always write a wrapper, if it's a logical action so currently we enter two number and compute right. So I've just added a wrapper method here and you can if you go here you can see I initialize the driver instance I just call this and I use get some to get the actual value. And then I expect obviously five plus five to be 10. So to run this again, I will make use of gradle itself. Right. Let me just go here. If you can notice the only changes I'm making is the tag and the target, right. So the tag is obviously your test energy group that I have that I annotated on the test, and the target is just a property based on which I decide what driver instance to initialize. So when I run this, it will just start a simulator, and it will install something called as web driver agent. So you can think of it as a small server running within your simulators or your real devices, and that proxies any command from Appium server directly to XUITAS framework. So you can see we entered the two number and we computed the sum and this is also good. I'm so glad that there is no demo effect today. So yeah, I think you can see this very basic implementation for iOS as well.  So I mean, if you go very quickly, I just showed that I think I added it here. One second. Okay, yeah, so in the Appium desktop section, right. Yeah, if you're using a real device, then you need to give some additional information, which is basically what is the bundle ID of the app and the automation name, right, and the export team name and and the signing ID. So all of these details is something that you can ask your iOS developers to give and they'll be able to actually provide that to you. Finally, you know, I think they're pretty much on time, but I just want to end with couple of bonuses. So you can use a CRCP via to screen share I already talked about it. But if you don't want to use the inspector in Android you have UI Automator viewer, which is a pretty much similar utility that you can use without creating any sort of Appium session for that matter. There are like some adb commands that you know can really help you so I wrote a blog on this I've given a link here. I talk about, you know how you can install an APK via adb. How do you copy files. How do you capture a screenshot video and stuff like that so you can basically read through this just to get an idea on those commands. And I think that would help a lot. And I guess, finally, yeah, I would like to thank you for your kind attention. In case there is any questions or feedback, you can like reach out to me, you know, on Twitter GitHub wherever you feel comfortable and more than happy to answer your questions. We'll see if we have some time now. And here are some further resources that can help you to learn Appium so you can go to Appium.io to read the docs. There is this execute automation playlist that I personally started learning Appium with and I recommend, and there is another series by, you know, automation step by step by rather which is also great. So yeah, with that, you know, I am very thankful for all of you attending all the best on your Appium journey and you got this. But thanks a lot, Gaurav, for sharing your experience with us today. It was really great. I really enjoyed. It was very straightforward, etc.  I think we have, you know, already some thumbs up from in the chat window. Yeah, thanks a lot, Nilesh. Let's hang out on the table.


The global shapers community is already covering the globe. Our age group is still a bit naive, but naive in a good way. What we are doing here is not something which is new or innovative. What we are doing here is something very compulsory. I think that there's something that's pretty unique about just the millennial mindset. We're incredibly collaborative and we're incredibly hopeful. Naive in a way that we think that we can change it and we can drastically change it. We're idealists. I think that we all feel like we can create something incredible out of it. Young people are a tremendous source of ideas, inspiration and innovation. Tapping into this generation can help reconnect you with that idealism, which sometimes is hard to find on a day-to-day basis. But at our age we still think everything's possible and nothing's impossible and collectively we can do something about it. The landscape of the way that knowledge is transferred and the way that people are communicating has shifted radically in the last three, four, five years. And a lot of the power that was controlled by traditional media previously is now in the hands, honestly, of people in their 20s. This is a generation that's already empowered. We just want to bring them together and help make them even more effective. And so whereas we didn't have a voice before, now our voice is becoming one of the loudest and most powerful voices out there. And so, you know, Shapers, I see as a vehicle through which that voice can be expressed through and out of the world economic form. Our generation has this opportunity to really be at the forefront of innovation I think. The types of individuals that are involved in Shapers come from every industry that you can imagine. There's entrepreneurs that have created startups and, you know, there's writers for TV shows. There's somebody from the NYPD in the room. There's a doctor in the room. There's an academic in the room. There's a public relations expert in the room. There's a celebrity blogger in the room. Being surrounded by those who are really motivated, really motivates you to actually come up with some of your own ideas or solutions. It's an amazing group of people and I think when you mesh all of that together, the skill sets and just the energy of the group is unlike anything that I've really seen before. You can't have the local impact without the global context. We imagine Shapers in New York who care about solving homelessness in their community, being connected to Shapers in Shanghai and Johannesburg, all interested in the same issues with the same passions and really using the best insights from that global network to make the biggest possible difference in their own community. I think that's what we feel as global Shapers in that room is this isn't exactly something extraordinary. We're supposed to be doing this. This is what we're supposed to be doing.


Welcome to this presentation on how US Air Force Service Doctrine is created. At the start, we need to understand the types of inputs that may determine the initial part of the process. Is this an update to an existing publication? Is this a proposal for a new doctrine publication? Is this just an administrative update to the text of an existing publication? Or is this an update to the Air Force glossary? Once the LeMay Center receives an input, our doctrine developers review it to determine what type of update it is. Here, the LeMay Center doctrine developers analyze the text to ensure it meets the four-part test from AFI 10-1301. Is it relevant? Does it describe specific Air Force operations and provide specific operational or strategic level effects in support of a specific objective? Is it appropriate? Does it describe operational level doctrine as opposed to tactical doctrine? Is it distinctive? Does it describe the information distinct from a similar function, mission or task, or that fits completely under higher level doctrine? Is it sufficient? Is there enough operational material that it warrants a standalone doctrinal discussion? If the input meets the tests, the doctrine developers prepare the text for full coordination. If not, it's sent back to the office that provided the input. Air Force doctrine is coordinated with the whole Air Force. Every Magcom, every Air Staff office, and three Secretariat offices can provide input. The doctrine developers adjudicate every comment, either accepting, accepting with modification, or rejecting each one. Once adjudication is complete, the doctrine developers send the comment matrix to all offices for a reclama opportunity. This lets any office with unresolved issues have another crack at clarifying its point. Once reclama is done, the doctrine developers update the draft text and prepare it for one final round of coordination with two offices. The statutory and regulatory coordination is needed with Half JAA, the lawyers review the text for legal sufficiency. SAF PA, public affairs reviews the text for public releaseability. Once the statutory and regulatory coordination is completed, the publication is staffed for a final approval. Air Force Doctrine Publication 1, the Air Force, is approved by the Chief of Staff of the Air Force. The SAF has delegated approval for all other operational doctrine publications to the LeMay Center Commander. Once approved, the final pub is placed on the US Air Force Doctrine website. From start to finish, the Air Force Doctrine process is a whole-of-service effort. The final product represents the efforts of airmen from across the entire service. Each publication is truly Air Force Doctrine.