WEBCAST

In everything that we do over the course of this webinar is going to be framed from the perspective of a real application. So just to hop right in and give a little bit of information about our application, what we’ve got here is a simple web app that’s backed by an API. And again, we made this application intentionally simple for this webinar, but the concepts we talk about will generalize and do generalize to any arbitrarily complex system. So the system that we’re talking about today is a simple web app backed by an RPG program. So we’ve got a web page here that I can visit, it’s actually publicly available. And I can come in here and type in a number. And when I hit the calculate button, what’s going to happen is it’s going to send out an API call with JSON data up to a Node.js application that’s running on a cloud IBM i, I believe in Virginia. It’s going to call an RPG program running on that IBM i, it’s going to pull out the parameter data, the output parameter from that application, and it’s going to show it in my interface. And so when I click the calculate button, you can see that I get the result from that RPG program. And so there’s a lot of components that go into getting this set up. And so everything we do, we’re going to go through those critical concepts. So before we get into working with JavaScript, obviously, one of the first things you’ll need to do is get set up, get JavaScript installed on your IBM i so that you can actually use it. We’re not going to cover that in this webinar. But if you need help getting that set up, you can head over to Eradani.com slash resources. We did a webinar a couple of weeks ago, called 11 million developers on your team. And that webinar goes through the detailed process of how to get up and running with JavaScript with Node.js on your IBM i. So again, if you need that, head over there. But we’re not going to be covering that in this particular webinar. So we covered our simple application. And what we’re going to do next is we’re going to hop into these critical differences. 

