I'm also a product manager in Google Cloud Platform focusing on Cloud SDK. I live in New York City and on a personal note, I love sailing as well as traveling. OMAR AYOUB: That's the slide you wanted. Great, so that's why we both traveled here today, to talk to you about developer experience. So specifically, what you can expect from today's talk is I will take you on a whirlwind tour of developer tools. So, we have a lot of them. We won't touch on everything. But we're really going to focus on three mainly. The Cloud Shell, we'll talk about some of the workflows that that enables as well for you. We'll talk about the Cloud SDK, and Aylin's going to walk us through that. that's a set of tools and libraries we have in Cloud. And then we will talk about the Cloud Client Libraries, which are there to basically allow you to have programmatic access to our APIs. So before we jump into every artifact, just a quick visual about where the developer tools fall within the context of GCP.
So we have the tools at the bottom here and the idea is that they allow you to access the GCP services as you would expect. And we have a lot of services. This is just a sample, the hexagons show you specific services. And the purpose here, the idea is to make it simple and easy, depending on what you're trying to achieve. You'll notice that we separated those services into two buckets. This is not a hard thing. Just for the purposes of this talk, it helps visualize. On the one side, we have the platforms. So by platform, we mean things where you want to run your code. So on the one hand, we have App Engine. This is our platform as a service offering, which allows you ultimately to run your code and not worry about anything else. So you write your code, you deploy it, and then you're up and running. Now the thing is, we have two flavors of App Engine and I just mentioned that because we will be referring to this during the talk. We have App Engine standard, which is a sandbox environment.
We have App Engine Flex, which is based on containers. If you've used GCP before, you're familiar. This is all known to you, but just to be sure we're on the same page. And then we have Container Engine. This is basically a Cluster Manager for your Docker Containers. So you specify your Docker Containers and then we scale up, we scale down for you as a managed service. Now one of the cool developer tools here in Workflow that we have that we won't touch on today but I encourage you to look into, is you can use Container Builder, which just went generally available very recently. You can use that to build your container images, which then will get saved to Container Registry, also in the Cloud. It's a registry for your docker container images, and then you can run this on Container Engine as a nice workflow from end to end. So I encourage you to go look into that for Container Builder. And finally, we also have Compute Engine. This is basically our infrastructure as a service offering.
So you want a VM, we'll give you a VM and you have full control basically of what you want to install and what not. So again, the idea here is that developer tools allow you to manage these resources, to push good on it, and you can see how CLIs or command line interfaces might be the good solution for this part. Then on the other side we have our APIs. We have Translation, Storage, BigQuery. Ultimately, you want to get data when your application is running. You want to save in a table. You want to analyze a piece of text using the Cloud Natural Language API. All of that, you would use obviously programmatic access and client libraries is where you'll probably want to go in and be able to do this. And of course your application running using these APIs could be running on one of the platforms or it could be running locally or running on another platform. Great. Given that context, we can now start and talk about our different artifacts. So quick story actually, I came to SF like two days ago.
I flew down from Seattle. So I'm in the airplane in the aisle doing my work. So I have my laptop. It has all my developer tools on it. I've been using it for a year and a half so I have all my languages, all my GCP tools. I'm doing my work and then out of nowhere– and this is a true story, by the way– on my left hand, I start noticing some Coke appearing then on my hand and then on my laptop and, like, all over my laptop. And I look up and the actual flight attendant by mistake just dropped everything on my laptop. I always wondered if that actually happened. But it actually does, so heads up. This might happen to you. So I get back to SF. I'm like, great. Obviously my data's all backed up, but I'm like, I have to get a new machine and reinstall everything. And for me to be even productive minimally, I have to do all of that. And my first thought was, if only I could log on somewhere and have everything preinstall and I can just hook up my data and I'll be up and running.
Anyways, kind of wishful thinking. But then I realized, this is exactly what Cloud Shell does. So in reality, Cloud Shell, no kidding, is a command line interface where you log on in the Cloud and you literally get access to a bunch of GCP tools and you can start being productive right away. So by the way, this was not a set up story. This actually happened and it just clicked in my mind, this is amazing. This is perfect timing for this. So literally, what actually happens is you only need a browser. You log on, nothing to install locally, and right there, you have a bunch of tools pre-installed. And by tools, they mean like text editors, we have Emacs, VIM, you have Nano. You have Git preinstalled, the Cloud SDK, which is a bunch of CLIs. And Aylin will talk about that a little bit later. But everything is pre-installed up to date, you have nothing to do. And we support seven languages out of the box. So we have Java, Go, Dot Net, Node, PHP, Python, Ruby, the interpreters, the compilers, the package managers, you can do pip install, it's all there.
And the beauty is that it has built in authorization so no need to log on again. You can just execute and it just works. I could give you guys more and more features, but it would probably be easier if I just show you how it works in the console. So we'll switch to demo. Lovely. So what we're looking at right now is literally the main landing page when you log onto GCB. If you've done this before, this is not new to you. You're looking at projects and every Cloud resource you create will be within a project. So to manage these resources, if you go to the top left corner and you click on that, you'll see a menu with basically a bunch of– so if you click on that, you will see a menu with a bunch of the services, some of which we talked about earlier. App Engine and Compute Engine, Container Engine. Anyways, the point being is that you can use that to do your management through the UI. But like we talked, what if you want to run some automation, you want to write some code, you want to– well you'll probably need a shell for that.
So if you go to the top right corner, you'll notice there's an Activate Cloud Shell. You click on that and that will start the Cloud Shell. So what happens in the background, just to let you know, is that a virtual machine, a small one, gets created and it has all the tools pre-installed right there. And what it does is it mounts five gigabytes of storage that you own. So every person here, when you log on with your Google account, you get 5 gig of persisted disk storage for free. And that gets mounted as your home directory in the Cloud Shell because it's mounted on the VM. So if you do a PWD, for example, you will see that we're in the home directory of where we are. And everything you save in there will get persisted. So if you log off, you come back in a week, everything you save will be there. So you can see how you can start writing scripts, writing automation, writing some code, everything will be saved. And also just to show you if we do get dash dash version, you'll see that we have that installed as well.
Now, we talked about VIM, talk about Emacs. There's always a big war between the two, which one's better. We have a solution [INAUDIBLE] which is basically to go in the top left corner, you'll see here files. And if you click on launching the code editor, this is experimental right now but this is basically a UI for you to be able to do coding directly in the browser. So if you're more into that and using a user interface, this is what you can do. And notice here that what we're looking at is your home directory also mounted. So whatever you save in there will get persisted again just like earlier. It's the same view. So we talked about having the tools, we talked about having a code editor. Everything is pre-set up. We have five gigabytes of space. So in the next part, we'll just really create a very small web app in Python just to show you what can actually be done. And it will walk through some of the workflows so you can get a better idea of what's enabled directly from the console again without installing anything locally.
So let's go ahead and do that. So we'll create a new app we'll call it My App. And that will be a Python web app, so exactly very simple. So first thing we'll do, we'll create a main.py, and that will contain our main code. Now we could go ahead and do that but if you're familiar with App Engine Standard, we do have a quick start in there that explains to you exactly how to get started and this is exactly where we're going to go and copy that code. Again, the goal is to make it very simple just to show you the other tools that we have around that. So in this case, you see that we have a very simple web application. We'll copy that in. And what it does is imports webapp2 which is a app engine standard web framework. Then we register a get handler where we just print out Hello World, where we could change that to Hello Next for instance. And then we're going to register the app– for the handler, I mean. So that is done, we're done. That is the simplest possible web app we can do in Python.
But given that we want to run this on App Engine Standard, and you'll see that in a second, we're going to have to create an app.yaml file. So we'll just create this new file. This is very typical. It's just a way of telling App Engine by the way, your platform has a service but you still need to know what type of application I am. So going back to the quick start, if you want to go and look, I encourage you to take a look at it. Very simple. And you'll see that we register– or simply tell App Engine that's Python and we tell that what handlers we have registered. That's it, we're done. So we can go back to the Cloud Shell. We've literally built an app. So if we do an LS, you see that we have a My App folder saved in our 5 gigabyte of persistent storage. We can log into that or CD to that. And then at this point, something else that's installed– pre-installed for you is the tooling for App Engine Standard. So one of which being dev app server. So this is just a tool allowing you to do local testing.
So dev app server, we pass in the app.yaml, hit Enter, and this basically will start on the VM locally the actual web app. Now do notice that it's listening on port 8080. But if we went on the browser now on port 8080, we'd be connecting to this machine. We want to connect to a VM. Well, in the top left corner of the Cloud Shell, you'll notice there's a button where you can click and you have a web preview. And that allows you to connect to port 8080 only to your account on that machine and you see that very seamlessly it just works. We can have Hello Next, we can do– obviously, you can make this much more complicated. This is just to get things going quickly. So we have this. Imagine we love this app, it's exactly what we wanted. And now we want to deploy to App Engine Center. We want to make it live. So for that we can just kill the application here at the testing and go ahead and do GCloud app deploy. Now we talked about GCloud a little bit because it's part of the Cloud SDK but Aylin will give more details a little bit later.
So GCloud is basically a command line interface that allows you to interact with the Cloud services. In this case, app means App Engine. So it allows you to interact with the App Engine service. Deploy, to deploy our app we pass in app.yaml. And then we'll just do dash dash version 2. This is not mandatory but you'll see later, we want to know the version. And versions, I just made up something, so we can hit Enter. Lovely. So this will run the background. Now one thing we forgot to do, by the way and we should probably do that right now is version control. Best practice, let's do thisl well. Notice there's a plus button right next, up here we can create a new shell session. So you click on that, we start a new session. And now we can run the get commands. So we do a CD into My App and then we'll just do the typical get dance like get in it, get at star, and then we'll just do a get initial commit or get commit dash M. Perfect, initial commit, great. So just to show that you can do obviously local repo, because if you guys will get persisted.
However, what if you want to collaborate with other people, right? Like software engineering, you're actually building an app you want to share with others, you probably use GitHub or Bitbucket, and I like to use Bitbucket for my private projects. But in this case, perhaps something you didn't know about, is that we do have private Git repositories in Google Cloud Platform and it's called a Cloud Source repositories. So in a new tab, if you click on it, you go in the menu, you go lower down you'll find under Tools something called development. If you click on that, this is literally a fully featured private git repo. So we can create a new repo, we'll call it stage repo, and that is ultimately a remote repository. Now, just to let you know, as an FYI, if you wanted to, you could still have stuff in Bitbucket or Github, and then automatically sync back to this repo, by the way. So that you can keep both in sync, and there are advantages to that as we'll see later, especially when you use App Engine.
But for now, we'll do the typical workflow. Right. We have our local repository, and we're going to push everything to this remote repository. So if we click on, I guess, repository on the left, we can just copy paste the remote URL, go back to Cloud shell, and get remote ad, call it Google and pass in the URL, and then we'll just do a git push Google master, right? And just for completeness, once this finishes, we'll head back to the repo and show you how all the files have been ultimately, have been pushed. Beautiful. And you have everything you would expect here, right? You would have commit history, you have branches, you can have tags, everything's there. Do disk between files, it's all up in here. OK, how we doing on App Engine center? Did it deploy? Let's see. It did. Awesome. So this is basically now live URL. I know it took a couple of minutes, not even actually because we were switching, and whatever we wrote is now live on App Engine standard. So a quick recap here, right.
We have the Cloud Shell, bunch of tools are installed, you can start coding, start developing. You have the Code Editor to do that, then we do a bunch of gits, we pushed to a source repository. We were able to test locally, we were able to push the App Engine center. The last thing that we're going to do in this workflow is debug it. So we'll go back to a tab and maybe you're not aware of this is probably one of my favorite features, by the way, in products. You go to sac driver de-bug. Now what we're looking at here is literally a debugger in the cloud. So, we're connected to GCP, right? If you notice here, there's a job done that says default/2. Remember when we specified the version 2? This is where it shows up. It's called default because we didn't specify a name to our App Engine application. But if you want to, the name will show up here. It picks up the App Engine running, and on the left-hand side, you see the files. Because we used Cloud source repository, it can pick up the files there as well and do the connection between the App Engine running the code, and the files checked in in the source repo.
So now we're looking actually at the code that we wrote, we copy pasted. And then we're going to put a snapshot point at some line. Do realize that I didn't say a break point, because we're not breaking the app. What's going to happen here is that we're telling App Engine, hey, please when you see the code or the application executing this code path, take a snapshot. Take a snapshot of the call stack take a snapshot of the local variables. Send it back to me. So if you open the live URL that we have for App Engine, hit refresh, it will execute the git, right? We go back, snapshot was hit. If you look in the lower right corner, you'll see the call stack. You'll see the local variables, everything you need. And just to be clear, we didn't stop the app, app is still running. We didn't have to create another version to put log statements, this is live happening directly. And if you wanted to, you can also put a conditional snapshot point. So yeah. So that was basically the full end to end workflow.
We can switch back to the slides now. So, quick recap. I just said it but really quickly, the stuff you might want to look into a bit more are the Cloud Shell, comes with a code editor, an experimental, but it'll get better. It will obviously move to beta and everything else. We have App Engine. We have source repositories. And we have the site [INAUDIBLE] de-bug. And all of that without logging on, with only logging on without installing anything locally. As simple as we can make it. Now if you think this is really neat, but is there more? The answer is yes there is Cloud Shell Pro. So right, now actually, at next we have an alpha version open only to next attendees. So you can have a bigger VM, more CPU, more ram. So if you're interested, I highly suggest going to this bit.ly link, shell-pro. It's a small form, you can fill it out and we'll reach out to you. And please, you can give us feedback. Let us know what you like. Let us know what's missing. Maybe more tools?
Whatever. We want to hear from you. Great. With that being said, now we can jump to the next part, which is the cloud SDK, and Aylin will explain that to us. AYLIN ALTIOK: Thanks, Omar. It was really cool to see all those actions you can do within browser with no installation. But what if you have a use case to access all the services within your local machine. The Cloud SDK is your solution. It contains a bunch of command line tools that lets you access the Google Cloud Services. For example, bq to access big query, gsutil to access storage, and gcloud, which is the primary command line tool that lets you access multiple services like App Engine, Compute Engine, data PROC, mission learning APIs, and many more. Indeed I will focus on GCloud for my rest of the demo, but I'll also show you the components that you get when you install Cloud SDK. Configuration and installation is super easy. You can get it on Linux, Mac or Windows. Actually, with no further slides, I will go ahead and jump into demo mode so we can see Cloud SDK in action.
Awesome. So I'll just search, the first thing we have to do is to install it. So I'll just search Cloud SDK Install, and we will go ahead the installation documentation here. And you will see there are a couple options that you can get it through zip file, or you can get it interactively by running the call command. So if you haven't done so, I highly recommend you start your installation. I already installed it prior to demo, so I'm not going to do that, but let's start together. The next step you have to do after installation is initializing Cloud SDK. So in order to do that, we are going to run GCloud in it's comments. So let me go back to my terminal and let's run GCloud in it. So, this command, what this command will do is that it's going to create a new configuration, or if you have only the existing configuration, you can also switch in here. But I created one configuration before, but let's start a new one together. So this will let us, this command will let us set up our project, our SDK.
So we can talk to cloud services online. So first thing we have to do is to give a name, the configuration. You can create multiple, and switch between, and it's going to ask, does the user name we want to connect to services. So I already used multiple user names before, but let's go out and start with a new account. So this is going to open the browser and let us to choose account. So this is a demo account we created before, now Cloud SDK ask for certain permissions to access services. Let's allow it, and boom, we are authenticated to Cloud SDK. If we go back to our terminal now, you'll notice that we are getting all the projects that was created under these account before. So I created a project before in the UI console. Next I'm on GCloud, so we will use it for the rest of the demo. And the last question is if you want to set the Compute Engine setting, this is going to mainly ask us the zone, so I'll go ahead and set the zone so we don't get prompted for the zone in the feature, but you can always set the zone flag or change it in the future.
So I'll just go out and select US on a, hit that, and awesome. We are all set and ready to talk to sources now. Let me clear it. OK remember, I mentioned to you Cloud SDK contains a bunch of command line tools. Let's go ahead and verify which components you get after you install. So when I run GCloud components, this command, these are all the components we see. Some of them are installed by default, like bq GAC2, GCloud, and there are multiple more that is not installed by default, but if you have used case, you can always go ahead and run GCloud components, update command, and, for example, cupsctl, and if you have a use case DOCSIS [INAUDIBLE] CLI, you can go ahead and run this command to update and install those components. So I'm not going to do that. We are not going to focus on that, but you get the idea. And notice that there are two, also GCloud specific commands under beta and alpha. I installed this prior to demo. These are not installed by default, but I will show you a very cool feature today under alpha commands which is our experimental command groups that we are currently working on, which is available to public as long as you installed this command group.
So I recommend you to get GCloud components update to alpha, and you notice here you see also the version. If your version is pointing to old one, you can always verify here our team is launching versions often, so I recommend you to check and get the latest. Perfect's, now we installed SDK, we initialized it, we check the components, and we get the ones that we are going to use. Now what is next? So we have to know which command to run, right? I assume some of you may not know how to run GCloud commands. So there are two ways you can figure it out which commands to run. The first thing could be GCloud have, you can run it, and this is going to bring you basically the manual page, the reference page to see the flex that's available, the command that is available. You can see like the app that you use before to access App Engine, Compute Engine container, and so on. Or you could do the same thing by going to our reference page here, and you see exactly the same information, if you prefer to see it in browser.
But here is the problem. If you are trying to basically come up with the command that you never used before, or if you are trying to discover new services, so this context switching between the Manual page, come back and continue typing, may be inefficient and time consuming. In order to solve this problem, we have been working on a feature called GCloud interactive shop, which lets you get auto prompting off the commands and the flags as you type with inline documentation. So you don't need to do this context switching. OK. Let me show it. So you get the idea. Remember I mentioned to you that I have something cool to show under alpha commands? This is it. And we are just announcing it today. So GCloud alpha shell, if you run it, this is going to bring up the share mode. You can see your configuration at the bottom here that we authenticated our user name. You see the project that we picked up. And now you can start using it. So we don't know how to use it, how about we create a compute instance together.
So I just start by typing c and it gives me auto prompting of the commands and I can go through them. And in here, I see the description of those and I see the syntax how to use it. And if this information is not enough, since there is a limited space, you can always Control W to open the full browser. So before going to compute user journey, remember Omar mentioned earlier that container builder ranked generally available recently. What if you want to learn how to use that command? So we will type container. Let's space. Let's hit space, and this gets us all the commands available on the container service so we can go through. OK. Builds is the one that we want to run. and we hit space and we get through all the command groups under that. And summit is the one that lets you run your local docker file and move it to a Container. Registry. Then you can deploy it to your Container Engine after. It's really cool that we had no idea how to run this command before, but we can discover, basically, the services this way.
And when you look at the syntax, the next thing for us to put the source here, the docker file source, or a dash dash config or the tech flag, and hit run. This should work fine. But if you want to see more, like I mentioned, control w would go to the reference page online. And you can go through everything here and understand and read more if you want to. So let's go back to them, not going to focus on container, we had the intention to create compute before, right? So let's go back to our original example, compute. Let's go through instances. And we will create but you see all the available commands here. Let's hit Create. And perfect. I see the syntax here. The next thing I need to give a name. Let's give a name stage VM. And this is it. This should work, right? I run it. So this is going to take a couple seconds to create the VM, but you get the idea. You had no idea how to run the compute command on a container command. We discovered it. we saw the usage, and basically we created the compute instance without hitting any errors and successfully ran the command here.
So with this. Oh. Just on time, it just created the instance. So I will exit from this shell mode, and will show you more advanced feature. Now we know how to run commands, but most of you probably want to take this and automate these VR flaws with your script , right? So in order to do, that I will show you some advanced feature to empower your script. So lets run the command. That will list us all the instances we created, including the one that we just created. See in here, stage VM is the one we just created running and prior to our demo, I created some instances, I terminated some of them just to give you a feeling of how it looks like. So now, when you run this command, you get human readable summary. But in your scripts, you prefer to get a format that is computer readable, right? So we support formats like yaml, JSON, CSV, and more. So if we run the same command, bypassing the format flag equals to JSON, we would get exactly the same result, but in JSON with more fields available for your scripting.
Let me clear now and let me run the same command instances list. OK. How about next step, maybe you are only interested in the VM that is currently running. So you can go ahead and programmatically filter out the ones that is running, but you don't need to. We also have a command for you that is dash dash filter. When we do that, you can specify any fields equals to any value, so we can get the field to by [INAUDIBLE]. So we wanted status equals the running, right? Let's run it and perfect. This gave me just the running one. So you don't need to programmatically do that. And I also want to mention that you can mix and match the filter and format. Remember earlier we only did the format for JSON. We could also get specific value. We don't need, maybe we are only interested in getting the name of the VM, so we will say a new name run it. Perfect. We get just values of the names. And as a next step, what we could do, take this command and paste it to maybe to compute instances delete, as an input.
So you want to delete after you are done, so you just paste the names to another command. So you can pipe the output as an input to another command. So you can create more sophisticated workflows this way. So with this, we also have more functionalities that is built in for you, like sorting, you can label, and you can do some formatting for day dates and things and many more. So I encourage you to go through the documentation and see other features that could empower your scripts. With this I am done with my demo, let's go back to our slides. Perfect. So today we took the journey of installing Cloud SDK. And we initialized that to be able to talk to services. We picked our user name. We get the project. We set some compute song by default. We created the configuration. Right, and then we moved on to see some components. We ran through the components of bq, gsutil, [INAUDIBLE] alpha commands, beta commands, and specifically for a alpha command today, we saw an interactive shell that lets you get to auto prompting or flags and commands.
So you don't need to context switch as you are typing. This is a perfect tool for you to discover new commands or discover the usages. Then we took the journey of discovering a container builder, and then we moved and we created a computer VM together. Then we moved to create more to see some more advanced features like filtering, formatting, and just to give you an idea to empower your scripts and automate these workflows. Flaws So, as a next step, i really, highly encourage you to install SDK. Please get the alpha components. Try to run GCloud alpha shell, and please give us feedback by running GCloud feedback command. Awesome. Thank you so much. With that, I will give it to Omar to cover client libraries next. OMAR AYOUB: Thanks, Aylin. [APPLAUSE] Great. Still works. Awesome. So client libraries. so we looked at how to use the Cloud Shell, how to run commands and tools, how to use the cloud SDK, again, everything in the shell array using ACLI. Now we're going to talk more about programmatic access to our APIs.
So we have cloud APIS, we have many of them, 35 plus. And what is an API ultimately? It's an interface. You get a version that expects parameters, request body, and you get a response, you have to parse it. Now, of course, you could go and use the endpoint directly and literally code against the endpoint and do all of that off and request in response parsing yourself, but clearly, this is a talk about making things easier. So that would not be fun for anyone. Not fun to get started, and also not fun to just keep going. Right? So ultimately you want to have client libraries that allow you to connect to these services in a fun, idiomatic way. So, in cloud, like I said, we have about 30 plus APIs, 35 plus. About a third of those are now using the new Google Cloud client libraries. So we haven't covered all of them yet, we're working on that, but a good third of them are ready for you to go and play with and have fun with. And the whole idea is to make these libraries more usable, a simple interface, idiomatic, and more importantly, well documented.
Because it can have the best library in the world, if you don't have samples to get started, and good examples to keep going, and more tutorials for how to guides, you'll probably, you know, at some point, get frustrated. And heads up, we actually support seven languages here as well. Again, go Java dotnet, PeachPy, Python, node, Ruby, and everything is open source on GitHub. So again, we'll just jump directly to showing you how to use basically this programmatically. So. Never mind, we switch back to the demo. So, actually we're going to walk through user journey, very simple ones. So you've probably heard about, obviously, the machine learning APIs. It's a big deal, rightfully so. And probably the vision API. So imagine you're curious about it, you want to make use of it, how can I call it? So first thing you probably do is just search for it, right? So we'll walk through that flow and see how you'll be able to make a call as a quick start. So we do a quick search, we see the second line here beautiful is the Cloud Vision API.
So if you haven't seen it yet, the cloud vision is you sent us to a service, an image, we analyze it and we return to you back a response with what is in that picture. Right? And then that analysis, with labels, with scoring, and all of the above. And in fact, if you scroll a little bit on that landing page, you notice there's a try the API. I highly encourage you to try it out if you haven't done yet. So you can just drag and drop a photo. I think we have one ready even. Perfect. And it's the cat. Drag and drop it. Just to show you the kind of information we'll get back. It's simple to pick up cat, 99% accuracy or scoring. It's a mammal vertebrate. So you get all these labels back directly, thanks to the API returning you this information. And by the way, you'll notice a bunch of extra data, like web properties, you can see a color gradient, also it can give you back. And finally, you also have the JSON response, if you want it to parse the JSON. Great.
But you're a developer, so you want to be able to call this programmatically. So we your going to go ahead and click on the View documentation to go a little bit more then what we have here. So this is a very standard documentation. We explain to you stuff. Well, one thing that we're to bring to your attention is that in the reference section, there is a client libraries place or item, rather. If you click on that, that will open the client libraries page. This is why I'm saying we're adding more and more of these across of cloud APIs. And the whole point is to show you how to get started. So how do I install the library, how to set up off and then how to make an API call. So, just for fun we'll try it in Node.js, see what happens. Any node developers in the room, by the way? Yeah? Yeah. OK. Got some It's perfect. So We'll just open, you know, we'll copy the installation. Open a terminal, and then, are we in the right place? Yes we are. Perfect. We'll just empty and install.
While this is installing, we'll go back to the actual documentation and just copy the code at the bottom. Yeah. Perfect. And then open Sublime. We'll just use Sublime for this case, and create a new file. That will call vision.js. So just to walk you through, really quickly, and on happening here. So we basically import the module. Then we have to set a project ID. Our project is called next-sanfran, but the moment you've created initially you log onto GCP and you're in that console UI, you create a project is your first thing, you put the ID here. You incentiate the client, then you specify a local resource in this case of what is the file you want to analyze the image, and then you call the tech labels. That's it. Now in our case, we don't have wake up cats, so if you open where we have, actually, the resources. We call it picture just to and then you'll notice that it's actually the Eiffel Tower. So, we're going to ask the Vision API to figure out where the heck this is.
So back to the terminal, we'll just run a basically. The terminal actually. Oh sorry. She's better than me. You can tell. A note, pass, and vision. what we get back is a bunch of labels, which is perfect. Tower landmark, monuments. Everything you would expect from this, right? The thing is, we know this is the Eiffel Tower. So how come we didn't get the Eiffel Tower? Because we asked for labels. We didn't ask for a landmark. So just a heads up, if you go back to the cloud documentation, there's always these how-to guides that we have. And these are meant to show you how to do something. And given that this is an API, the whole point is to show you how to do different calls on the API and how to make use of the API. So if you click here on detecting landmarks, you'll notice that we want to show you in our seven languages, right, all of the samples and all of the examples per language. If there's language missing or two missing, it's just because it's coming.
We're working hard at adding all of that. But again, to make you productive. So in this case, GS is selected. You look at the example. It's pretty much the same as the quick start we saw earlier. Only difference is at the bottom, we're calling detecting landmarks. Great. As simple as that. We can copy this, go back to the code, update the call. And then, oh yeah. Perfect. And if we execute it, you'll notice that it will– well, let's not predict the future. There we go. It figured out that it was the Eiffel Tower. Notice that there was no scoring on this, because this is a non-verbals version. But if you wanted to make it more verbose, you can have and pass a bunch of options. And for that, one last quick thing, if we go back to the client libraries page, at the bottom there's always an additional resources that we're adding. Just to let you know, you have links over there to basically the API reference documentation, you have links to the source code. You want to ask a question on Stack Overflow.
And, just to let you know, within the client library reference, so the API reference, we're adding a lot of examples, also, in there. Just to make sure that as you're learning about the API, looking at different methods, we also have an example right there to help you to make it simple. And lastly, everything is on GitHub, so just as an FYI, if you go into Google cloud platform organization, we have all of these repos. Google Cloud NODE, Google Cloud Ruby, in all seven languages. Now, if you're wondering, is that, how come we talked about the seven languages earlier with the Cloud Shell, we're talking about now seven languages with libraries, is that coincidence? Well, actually it's not. There is a cloud GCP wide effort of bringing you forth the seven languages as first class citizens. We want to make sure that, as a developer, when you come to GCP and you want to put on your– My language lens and be able to look at GCP from that lens, we have the documentation for you and the tools for you and things to get you started.
So, if you actually go to cloud.google.com/docs, at the very, very top, you'll notice that there's a bunch of languages. These are the languages that we support. In fact, if you click on Java, for instance, you'll see that this is a landing page for Java. We have quick start. We have tutorials. We have code samples. All of that with the idea of, you're a Java developer, you want to learn about this in a Java reality, with a Java lens. Right? We've got you covered. So you can learn about App Engine Flex, App Engine Center, all of that using Java. In this case, if you click on Tools, we also have a bunch of tools for you as a Java developer. Remember how in the console UI, we used a debugger, we used, ultimately, to class those repositories, all these tools that we had for you. Well, if you're a Java developer, you probably use an IDE, right? So, until inteli-J, or Eclipse. So we kind of need to have all of these tools directly in your IDE, so we don't have to move away from your IDE, and stay in your environment and work from there.
So, in the last part of the demo, we'll actually show you that. So we've already preinstalled the IntelliJ plug-in, and IntelliJ itself, and if you open here, we already have a project created. , So just a heads up, if you were to go to the App Engine Flex documentation, there is a quick start there as well, that has a code sample. So we basically just git clone the repo, which is called Getting Started Java, and you notice there's also some code there. So if you wanted to look into this a bit more, I encourage you to go into the App Engine Flex Java quick start. But all we do, is that we install IntelliJ, we install the plug-in, we Git clone in the repo. So now we're ready to go, and we have that open right here. If you look, it's very simple. All we do again is the Hello World, and we do a do get. Right? We handle the get request. So we want to show some of the tools we have in IntelliJ, but before doing that, just make sure that Java developers know we have some love for them as well.
It's also as easy to get started with the client libraries. So in this case, we'll just use a Translation API. Translation API, another one of our machine learning APIs. If you go to a client libraries page, now that you know about it, you see that we have, in this case, our Maven dependency. So we can hop back to the Getting Started, open the pump file, and then just add this as a dependency. Great. This is done, and now we can copy paste, also, the code. So, just to explain what the code does. Ultimately, it incentiates the client, right, defines what text we want to translate from one language to another, and therefore, after that, we simply have a source language and the target language. So in this case, we just copy pasted the imports, and I will copy paste this part. Lovely. And then you see here, we translate from English to Russian. We'll probably just try French, just Eiffel Tower moments. And then we can just. Yeah. Perfect. And Yeah. Obviously, we're now printing this to the console, since we want to return this to the browser, we'll just update what we return back.
So, by the way, we also installed the Jetty plug-in, so if, as a web server, you might use something else. Tomcat, for example. But in this case, Jetty works well. If we run this, this will basically do a local testing of the web app and then we'll just show you how quickly and how easy it is while Jetty is loading this. And if you do a quick zoom, for those know French, hello world is Bonjour le Monde. We got it. That simple. That quick. That easy. Cool. And, the last piece, really, here is just to make it clear is that, we talked about doing all these workflows and the cloud UI. You can say like, Do gits, push to cloud source repositories, as a remote repo, do debugging, upload your App Engine. Well, because we installed the cloud tools for IntelliJ plug-in, if you click on tools, you'll notice that we have the Google Cloud tools menu or entry here, and you can do exactly what we did earlier. You can set up the Cloud source repo there. You can attach to a debugger, and do live debug.
You can deploy to App Engine standard and App engine flex. In fact, if you click on Deploy your App Engine, you'll notice that you can select your project ID, you can set some information about your application, just like we did earlier, and push it up to App Engine, and have it run and scale up and scale out. So Yeah. That was that part. We can switch back to the slides. Lovely. So again, the whole point here is that we want to make the developer experience easier, so you want to use Node, you want to use Go, .NET. We want to give you client libraries that are easy to use, well-documented. We look at vision with Node.js, we look at the Translation API with Java, disk cloud tools and for IntelliJ. But we have that for Eclipse, we have that for Visual Studio. Again, all with the idea of meeting you where you are as a developer. And if you want to learn more about each of these languages, I recommend going to one of these language documentation set, and learn about the tools that we have for you, and we'll keep adding, them making them better with the developer in mind.
Great. We can jump in to the wrap up. So, this is everything we covered. Cloud shell. Cloud SDK. Cloud client libraries. And if you want to dig deeper, in more of these, I suggest looking at these talks. So, some of them already happened yesterday. Some of them are happening, I believe, this afternoon and tomorrow. Ruby, I think, is right after this. If you want to learn more about how we're supporting your language in GCP, [INAUDIBLE] is something that you want to look at. And also, the videos will be online, so you might was to look into that. And finally, as next steps, sign up if you're interested in cloud shell. You can do cloud shell pro. Sign up at this bit/ly link. Learn about it. Let us know what you think. We want to make sure that we hear you. Download the latest Cloud SDK, just like Aylin was saying, to try out the alpha features and play with that, and you can send feedback at GCloud feedback. [INAUDIBLE] back. And then, try to client libraries. For everything we talked today, you can go to this link, which is a GitHub repo Next-17 under my username.
Just to see all the stuff we talked about, links, and the form for Cloud Shell pro. So everything will be in one place so that you can refer back to this. If you have questions for me, you can also just file and issue. I'll be happy to answer. And that was it. That's it. Cool.
Google Cloud Platform (GCP) has tools built by developers, for developers, using many languages. In this video, Omar Ayoub demonstrates libraries, IDE integration, framework integration and other tools that make developing applications on GCP easy and intuitive for developers.
Missed the conference? Watch all the talks here: https://goo.gl/c1Vs3h
Watch more talks about Application Development here: https://goo.gl/YFgZpl