So there are three main core differences between JavaScript and a procedural language. We’re going to be using RPG for this example, but really any procedural language would fit in this comparison. So number one on our list is the asynchronous event-driven nature of JavaScript, as opposed to, in the RPG example, synchronous and procedural code. What that means is that JavaScript is designed to run in tasks in parallel. It’s designed to work with events. And where that comes from is, if you think about a web interface, you think about a web API, you’re not getting a data record, do a process, finish. Next data record, do the process, finish. You’re not just going through a cyclical process over and over again. What’s happening is you’ve got a user on a screen. They are clicking here, scrolling there, typing there, clicking another button. They’re doing things in a random order. And so when you’re working with an interface, you need to be thinking in this asynchronous event-driven mindset so that you can handle that chaotic environment. So that’s one of the core differences, and it’s the first one we’re going to cover because it’s typically the hardest to wrap your brain around when you’re new to it. The second one we’re going to talk about is the availability of open source packages. This radically changes the way that you develop code when you’re working with open source technology. When you’re working with something like RPG, if you want to write an application, you’re going to have to write pretty much all of the code for it yourself. When you work with something like JavaScript, you do a lot less writing code and a lot more wiring packages together that you get from the community. So it’s a critical difference when you’re talking about these two languages. And finally, we’re going to talk about the flexible types of JavaScript, and this is also very important in an API architecture because in an API, you never know what you’re going to be getting as your input. Users can give you bad data, they can give you missing data, they can give you whatever they feel like, and your application needs to be able to handle that gracefully. And so JavaScript does not enforce any data types, which is going to be very different from RPG and most other languages where you specify exactly the type of something and how long the field is and what precision you have on your decimals. You don’t do that in JavaScript. So with those three, we’re going to hop into the first one and get started here. So our first section, like I mentioned, is asynchronous versus synchronous code. We’re going to hop in and we’re going to do a little bit of JavaScript here. So this window that I just opened up is my Visual Studio Code editor. This is where I work with my JavaScript code. You can find this editor online, just Google Visual Studio Code. You’ll find it. It’s one of the most popular editors out there. It actually also happens to be written in JavaScript, which is just a little fun thing. But so when I work with this tool, Aaron, I understand, doesn’t Visual Studio Code also have an RPG plug-in so you actually could use it for RPG as well? Yeah, yeah, it actually does. And I’m actually going to show that later on when we talk about, when we wrap things up, actually, I’m going to show you the RPG program. Yeah, so I use Visual Studio Code for everything. I use it for my JavaScript. I use it for my RPG. I use it for my CL. I use it for everything that I do, SQL, whatever it is. It’s a really, really wonderful tool, and it’s completely free, by the way, just pointing that out. So we’re going to write a little bit of JavaScript here. So as a baseline, we’re going to do a console.log. So when you work with JavaScript, what you write are typically these calls on, it’s based around these global functions that you have available. So the first one, and one of the most important to understand when you’re starting is console.log. Basically what console.log does is it says display some text on the screen. So you can imagine when you’re starting with JavaScript, it’s going to be a really useful line to know. You can display out variables, display out text, gives you a baseline as you’re writing your code. And you can see if I run this code down in my terminal down here, I get some text down at the bottom. So we can see down in the terminal the output from my JavaScript program. Now what I really want to demonstrate here is the asynchronous nature and walk you through the basics of that. So let’s say we have an application where we have to do three tasks. So first, and we’re going to do all console.logs, but obviously these would be different sets of business logic, database reads, whatever we have to do. So we got our first task that we’re going to complete. Then what we want to do, we want to wait a little bit. And we want to do our second task after a small delay. Then we want to say do our third task at the end. Now in a procedural language like RPG, what you would expect to happen with this code is you would see first out in the terminal, then you would see after a delay, you’d see second, you’d see your second task completed. And then you would see third. They would be done line by line in order. If I actually run this, you’ll see in my terminal that that is not what JavaScript does. The output we actually get is first, third, second. And this is one of the most powerful features of JavaScript and simultaneously one of the hardest ones to get used to. What JavaScript does here is it does the first task and then it realizes, okay, I’m supposed to wait a little bit for that second one before I do it. So why would I spend that time doing nothing? Why would I just waste that time sitting idle? What I’m going to do is I’m going to go on and I’m going to do the next thing that’s on my to-do list and I’m going to get that done. And then once that second task is ready, I’m going to come back and I’m going to finish that. And so that’s what it does. It does first, then it does third. And then once second is ready, it goes back and it does second. And when you work with a JavaScript application, all of your code is going to work like that. And so it’s a really important thing to really make sure you understand when you work with JavaScript. And that’s not just a, you know, that’s a simple example, doing logs in a timeout. To give a more direct example, I could pull up a more real example. I could pull up something like this. This code here is making a REST API call. So over here, what I’m doing is I’m reaching out to an external API and I’m getting data from it. Right? And that’s something that can take a long time to get that data back. You know, I mean, from a computing perspective, if it takes 300 milliseconds to get that response, you don’t want to spend 300 milliseconds sitting idle. And in a real process, you’ll often end up with many of those requests happening. And so your system will be a lot more efficient if you can use that idle time well, rather than just sitting there and waiting for your, you know, just waiting for your responses to come back. So to help this be more relatable, I’m going to hop back in here and we’re going to talk about one of our favorite examples around asynchronous versus synchronous. And our example here is, our analogy is a coffee shop. Right? So let’s say that we have a, we have a coffee shop and the way our process works as a simplified model is a customer comes in, they place their order with the cashier. Then when that’s done, the cashier passes the order back to the baristas, the baristas make the drink, and then we deliver it to the customer. And then we move on to the next customer. Right? So in a procedural environment, in an RPG like environment, what you’re looking at is take the customer off the stack, basically, take the order, make the drink, done. Next customer, order, drink, done. The downside of that approach is that while the order is being taken, the baristas aren’t doing anything. They’re sitting there. They’re staring at the wall. I don’t know. They’re just not doing anything. They’re sitting idle. And while the baristas are making the drink, the cashier is sitting there staring at the wall and the second customer is just sitting there waiting and can’t do anything. And when you look at a longer example, like let’s say that we have three orders that we have to take, we’ve got three people in line, your timeline looks like this when you do the procedural architecture. And that is you take the first order, you make the first drink, you deliver it. You take the second order, you make the second drink, you deliver it. And it ends up taking a long time with a lot of idle time. Now, from an asynchronous standpoint, your timeline looks more like this, where what happens is customer one comes in, they place their order. And while the baristas are making drink one, the cashier is still working, taking order two and taking order three. They’re working at the same time. They’re working asynchronously. And then at the end, what that allows us to do is, first of all, double up the work from the beginning. And once we finish taking all the orders, we can repurpose our resources, that cashier, and move them back to making drinks so we can make even more at the same time. The end result is that the asynchronous architecture is able to get this job done in a little bit more than half the time that the procedural synchronous system took to get this done. And that is, in a nutshell, the biggest benefit when you’re working with JavaScript. And that’s why when the web world transitioned, really, in its new application development from PHP to Node.js, we saw applications suddenly running 20 to 100 times faster. And that’s because in the older systems, things are done synchronously in a procedural manner, and there was a lot of idle time. When you work with Node.js, everything is utilized to its maximum possible potential. And you have to make sure that your code is designed to handle that. So just to give a quick overview of what we just talked about, we just went through the asynchronous versus synchronous procedural example and the core differences in that sort of model and why you want to use that.

In a web API, in a user interface, where you’re getting this chaotic event-driven environment, that is going to make your application much, much more stable, much more performant. And once you learn how to work with it, also easier to write. So the next benefit, or the next difference, really, that we’re going to talk about, we’re all going to talk about benefits, but the next big difference that we’re going to talk about when you work with JavaScript is that open source versus proprietary technology. And where that really comes in is when you work with open source technology, you spend a lot less time writing code and a lot more time just wiring packages together, right? So when you work with JavaScript, you would go to NPM, NPM is the Node Package Manager, and look for the packages that you need, rather than trying to write them yourself. So for example, if I need an XML parser, or I need a library to connect to my IBM i, if I need IoT libraries, those things are already written for me, and I don’t have to do them myself. And just as an example of where this really becomes powerful, you know, it’s not just a little change in the way you write your applications. This screen here is the Cloud Storage Solutions for i web application. This comes with your IBM i. This application was built by our team. And when they were working on this, basically what this application does is allows you to back up objects on your IBM i up to different forms of cloud storage. When the team was working on the green screen version, where they had to write everything themselves, they wanted to talk to Amazon, AWS, S3, they wanted to talk to IBM Cloud and Azure, they had to write those themselves. The green screen application took six months to build. And then the team turned around and worked on the JavaScript version, and it took four days. And not only did they get it done in four days, they were actually able to put in more

features in those four days than they got in six months of green screen development. Because they wanted to connect to Amazon, well, Amazon had already written all the code they needed. So they just downloaded that, wired it into the application. They wanted to show these objects in a tree layout, like you see on the screen, was already done for them. They didn’t have to handle any of that. And the same goes for the security, the authentication, data validation, everything that goes into an application was already done for them. So to give you an example, we’re going to focus down a little, because in a real application, you download lots of packages, we’re going to focus on one. We’re going to focus on HTTP calls. So if I wanted to make a REST API call from a procedural language that doesn’t have access, if I wanted to write it in RPG, there are some tools that you can get that will help you with that. But at the end of the day, you’re going to end up writing a lot of the code yourself and doing that connection management, that authentication, the JSON parsing, you’re going to end up having to do a lot of that yourself. When you work with something like JavaScript, if I want to make HTTP calls, what I’m going to do is I’m going to say, okay, I want to hop over to NPM, open up NPM in my web browser, where by the way, I just want to highlight this on the screen. There are just under 1.3 million open source packages that are being downloaded just over 20 billion times a week, right, so this is an extremely large community. Now I want to make HTTP calls, so I’m going to search HTTP and order by the popularity. And what comes up, number one, outside of the exact match, is Axios, Axios is a library that I can download that will make REST API calls for me and handle the entire thing. Now I want to point out a couple of things here, because we get a lot of common questions about this when we talk about open source, you know, how can we trust them, how can, how do we know it’s secure, how do we know it’s reliable? The biggest way, the biggest thing that I look for when I’m working with one of these packages is this right here. I can see the number of weekly downloads of this package. This particular package is downloaded just under 10 million times a week. And the thing is that when you’re getting 10 million downloads a week and you’ve, that means you’ve got probably hundreds of thousands, if not millions of developers using this module and trying every which way they can to break it. And that means that this module is going to be extremely reliable and extremely secure. Because you don’t get to that kind of usage without making those things. So that’s just one of the biggest things that I want to point out here. One of the most important criteria when you’re looking at an application. You can also see things like what’s their test code coverage, you know, how can you reach the developers, what kind of support do they have, the kind of stuff that we can see in here. Now if I want to use this package, right, so I just found this on the NPM registry. Now I want to use this package. What I do is I flip over to my terminal and I say, and this would be your SSH connection to your IBM i. And again, if you’re not familiar with SSH, go take a look at our 11 million developers on your team webinar. We go through the basics of what it is and how to work with it. Long story short, SSH is open source’s version of 5250, it’s how I send commands to a machine. What I would do here is I’d say NPM install Axios, that name that I found in the registry. And when I run that, NPM goes out and it figures out how to get Axios for me and it downloads it for use in my application. And then I can hop over to my editor here. And that’s what allows me to write this code. So what I do is I come up here and I say, at the top of my file, I say require Axios. And what that says to Node.js is, okay, I have this module Axios installed, go get it for me and import it. And then what I do is I store it in a variable, so I create this const variable. What that means is const right here, so I’m creating a variable named Axios and I’m saying it’s a constant, you can’t modify it, it’s going to be the same for the whole duration of the program. In JavaScript, that’s a recent JavaScript feature, it will give me an error if I try to edit that. It’s just a best practice when you’re working with modules because you don’t want to accidentally modify a module you imported, that just makes everything difficult. So I import the module, I give it a name, and then what I can do is I can come in here and I can just use that freely. So I can write stuff like this Axios.get that you see on line five of this file, and I give it a URL to go run an API call against. And when I run this code, this particular API is a great demo API, it’s the Chuck Norris joke API. What it does is you fire up an API call in JSON, it gives you back a random joke about Chuck Norris in JSON format. And one of the things that’s really important to notice about this code is the asynchronous nature here. We’ve got task one, where we say, I’m about to run the request. We’ve got task two, where we actually run our request. And we’ve got task three, where we do something else. And the critical thing to point out here is we want to log out the joke that we get back to the terminal, we want to display that text on the screen. But the question is, when do we do that?

We have a dependency here now, which is not something that we had in our previous example, we have this console log that has to happen after the API call finishes. So you can’t just run these completely separately, because otherwise, you’d try to log it before the API call got back to you. Because of that asynchronous nature, right, JavaScript is going to do things as fast as it can, and it’s going to try to collapse those tasks together if it can. So what we do, the key to that is this right here, is this dot then. Basically what I’m doing here is I’m saying make the API call. And then when that API call is done, do this. And that is the core of most JavaScript code. When you are writing JavaScript code, most of your code is going to function like this, where you say, okay, I’m going to do this. And then when that is done, I want to do this next task that’s dependent on that. And what that allows you to do is say, okay, this task is dependent on the API call. But this one is not, this one at the bottom, that line 10, do something else, that’s not dependent on the API call. So I can set up loosely the order that things need to happen in, but still get the power of JavaScript and of the Node.js engine in figuring out how to do my tasks, how to complete them most efficiently. And if I actually run this code, we can see that in the terminal, the output that we get is this about to run request, then we get do something else while we wait. And then a little bit later, we get our response from the API, and we see our joke in the terminal. Right? So we’re getting that response from the API and extracting it from the JSON. And so these modules apply to just about everything that you’re going to look at, right? So what we’re showing here is pulling in an API call module so that you can run API calls. And again, npm registry has 1.3 million, just under 1.3 million modules available for you. So pretty much whatever you want to do, there’s probably a module that does most of it. And so you’re going to end up pulling in a lot of modules for your code. And that holds true also for when we’re talking about connecting to the IVMI, or any other system like that. And actually, we’re going to hop over and show a quick example of how you would do that. So in our sample application, we had this web app where I load up my web page, and I’m calling an RPG program behind the scenes. Now calling an RPG program is very, very complicated. You have to do a lot of formatting to get your Node.js code talking to your RPG. You have to authenticate with the IVMI, make sure the data is in the right format, make sure that everything’s good, everything’s working properly. It’s a whole complex affair when you want to get this done. And so when I want to call an RPG program, I don’t want to have to write all of that code myself. So in my case, what I’m going to do, I’m going to install a module that handles that for me. And this module is the Eradani Connect module. This is available on NPM that will allow me to work with my RPG assets, all my IVMI assets, the same way that I work with the rest of my code, and handle all of that for me. And to show a quick example, we had our RPG program, which is a very simple RPG program for this demo, basically just takes in a numerical parameter, multiplies it by 40, gives me the result back. But obviously, again, this will generalize to any arbitrarily complex program. If I want to call that program, what I need to do in my JavaScript is open up my controller and import my connector. So I’m going to do that require again, like I did with the Axios module, I’m going to say require this Eradani Inc, Eradani Connect. I’m going to give it a name. And then from that point on, I can use this module however I want, right? So I can say, all right, open up a connection to the IVMI, which is what line three is doing. And it’ll handle that entire process for me of authenticating and connecting and making sure everything’s encrypted and secure and actually managing that connection. And then when I want to call my program, I write three lines of code. And all that code has to say is go execute my program with these parameters. Now behind the scenes, of course, there’s a ton happening that has to happen in order to get that program call working, but I don’t have to worry about it. What I get to worry about is the features I want to deliver to my customers, to my users, and the actual business logic that I want to write, rather than all the plumbing and infrastructure that has to go into those things. So that’s a real world example of what you do and what you use these modules for. And as I mentioned, in a real life application, you don’t work with one module, right? Both of the examples that I showed you were one module. We had Axios and we had Eradani Connect. It’s one module each. When you install a Node.js application, you tell it to go out and get its dependencies, you get this cool little message that’s my favorite part of the installation, which is this highlighted line that says, added 605 packages from 907 contributors, right? So this line is actually the line for that sample application that we’re looking at for this demo, the one that I showed you. And what this line is telling us is that when it set up the application, Node.js went out and grabbed 605 different packages that were built by 907 different developers, right? So when I go in to build an application as an open source developer, I could be working alone, but from day one in this template application, I’ve got 907 developers backing me up and I’m working with their code. And so you can imagine how much faster development can go when you take advantage of that. And so one of the most important points when you work with JavaScript is to remember that those modules are there and to get that into your muscle memory, that when you want to write something, if you think it’s a common function, check for a module because it’s probably there.

And just to be upfront, 907 contributors is actually fairly rare for an application like This. You’re much more likely to see numbers like 5, 10, 20,000 contributors on a real application because of the breadth of the features and the modules that end up getting pulled in. So you’re talking about huge, huge resources that are at your disposal. So just as a quick recap of that section before we move on, we went over open source packages and how you can use them in your JavaScript applications. You do that npm install to get the module after you look it up on npmjs.com. Then you do require with the module name in your JavaScript code, and you store that in the variable. And from then on, you can use your module throughout your code. And that’s going to, trust me, it will radically change the way that you write code. So number three of the critical differences when you work with JavaScript is the flexible types versus rigid data structures. So when you work with JavaScript, you’re working typically in an API or a user interface. And what ends up happening is your data types can change at any time. And the important point here to remember is in an API, you do not have control over the point of data entry in your API. And what I mean by that is in the RPG world, you control the screen, you control what a user can actually enter into your application and what the types are that they can enter. And you can give them an error if they give you the wrong thing. In an API, you don’t get to do that. They send whatever data they feel like sending. And it could be the wrong type, it could be the wrong structure, it could be missing, it could be corrupted, just about anything can happen. And so you need to have a language when you’re working with an API, you need to have a language that can handle that complexity and deal with it gracefully. So when I go into my JavaScript code, and I just want to give you a quick example before we move on, I can create in this code, as an example, a variable, calling it my variable here and store a number in it, just to illustrate this. So I’m taking this variable, I’m storing a number in it. And then two lines later, I’m coming in here and I’m replacing that with text, I’m overriding it, I’m storing a completely different type in there. And JavaScript has no problem with that. It handles that just like it would handle anything else. Right after that, I store an object in there, an object is analogous to a data structure in RPG. After that, I store some code in there, I store a function in there, which is basically just a reusable block of code. So I’ve taken this variable, I took it from number to text to data structure to code, and JavaScript has no problem with those transitions. And that gets really important when we start talking about real functionality, when I want to work with data, JavaScript is going to do its best to convert between the types that I give it and figure out what I’m trying to do, because again, we never know what we’re going to get from the API. And so in this particular example, I’m going to run this console dot log, and I’m going to add together a number and some text. So I’ve got the number 1000, and the text ABCDE. And I’m telling it, add those together, do addition on those. And if I run this code, what I end up getting in my output is 1000 ABCDE, I get the text 1000 ABCDE, because what JavaScript does is it converts that 1000 to text so that it can concatenate the strings, and it does the best job that it can. So that’s one of the really important points to understand when you’re working with JavaScript. And this is, again, really, really important in an API. And I want to show you an example of where that gets particularly important. I’m going to show you output from a real API. And this API is the Google Maps geocoding API. Geocoding is just a fancy term for taking in a latitude and longitude coordinates, and giving back all the results about what is present at that location, according to Google Maps. And when I run this API call, I get back a JSON structure down here that has these results. So I’ve got JSON here, I’ve got plus code, I’ve got results. And if I open up that results, I’ve got an array of data here. Now this array, in this particular case, has 13 elements, but it could have zero, it could be missing entirely, it could have half a million. I have no idea what I’m going to get back from here. And within that array, each element is an object, is a data structure beyond that, that has its own nested arrays and its own nested components. And if I open up these address components, I get another array that has an arbitrary, I don’t know, number of elements. And each of those elements is a completely different length. But if I look at these city names, or if I look at the component names, actually, I want to point out, like, I could look at Williamsburg is completely a different length from Brooklyn. But in the JSON, it doesn’t care, and it doesn’t tell me how long these fields actually are. And so when you’re working with a complex API like this, in a procedural language that doesn’t handle that complexity, as naturally when you’re working with something like RPG, you have to figure out how to parse that JSON. And that can get very complicated. Whereas in JavaScript, what I would do with this JSON is I’d come in here, and I would say JSON dot parse. And that’s everything that I have to do. When I run JSON dot parse, it’s built into the JavaScript language, it will parse out the JSON and get me a format that I can actually work with. So again, that uncertainty becomes very, very important when you work with an actual API. So as a recap, I wanted to go back over the critical differences that we went over in this webinar. Number one was that asynchronous event driven architecture of JavaScript, as opposed to the synchronous procedural of RPG. When you’re working in an API, you’re working in a chaotic environment, where you need to be able to handle these rapid fire events coming at you from all directions. And that’s where you need that asynchronicity. You have open source packages, so you end up not so much writing code, as you are wiring in packages. The vast majority of your code is going to be downloaded from other sources, not written yourself, which allows you to write code a lot faster. We also went over how you can make sure that those modules are reliable. Again, number one, look at the weekly downloads. If you see a module that’s being downloaded 10 million times a week around the world, trust it. If you see one that’s not being downloaded at all, maybe not. And number three is flexible types. When you work in this uncertain environment, you can get anything from your users, and you need to be able to handle that gracefully. And the conclusion here, and the really big takeaway from this, is if you are writing a web API, either making calls or taking API calls, if you are writing a user interface, do it in JavaScript. JavaScript is the best language that you will find for writing those kinds of use cases. If you are writing complex, CPU-intensive core business logic, that’s a great use case for something procedural like RPG, and it’s actually something that JavaScript isn’t good at. So one of the big takeaways here is use the right tool for the job that you’re trying to accomplish. And just as a quick wrap-up, I wanted to go back to our sample application here and show you, again, this round trip. When we look at this application, remember, I as a user come in here, I type, I scroll, I click, and the API needs to be able to handle that environment. And I can give it whatever I want, right? A user, I don’t have control over this interface, so a user can come in, they can give me text, they can give me nothing, and I have to be able to handle that. And that is where JavaScript becomes a really, really powerful tool. So thanks for listening to that. I’m going to kick this over to Dan to wrap us up. So Dan, take it away. Great. Just to share my screen here. Okay great. Thanks, Erne. That was a wonderful overview. We got some good ideas of concepts of how JavaScript works, some examples of how to code in JavaScript, and some of the tools that you use. So thank you for that. I’m going to just run through to wrap up some quick examples of real-life things that people have done with JavaScript running natively on the IBM i. So Aaron showed this. This is the cloud storage solutions for IBM i. This is an Angular and Node.js application running natively on the IBM i. And what’s great about this is it’s a two-way connection, so there are things happening where you initiate an activity from JavaScript, and you send that information to the IBM i, and you have the IBM i do things, and there are other things where the IBM i is actually doing something. So for example, when it’s transferring the files, when the file is done transferring, it then sends information back and executes an operation inside of the JavaScript. So it actually connects both ways, from JavaScript to the IBM i, and from the IBM i to JavaScript, and you get this very, very modern user interface into IBM i functions. This is an example of a plugin written to connect an open-source tool or a popular development tool. 

So this is Jira. Some of you may be using Jira for issue tracking. It’s probably one of the most popular issue tracking tools out there. So you can do all of your issue tracking in Jira, but what’s happened here is we’ve used JavaScript to connect to the IBM i. So this is Jira running in the cloud with a JavaScript plugin that connects to the IBM i and runs JavaScript on the IBM i that gets information from a development tool, so it can display inside of a Jira issue what objects are people changing, what source code are people changing on the IBM i, and where is it in the life cycle? Is it in development? Is it in test? Is it in QA? So it’s getting information from the IBM i directly and adding it into this Jira ticket. So there’s no user interface built here in JavaScript. There’s a plugin to Jira to talk to the IBM i. This is an example of a JavaScript application that a customer had a green screen application for doing inquiries into orders and shipments of their products, and they wanted to be able to view that through a web user interface. So this is a whole web UI built in JavaScript that then accesses all the data from the IBM i. You can see it gives you the ability to put graphical elements onto the screen, to put a lot more information on the screen, so there are a whole lot of things you can do because now you’re building your user interface in JavaScript. And then this is one more example. This was a beverage distributor who wanted to be able to take what were a whole series of very, very, very packed green screen panels and put them up into a web UI. So here you can see they can pull up a list of their customers. They can drill into a customer, and they can see categorized information about that customer and drill down into even more detail about the customer. And it’s a JavaScript responsive application, so if they view it from their mobile device rather than from their terminal, you can see it resizes the screen. It moves the menu to the top, so it’s responsive to the device that they’re working on. So you get a lot of capability, things you can build very, very quickly to really upgrade the experience of working with your application by using JavaScript. And that’s because you have this ability to connect from JavaScript or from open source into your IBM i, and the idea is to create a layer so that from the JavaScript side, I don’t have to really know anything about the IBM i.All I want to be able to do is do a call to a resource and then get my response back in JSON. I don’t want to have to know how do I translate that JavaScript call into a RPG program call or a stored procedure call or a command call or database. I just want to say, go get me this stuff and have the system then give me back JSON data. So the idea is to have this middleware, and that’s what Aaron downloaded during the demo was this middleware that made that possible. And that middleware goes both ways, so I can go not only from open source to the IBM i, but as an RPG programmer, maybe I want to go get something from open source, so maybe I need to connect to my transportation partner and get data about where my shipment might be, or maybe I want to get weather information, or I want to get government information from a government website. But as an IBM RPG programmer, I want to be able to work the way I’m used to working. So when I need a resource, I do a call with parameters. So as the RPG developer, I want to be able to run my call with parameters, and then at the end, get data back as parameters into my RPG program. I don’t want to have to worry about what are all the things I have to do in order to talk to the open source code, and I don’t want to have to worry about parsing that complex JSON that I get back, just give me parameters back in response to my call. So again, that module that Aaron downloaded provides that connection so that you can go from your RPG program out to open source. The idea being that the open source people do things the way they’re used to doing things, the RPG people do things the way they’re used to doing things, and the translation is happening, and all that connection is happening from a module that they can download. And at the end of the day, what we’re trying to help people do is create an environment that is very responsive to change. This is a book I’ve been reading recently called Anti-Fragile, and Anti-Fragile, the idea here is that organizations that thrive on change survive and do better than organizations that really are afraid of change, that don’t react well to change, and the point of having a productive development environment like JavaScript and a flexible environment like JavaScript is to help you be antifragile, to help you be able to change very, very rapidly. So this is just a couple of concepts from the book. Anything that has more upsides than downsides from random events or certain shocks is antifragile, the reverse is fragile. And I had a conversation with a customer just this morning that really brought this home to me. It’s a company that’s in the restaurant supply business, and you would think, gee, this would be a really, really difficult time to be in the restaurant supply business. And yet, what they’ve done is they’ve pivoted and they’ve created a whole new set of product lines for how restaurants are going to have to operate in the near future. So things like no-touch menus, things like shields for cashiers, so they’ve come up with things for disinfecting plates and things that they use for serving food. So they’ve come up with a whole new line that they think is going to be a big, successful new operation for them, and they’re doing it to respond to this unexpected shock. So you want to be in that position where you can respond quickly to changes that are being made. And what this also says is anti-fragility is the property of things that actually survive. If you don’t stress things with change, they tend to die off. So you want to actually have things that force you to respond to change. So some of the things you do with JavaScript is create that environment where you can respond quickly to change. And if we look at it, so fragile being resistant to change, antifragile being something that is responsive and thrives on change, a lot of people think that the IBM i is something that’s fragile and resistant to change, and open systems are things that thrive on change. Well, the reality is the IBM i actually is very antifragile. It has so many capabilities, and we talked about running JavaScript and running service calls and doing modern things on your IBM i. It’s all available. It’s really been much more the IBM i culture that has made it difficult to respond to change in that we continue, and I certainly include myself in this, we continue to use green screen applications. We continue to do things the old way because we can, and we’re comfortable doing that.

At Eradani, what we’re trying to do is encourage people to look and see what are all the other things you can do? How can you make that IBM i environment antifragile and to thrive on change? Because the reality is that the IBM i is not the green screen only, RPG only, DB2 only environment of applications that have been built over the last many, many years. That may be the core of what it does, but you can do all of this great new stuff with it. There are all kinds of new things you can do, and you can do the latest in Windows interfaces, in web interfaces, in mobile interfaces. You can do service interfaces. You can run open source. All of those things are available. In fact, there’s very little that you can do on a Linux or a Windows platform that you cannot do on the IBM i, so it is a great platform for new technology, and so with that, I’m going to wrap this up. We do have our next webinar coming up, which is going to be talking about the whole idea of services and service enabling your IBM i and using services from within your IBM i program. We haven’t set a date for that, but we will notify everybody as soon as that date is set in stone so that you can come to it, and you can always check out the Eradani website to find out what the latest is and what we’re doing, and with that, I think I’m going to turn things back to Callie to see if we have any questions in Q&A.

Yes, we do have some questions, but we’re only able to fit a couple in, so if we could, the first one is for asynchronous programming, I’ve heard of callback help. What is it, and how do you do it? That is a great question. It’s really important when you get started with JavaScript. Personally, I prefer the name Pyramid of Doom for callback help. Basically, what callback help refers to is the phenomenon in JavaScript, I’m actually going to share my screen real quick and show you something. Callback help is the phenomenon where your JavaScript code, remember we talked about tasks and saying when something is done, I want to do the next thing, so what you end up with a lot of times in your JavaScript code is you end up saying, I want to, I’m just going to use this as an example, I want to wait some time, and then I want to do something in here, and after that, I want to wait some more time, and I want to do something else, and then again, and again, and again, and again, and what ends up happening is your code starts to look like this, starts to look like this pyramid shape on the left side, and that’s what we call the Pyramid of Doom or callback help. That is a problem that the JavaScript world solved a couple of years ago. What you’re going to want to look into is promises and async await, and basically what those allow you to do is flatten that code out, and you saw a little bit of that when we did the web service example, we’re going to have this get my joke from the API, and then instead of having to march further right if I want to do more, I can do these dot athens and just keep on moving downward instead of going further and further right, and that’s pretty much solves the problem, and async await is just a neater format for that. That’s more recent. Okay. Thanks, Aaron, and then the second question, if the JavaScript is going to allow data of the wrong type, how do I protect my RPG application? Good question, yeah. So there’s a difference between the JavaScript language and your application, right? So the thing is, if I pass in wrong data to a programming language that can’t, that doesn’t handle incorrect data types, when I try to do anything with that data, I’m going to end up with a problem, like, for example, you end up with decimal data errors a lot when we get these kinds of bad inputs in an RPG program, because JavaScript doesn’t care, the language itself doesn’t care what the type is, you’re able to handle wrong data types gracefully, and what that looks like is I can say things, let’s take a look at this API response, as an example, I have this response, I can say, if response, and basically what that’s saying is, if the response exists, I want you to do this code, and I can do little things like that, that allow me to effectively check and validate my data and make sure that before it ever gets to the RPG program, which can’t necessarily handle those inputs, I’ve already taken care of them, and JavaScript is able to handle those really easily, and you know it’s not going to run into any errors, because the language itself already doesn’t care what your data types are. And I think, actually, we’re going to be doing another webinar a little bit down the road in TypeScript, which is something that actually helps address some of these type issues that makes JavaScript more strongly typed, but we’ll announce that when we’re ready for that as well. Excellent. So, to all of you who post questions, we’ll make sure to answer them and send them out with the recording. Thank you so much for joining, and we look forward to having you attend the next webinar, and as usual, please reach out if there’s anything our team can do to help you get started with open source. Thanks, everybody. Have a great day. Bye. All right. Thank you, everyone.