Where is my error gone?
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Vandersteene, Bo
Debugging is a great tool, for frontend it is great on your own developer machine, but what if you start getting errors on the client his computer. You cannot access that computer. I will discuss some techniques how you can achieve this in a nice way. Javascript provides a good integration for logging and debugging. You can use Chrome Dev tools as a great tool to help you debug frontend applications. On your locale machine you can set breakpoints add error logs. But then the user has an error! You cannot access his console or debugger tools. It maybe always happen at a certain hour. No log is available for you personally. The user cannot explain the flow he has followed to this error, even explain you which browser version he has is hard! During this talks we do a deeper dive into the console and chrome dev tools, but also how can you log your errors and warnings from a remote computer.
 Thank you. Thank you very much for coming. My name is Kierke, I work at Oracle. Before that I worked at Sunmarcus Systems. In Oracle I'm increasingly working on the JavaScript strategy that Oracle has and I want to talk about something that many people may not be aware of, of what I would call a second generation development of JavaScript frameworks and libraries. And I want to position this around a number of organizations, surprising organizations that have open source stacks and how you can use them, what the benefits are, the advantages, disadvantages, etc. So in the enterprise, I'm thinking about large organizations like the Oracle, the Microsoft, banks, ING, in logistics and healthcare, insurance and banking, these kinds of domains, increasingly applications look like this, of course. They're increasingly my-about applications. And if they're not my-about applications, then they're very, very engaging graph chart, map, gauge-oriented applications on the desktop browser. And this is happening in the enterprise. This is all over the enterprise, of course. This isn't simply a hobby project or a small project. These are large enterprise front-ends. And increasingly we see these being written in JavaScript in these large organizations where maybe five or ten years ago, these large organizations looked very skeptically at JavaScript because JavaScript is constantly changing, which is a wonderful thing. It's constantly growing, constantly innovating. But if you're a large enterprise, that's not a very good thing because you want stability. You would rather have a boring, stable ecosystem than one that is constantly changing. So this is, of course, the problem that everyone faces, you know, all these different libraries, all these different frameworks, you know, making the right choice. What is the right choice? Something that's the right choice today in three years or three months or two weeks could be the wrong choice. How do you- I mean, this is the key problem of this ecosystem. And that's as true for large enterprises as for startups, as for people working on something at home. So this is, on the one hand, you know, this thing of this is wonderful, this is innovative, I can constantly learn, which is fantastic, but for the enterprise, you know, you want stability, you want reliability, you want maintainability, you want all of these kind of boring abilities, but the kinds of abilities that you need for large systems, large enterprise systems in logistics, healthcare, banking, finance, these kinds of things. So in the case of Oracle, for example, traditionally these kinds of technologies have been used. So ADF, APEX and forms, and if you're not in the Oracle ecosystem, you've never heard of these things. These are very preparatory to Oracle. And increasingly, it becomes difficult to find people with these skills. And when you go to the conferences of these particular types of technology stacks, you see a high dominance of gray-haired people, which- nothing wrong with gray-haired people, but it does kind of indicate that these are not the kinds of technology stacks where there is growth in. And also, when you look at the Java ecosystem in general, which is what an enterprise like Oracle, or Microsoft, or SAP, whatever would intuitively first go for because it's been around longer, because it's got these libraries, because it's got this ecosystem, because, you know, there's this stability and there's this specification-based approach. There are a number of technologies out there. But what you have seen in the last couple of years is really that JavaScript is being used in these large enterprises. And key reasons are that the browser is everywhere. You know, if there has been a war between platforms, the browser platform has won. I mean, the browser is on every single device. And the native language of the browser, at least right now anyway, is JavaScript. So it makes sense to ask yourself, well, maybe we should rather than using an abstraction, such as these Oracle technologies or some Java framework, use JavaScript directly. And a number of these organizations have been experimenting with this internally over a number of years and have been, over the past years since then, open-sourcing and putting those technology stacks out on GitHub to get more engagement from the developer community. So people coming out of colleges, universities know these libraries, know the idioms, know JavaScript. So in the case of Oracle, for example, switching to a JavaScript-oriented front-end technology with an Oracle results in its partners and customers doing the same thing, which as a consequence has that for the first time, a number of them are able to hire new young developers. Because there is just so much work out there for developers. If you go for a job interview as a developer, you are in fact interviewing that organization. They are not interviewing you. You are there to see whether they have the technology stack that matches your desires. So if you go for an interview somewhere and they say to you, welcome and work for us on our proprietary technology stack. And you say to them, well, I'm going to leave in three years. What can I do with what I've learned here? And then they'll say, well, it's proprietary. You have to stay in the ecosystem, basically, in our specific ecosystem. So now, by means of using these open source corporate technology stacks, organizations are able to attract new developers because of it being open source and because this enables a transfer of skills from one organization to the other within that open source domain. So what can we talk about a second generation? One was always talking and comparing Angular versus Backbone versus Ember versus this versus that. And maybe, especially if you're in the enterprise ecosystem, enterprise developer of some kind, you should instead be thinking about comparing these corporate solutions. So this is obviously the large software vendors. So Salesforce has its stack, Microsoft has its stack, Oracle has its stack. But did you know that there are other types of normalizations that you would not expect to have these kinds of stacks? So who here has heard of Kraken? So Kraken, very interesting. It turns out PayPal has its own open source division, which I learned about when I was at a conference and the keynote was done by a VP from PayPal. And the keynote at this developer conference, he wouldn't have been able to do if he had been talking about their proprietary stack. But because PayPal, like anyone else, is looking for new servers, they have an open source story and enabling their VP to go to developer conferences, stand on the stage, sponsor the conference and say, come and work for us, we have this wonderful open source technology stack. So the process by means of which these technology stacks develop is always the same. So first is this internal experimentation. For example, in PayPal, internal experimentation, let's look at Angular, let's look at React. At some point, the organization says enough experimentation, we need to standardize. And then an internal technology stack is developed within that organization. And at some point, someone says in that organization, well, we have something that is really coherent and usable by anybody. We want to attract more people. All the building blocks of our stack are open source anyway. Why don't we put it on GitHub? And then put it on GitHub. So this is one example, Kraken. So here you have, so if you're using these building blocks already, Kraken is a great way to, a great solution to use to combine them. So they use React, they use Node, all the usual suspects. If you look, so not just at PayPal, but here's some other examples. So it turns out Walmart, did you know Walmart is an IT organization? Of course Walmart is an IT organization. Every organization, every company nowadays is an IT organization. So Walmart has an open API. It has an open source story. Did you know the financial times is on GitHub? Same story. I have a technology stack that developed inside the organization. Another example is Uber. Uber is on GitHub. Their internal technology stack consisting of various open source components and libraries is published on GitHub. So it makes sense to take a look at these different, these different solutions. There are two warning signs, however. The first is a large enterprise putting something on GitHub could be a large enterprise saying we don't care about this technology stack. Could be. So be very careful whether this means this is the end of our interest in it. We are giving it away. Or does it mean we want to get the community involved with our direction? That's the first question to be really careful about. So there was a bank a number of years ago that went to a lot of conferences and talked about their technology stack and the VP was on stage and so on. And if you go to their GitHub repo now, you will see. The nice thing with GitHub is you can see the amount of development going on. There's nothing hidden. So you can see in that case, well, they've done nothing in the last five years. So then you wonder, okay, should we use this? The second question to ask is, is the business I'm doing comparable to the business that is done by the vendor putting out this technology stack on to GitHub? So if your business is not very similar to the financial times or if your business is not very similar to Walmart, maybe you should ask yourself, well, does this really fit my requirements? So if you're in the software business creating software products, creating web apps or whatever kind, then it makes sense to say, well, our business is maybe we are a partner of Microsoft. We are a partner of Salesforce. We are a partner of this particular vendor. Let's see how they do things and let's see if they have an open source solution that we can leverage. So that's basically the kind of direction that has clearly been going on over the last couple of years. In each of these cases, what these technology stacks need to respond to are a number of enterprise requirements. So the question is never in these cases, what is the latest coolest library? Never. The question is always, what is the stablest library? What is the stablest library out there? Because I mean, all these different frameworks are very similar. If you now react, you can learn Angular. If you knock out, you can learn view. These are all variations and dialects of each other. The first question is always, is it stable? Is it stable? Has it been around for a while? Is it documentation? Is there a community around it? Can I find things on Stack Overflow? Is it stable? Will it still be there in a number of years' time? That's an important question in the enterprise. It's not what is cool, what is new. And does it have built-in solutions for doing responsive design? When other templates to set things up, other ways to scaffold things? Are there solutions around accessibility and around internationalization? These are, there are specifications around this that large enterprises need to comply with. So if they choose a technology stack, it needs to have some solutions around this. Are there data visualization capabilities? Do I need to, again, look for graphs and charts somewhere? Or can I simply use them out of the box from this particular stack? Are there solutions around security? The biggest question that an enterprise has. So how are security issues handled? Can I tweak? Can I optimize performance? Another big question you have in the enterprise. What are the standards it conforms to? Are there ways to empower more business users? So is it just a code-oriented solution and also documentation and support? Not obvious at all, right, in the JavaScript ecosystem. There's a cool new library out there and you start using it and you do Hello World and it's fantastic and then the very next step is a problem. And then you write to the random person in the basement who created this wonderful library and they say, yeah, thanks, but I'm working on something different now. So this is not, that's not a nice thing for enterprise developers. You want something stable and reliable and consistent and so on. So in the case of Oracle, as one example of this particular sort pattern, we ended up choosing jQuery, very boring, we ended up choosing knockout, not the latest thing, Cordova for packaging everything together, RequireJS for modularity. What is nice about RequireJS and about knockout is that there are very specifically and narrowly focused on one particular thing. So this is another thing that is worth thinking about. Are you choosing a framework that locks you in, especially a vendor-driven framework, or are you choosing a modular, loosely structured, flexible architecture? Because things are changing all the time. So if you have this very strongly vendor-focused framework, what you'll be able to keep up with all the changes, are you able to experiment, are you able to throw in new libraries and adapt and adapt to change? So in the case of the approach technique at Oracle is let's just choose a few libraries out there, combine them together, make it flexible, make it extensible, so if you know Require, you know, you get this Require configuration file, you just add new libraries into that configuration file and you're done. So really if you know Require, if you know knockout, if you know jQuery, then you know everything that you need to know in order to be able to use Oracle's enterprise technology stack out of the box. Then recently added was Wepec and TypeScript. So TypeScript-based development is also possible. So in the case of how Oracle looks at things in this JavaScript space, it's purely a front-end solution. So back-end is completely open, no connection to any particular DB or whatever. You would have REST endpoints, you would have WebSockets and Oracle's technology stack, which is called JET, stands for JavaScript extension toolkit, is based on top of that, the back-end of REST endpoints and WebSockets. And it's just a model-view-view model of knockout jQuery, Require, routing built-in for bookmarks, so Require for modularity and built-in support for web components. So to show you what this looks like, the command line in the folder and I say, oh, JET, so there's a small command line tool that you can store via NPM, create an app of some kind, and there are different templates for scaffolding, and then you kick off the process. So this is a little command line tool that you can store via NPM, it's all free, and it just sets up the application for you. It takes about two minutes to download the library, so it actually downloads jQuery. Beneath this are things like Bower and Grunt, you don't need to learn Bower and Grunt, it all hides it within that particular tool. And very quickly it generates the application. Here we are, and then we go into that application and we say, oh, JET, serve. And it serves up the application into the browser and you have a pure front-end, and you can then connect to any back-end or whatever you need. So within about two minutes of starting this application, we should have it served up and shown in the browser, and then this is exactly what people all over Oracle are doing, so all of Oracle's newest front-ends are created in this way. So here we have the starting point. If we change the resolution, you can see it's responsive, so we get the hamburger icon shown with the typical menu structure for MoMAO. So out of the box, responsive design, symbol page application architecture, because all over Oracle, there are developers switching from Java front-ends and all kinds of other front-ends to JavaScript, and they're doing it in this way. They don't need to think about responsive design in their initial setup. They don't need to think about the project structure. They don't need to think about symbol page application architecture. It's all simply built in to the template that sets us up. So now the next step is we want to have some content. So open any editor you like, and so I work a lot on NetBeans, which is in Apache, and here is the source structure. So view models and views. So here are the HTML templates, and here are the JavaScript files, and there's a one-to-one match with the tabs you see in the browser, dashboard incidents customers about. So the dashboard tab consists of a defined block in a file called dashboard.js and an HTML file in dashboard HTML. So here we have the two files together that create a module. This is simply a required JS module that is loaded into the application by means of the single-page application architecture as a fragment into the index file. So now we need to have some content. So there's a cookbook. So all of our Oracle people are switching to JavaScript, and if you're a JavaScript developer, you like nothing more than if you need a daytime picker, you go to Google.com, look for JavaScript daytime picker, find some random snippet, copy and paste it into your application. So that's very dangerous in the enterprise, of course. You want to control where everything comes from. So this is a controlled environment. This is an open page online you can go to where all the components are found. So here's one of them. So here is a bar chart, and there's many different kinds of charts, all enterprise oriented. You can see here that there's HTML and there's JavaScript. And I can tweak this graph live. So this is actually running live in the browser. You can see there's a toolbar along the bottom here. And I'm now going to just remove those tags from the HTML and I say apply. So I'm updating the browser live so I can tweak all the components live until I'm happy with them. And then I copy the chart, copy from here and paste that into my HTML file. So here is the chart. So you can see there is a custom element and you can see key value, key value. And these values are JavaScript properties. So here is the JavaScript. So we simply copy and paste. And the final step is we need to add to the define block a reference to the chart. So this is simply using require. So here we have a reference to a J chart. And paste it. So now I've copied from the cookbook and I look at the application, the browser, here's the chart. All of our people are setting up their applications like this. Then copying and pasting as JavaScript developers love doing, but directly from a controlled space so that the daytime picker that one person copies is the same daytime picker as somebody else copies. And this is how we are moving ahead in the JavaScript front end ecosystem. Now of course there's also support for web components. So this is increasingly important. I'm going to stop this process and open a little window here and get back into that folder, desktop, into an app. So here's my app structure. Now I'm going to say, OJets create component, FOSDEM chart. Very quickly what is generated is the starting point of a component that meets the web component specification requirements. So this we can zip up and share. So there is already internally within Oracle an exchange full of components like this. So inside of one of these folders is found most importantly the definition of a new custom element. So here a custom element called FOSDEM chart is created. And here's the HTML file, the JavaScript file, the CSS file. So this enables us to create web components and potentially for the ecosystem around Oracle to base its business around creating generic components for Google, Mac integration or whatever integration they would like. So what I've talked about is basically that there's a second generation of frameworks and libraries that are on GitHub. Take a look at them, compare them, consider which of the vendors doing this open source work are in your domain area, what your organization is partner of, see what they're doing and leverage of them. There's no need to recreate the wheel anymore. You can lift along with the developments of these large vendors because once they have gone in a particular direction it will take a long time before they change to something different. So these are all stable solutions that you should consider making use of especially because they are free and open source. Thank you. So we have time for questions. Who has the first question? If you do have to go away then please don't make noise and be nice. Thank you very much. Question you asked, you talked about things being open source but there's also the evil twin because I would be extra worried with big organizations about patent claims coming back later to haunt me. So do you have any ideas on how to combat that fear or take it away to some degree? Read the FAQ of that particular project very carefully and make sure that the licensing is okay. So in the case of the Oracle Jet Solution it's MIT license which is about as liberal as you can go. But you need to just make sure that the licensing is really appropriate to your needs. And in the case of an organization like Oracle, Oracle really wants people to use this. So there's no way that afterwards anyone's going to say hey why are you using this. So you need to really look at why is a particular technology stack out on GitHub. Is it because it's being dumped by an organization and if you start using it, you know, be concerned? Or is it because they want to attract more developers in their ecosystem, in which case more than likely no one is going to come after you because they want you to use it? Thank you. Okay, well thank you very much for your attention. Oh, oh, oh, somebody is questioning right here. Hey, so an open source project, like my experience with open source projects is you get a bug fix like someone is using it. They see that something's wrong with it. They make a bug fix and even if it's not perfect, an open source project with not many like full time people on it will accept that bug fix and it would be good enough and stuff like that. But with a bigger organization, it's sometimes harder to get stuff in upstream and then you have to basically patch them and do crazy stuff around that. So how open is Oracle? I mean, and other big companies. I think what you would see in all these organizations and Oracle is the same like in the first open source release, it was only available for the partners of Oracle. It was available for everybody but only partners could use it in production. That was the first phase. The next phase which is right now is everything is on GitHub. You can use it whatever but you can't do pull requests on it yet. It's always going to be in stages and the next stage once it's all stabilized and the next stage would be, hey, let's accept pull requests. But you should really ask these questions when you're looking at these kinds of different offerings because exactly this. It's also, I think, a question of in the case of Oracle, I think the community around it is growing because all of Oracle's partners and customers have wanted to use JavaScript for years but there's never been an official way for Oracle partners and customers to do that. So some did Angular, some did React, some did this, some did that. So now Oracle is standardized. So now all Oracle's downstream partners and customers, if they do JavaScript, they will do it like this. So this will create a community. So right now one of the employees of one of the partners is writing a book on Oracle Jet in anticipation of this becoming more and more popular. So then you build up a community. So then you could envision the community being involved in reviewing the bugs, for example. So it's always going to be some kind of conflict in a way between the commercial interests of the enterprise and its open source vision. But you have to just see what's going on per project. Thank you very much. Thank you.
 Thank you. Thank you very much for coming. My name is Kierke, I work at Oracle. Before  that I worked at Sunmarcus Systems. In Oracle I'm increasingly working on the JavaScript  strategy that Oracle has and I want to talk about something that many people may not be  aware of, of what I would call a second generation development of JavaScript frameworks and libraries.  And I want to position this around a number of organizations, surprising organizations  that have open source stacks and how you can use them, what the benefits are, the advantages,  disadvantages, etc. So in the enterprise, I'm thinking about large organizations like  the Oracle, the Microsoft, banks, ING, in logistics and healthcare, insurance and banking,  these kinds of domains, increasingly applications look like this, of course. They're increasingly  my-about applications. And if they're not my-about applications, then they're very,  very engaging graph chart, map, gauge-oriented applications on the desktop browser. And this  is happening in the enterprise. This is all over the enterprise, of course. This isn't  simply a hobby project or a small project. These are large enterprise front-ends. And  increasingly we see these being written in JavaScript in these large organizations where  maybe five or ten years ago, these large organizations looked very skeptically at JavaScript because  JavaScript is constantly changing, which is a wonderful thing. It's constantly growing,  constantly innovating. But if you're a large enterprise, that's not a very good thing because  you want stability. You would rather have a boring, stable ecosystem than one that is  constantly changing. So this is, of course, the problem that everyone faces, you know,  all these different libraries, all these different frameworks, you know, making the right choice.  What is the right choice? Something that's the right choice today in three years or three  months or two weeks could be the wrong choice. How do you- I mean, this is the key problem  of this ecosystem. And that's as true for large enterprises as for startups, as for  people working on something at home. So this is, on the one hand, you know, this thing  of this is wonderful, this is innovative, I can constantly learn, which is fantastic,  but for the enterprise, you know, you want stability, you want reliability, you want  maintainability, you want all of these kind of boring abilities, but the kinds of abilities  that you need for large systems, large enterprise systems in logistics, healthcare, banking,  finance, these kinds of things. So in the case of Oracle, for example, traditionally  these kinds of technologies have been used. So ADF, APEX and forms, and if you're not  in the Oracle ecosystem, you've never heard of these things. These are very preparatory  to Oracle. And increasingly, it becomes difficult to find people with these skills. And when  you go to the conferences of these particular types of technology stacks, you see a high  dominance of gray-haired people, which- nothing wrong with gray-haired people, but it does  kind of indicate that these are not the kinds of technology stacks where there is growth  in. And also, when you look at the Java ecosystem in general, which is what an enterprise like  Oracle, or Microsoft, or SAP, whatever would intuitively first go for because it's been  around longer, because it's got these libraries, because it's got this ecosystem, because,  you know, there's this stability and there's this specification-based approach. There  are a number of technologies out there. But what you have seen in the last couple of years  is really that JavaScript is being used in these large enterprises. And key reasons are  that the browser is everywhere. You know, if there has been a war between platforms,  the browser platform has won. I mean, the browser is on every single device. And the  native language of the browser, at least right now anyway, is JavaScript. So it makes sense  to ask yourself, well, maybe we should rather than using an abstraction, such as these Oracle  technologies or some Java framework, use JavaScript directly. And a number of these  organizations have been experimenting with this internally over a number of years and  have been, over the past years since then, open-sourcing and putting those technology  stacks out on GitHub to get more engagement from the developer community. So people coming  out of colleges, universities know these libraries, know the idioms, know JavaScript. So in the  case of Oracle, for example, switching to a JavaScript-oriented front-end technology  with an Oracle results in its partners and customers doing the same thing, which as a  consequence has that for the first time, a number of them are able to hire new young  developers. Because there is just so much work out there for developers. If you go for  a job interview as a developer, you are in fact interviewing that organization. They  are not interviewing you. You are there to see whether they have the technology stack  that matches your desires. So if you go for an interview somewhere and they say to you,  welcome and work for us on our proprietary technology stack. And you say to them, well,  I'm going to leave in three years. What can I do with what I've learned here? And then  they'll say, well, it's proprietary. You have to stay in the ecosystem, basically, in our  specific ecosystem. So now, by means of using these open source corporate technology stacks,  organizations are able to attract new developers because of it being open source and because  this enables a transfer of skills from one organization to the other within that open  source domain. So what can we talk about a second generation? One was always talking  and comparing Angular versus Backbone versus Ember versus this versus that. And maybe,  especially if you're in the enterprise ecosystem, enterprise developer of some kind, you should  instead be thinking about comparing these corporate solutions. So this is obviously  the large software vendors. So Salesforce has its stack, Microsoft has its stack, Oracle  has its stack. But did you know that there are other types of normalizations that you  would not expect to have these kinds of stacks? So who here has heard of Kraken? So Kraken,  very interesting. It turns out PayPal has its own open source division, which I learned  about when I was at a conference and the keynote was done by a VP from PayPal. And the keynote  at this developer conference, he wouldn't have been able to do if he had been talking  about their proprietary stack. But because PayPal, like anyone else, is looking for new  servers, they have an open source story and enabling their VP to go to developer conferences,  stand on the stage, sponsor the conference and say, come and work for us, we have this  wonderful open source technology stack. So the process by means of which these technology  stacks develop is always the same. So first is this internal experimentation. For example,  in PayPal, internal experimentation, let's look at Angular, let's look at React. At some  point, the organization says enough experimentation, we need to standardize. And then an internal  technology stack is developed within that organization. And at some point, someone says  in that organization, well, we have something that is really coherent and usable by anybody.  We want to attract more people. All the building blocks of our stack are open source anyway.  Why don't we put it on GitHub? And then put it on GitHub. So this is one example, Kraken.  So here you have, so if you're using these building blocks already, Kraken is a great  way to, a great solution to use to combine them. So they use React, they use Node, all  the usual suspects. If you look, so not just at PayPal, but here's some other examples.  So it turns out Walmart, did you know Walmart is an IT organization? Of course Walmart is  an IT organization. Every organization, every company nowadays is an IT organization. So  Walmart has an open API. It has an open source story. Did you know the financial times is  on GitHub? Same story. I have a technology stack that developed inside the organization.  Another example is Uber. Uber is on GitHub. Their internal technology stack consisting  of various open source components and libraries is published on GitHub. So it makes sense  to take a look at these different, these different solutions. There are two warning signs, however.  The first is a large enterprise putting something on GitHub could be a large enterprise saying  we don't care about this technology stack. Could be. So be very careful whether this  means this is the end of our interest in it. We are giving it away. Or does it mean we  want to get the community involved with our direction? That's the first question to be  really careful about. So there was a bank a number of years ago that went to a lot of  conferences and talked about their technology stack and the VP was on stage and so on. And  if you go to their GitHub repo now, you will see. The nice thing with GitHub is you can  see the amount of development going on. There's nothing hidden. So you can see in that case,  well, they've done nothing in the last five years. So then you wonder, okay, should we  use this? The second question to ask is, is the business I'm doing comparable to the business  that is done by the vendor putting out this technology stack on to GitHub? So if your  business is not very similar to the financial times or if your business is not very similar  to Walmart, maybe you should ask yourself, well, does this really fit my requirements?  So if you're in the software business creating software products, creating web apps or whatever  kind, then it makes sense to say, well, our business is maybe we are a partner of Microsoft.  We are a partner of Salesforce. We are a partner of this particular vendor. Let's see how they  do things and let's see if they have an open source solution that we can leverage. So that's  basically the kind of direction that has clearly been going on over the last couple  of years. In each of these cases, what these technology stacks need to respond to are a  number of enterprise requirements. So the question is never in these cases, what is  the latest coolest library? Never. The question is always, what is the stablest library? What  is the stablest library out there? Because I mean, all these different frameworks are  very similar. If you now react, you can learn Angular. If you knock out, you can learn view.  These are all variations and dialects of each other. The first question is always, is it  stable? Is it stable? Has it been around for a while? Is it documentation? Is there a  community around it? Can I find things on Stack Overflow? Is it stable? Will it still  be there in a number of years' time? That's an important question in the enterprise. It's  not what is cool, what is new. And does it have built-in solutions for doing responsive  design? When other templates to set things up, other ways to scaffold things? Are there  solutions around accessibility and around internationalization? These are, there are  specifications around this that large enterprises need to comply with. So if they choose a technology  stack, it needs to have some solutions around this. Are there data visualization capabilities?  Do I need to, again, look for graphs and charts somewhere? Or can I simply use them out of  the box from this particular stack? Are there solutions around security? The biggest question  that an enterprise has. So how are security issues handled? Can I tweak? Can I optimize  performance? Another big question you have in the enterprise. What are the standards  it conforms to? Are there ways to empower more business users? So is it just a code-oriented  solution and also documentation and support? Not obvious at all, right, in the JavaScript  ecosystem. There's a cool new library out there and you start using it and you do Hello  World and it's fantastic and then the very next step is a problem. And then you write  to the random person in the basement who created this wonderful library and they say, yeah,  thanks, but I'm working on something different now. So this is not, that's not a nice thing  for enterprise developers. You want something stable and reliable and consistent and so  on. So in the case of Oracle, as one example of this particular sort pattern, we ended  up choosing jQuery, very boring, we ended up choosing knockout, not the latest thing,  Cordova for packaging everything together, RequireJS for modularity. What is nice about  RequireJS and about knockout is that there are very specifically and narrowly focused  on one particular thing. So this is another thing that is worth thinking about. Are you  choosing a framework that locks you in, especially a vendor-driven framework, or are you choosing  a modular, loosely structured, flexible architecture? Because things are changing all the time.  So if you have this very strongly vendor-focused framework, what you'll be able to keep up with  all the changes, are you able to experiment, are you able to throw in new libraries and  adapt and adapt to change? So in the case of the approach technique at Oracle is let's  just choose a few libraries out there, combine them together, make it flexible, make it extensible,  so if you know Require, you know, you get this Require configuration file, you just  add new libraries into that configuration file and you're done. So really if you know Require,  if you know knockout, if you know jQuery, then you know everything that you need to  know in order to be able to use Oracle's enterprise technology stack out of the box.  Then recently added was Wepec and TypeScript. So TypeScript-based development is also possible.  So in the case of how Oracle looks at things in this JavaScript space, it's purely a front-end  solution. So back-end is completely open, no connection to any particular DB or whatever.  You would have REST endpoints, you would have WebSockets and Oracle's technology stack,  which is called JET, stands for JavaScript extension toolkit, is based on top of that,  the back-end of REST endpoints and WebSockets. And it's just a model-view-view model of knockout  jQuery, Require, routing built-in for bookmarks, so Require for modularity and built-in support  for web components. So to show you what this looks like, the command line in the folder  and I say, oh, JET, so there's a small command line tool that you can store via NPM, create  an app of some kind, and there are different templates for scaffolding, and then you kick  off the process. So this is a little command line tool that you can store via NPM, it's  all free, and it just sets up the application for you. It takes about two minutes to download  the library, so it actually downloads jQuery. Beneath this are things like Bower and Grunt,  you don't need to learn Bower and Grunt, it all hides it within that particular tool.  And very quickly it generates the application. Here we are, and then we go into that application  and we say, oh, JET, serve. And it serves up the application into the browser and you  have a pure front-end, and you can then connect to any back-end or whatever you need. So within  about two minutes of starting this application, we should have it served up and shown in the  browser, and then this is exactly what people all over Oracle are doing, so all of Oracle's  newest front-ends are created in this way. So here we have the starting point. If we  change the resolution, you can see it's responsive, so we get the hamburger icon shown with the  typical menu structure for MoMAO. So out of the box, responsive design, symbol page application  architecture, because all over Oracle, there are developers switching from Java front-ends  and all kinds of other front-ends to JavaScript, and they're doing it in this way. They don't  need to think about responsive design in their initial setup. They don't need to think about  the project structure. They don't need to think about symbol page application architecture.  It's all simply built in to the template that sets us up. So now the next step is we want  to have some content. So open any editor you like, and so I work a lot on NetBeans, which  is in Apache, and here is the source structure. So view models and views. So here are the  HTML templates, and here are the JavaScript files, and there's a one-to-one match with  the tabs you see in the browser, dashboard incidents customers about. So the dashboard  tab consists of a defined block in a file called dashboard.js and an HTML file in dashboard  HTML. So here we have the two files together that create a module. This is simply a required  JS module that is loaded into the application by means of the single-page application architecture  as a fragment into the index file. So now we need to have some content. So there's a  cookbook. So all of our Oracle people are switching to JavaScript, and if you're a JavaScript  developer, you like nothing more than if you need a daytime picker, you go to Google.com,  look for JavaScript daytime picker, find some random snippet, copy and paste it into your  application. So that's very dangerous in the enterprise, of course. You want to control  where everything comes from. So this is a controlled environment. This is an open page  online you can go to where all the components are found. So here's one of them. So here  is a bar chart, and there's many different kinds of charts, all enterprise oriented.  You can see here that there's HTML and there's JavaScript. And I can tweak this graph live.  So this is actually running live in the browser. You can see there's a toolbar along the bottom  here. And I'm now going to just remove those tags from the HTML and I say apply. So I'm  updating the browser live so I can tweak all the components live until I'm happy with  them. And then I copy the chart, copy from here and paste that into my HTML file. So  here is the chart. So you can see there is a custom element and you can see key value,  key value. And these values are JavaScript properties. So here is the JavaScript. So  we simply copy and paste. And the final step is we need to add to the define block a reference  to the chart. So this is simply using require. So here we have a reference to a J chart.  And paste it. So now I've copied from the cookbook and I look at the application, the  browser, here's the chart. All of our people are setting up their applications like this.  Then copying and pasting as JavaScript developers love doing, but directly from a controlled  space so that the daytime picker that one person copies is the same daytime picker as  somebody else copies. And this is how we are moving ahead in the JavaScript front end  ecosystem. Now of course there's also support for web components. So this is increasingly  important. I'm going to stop this process and open a little window here and get back  into that folder, desktop, into an app. So here's my app structure. Now I'm going to  say, OJets create component, FOSDEM chart. Very quickly what is generated is the starting  point of a component that meets the web component specification requirements. So this we can  zip up and share. So there is already internally within Oracle an exchange full of components  like this. So inside of one of these folders is found most importantly the definition of  a new custom element. So here a custom element called FOSDEM chart is created. And here's  the HTML file, the JavaScript file, the CSS file. So this enables us to create web components  and potentially for the ecosystem around Oracle to base its business around creating  generic components for Google, Mac integration or whatever integration they would like.  So what I've talked about is basically that there's a second generation of frameworks  and libraries that are on GitHub. Take a look at them, compare them, consider which of the  vendors doing this open source work are in your domain area, what your organization is  partner of, see what they're doing and leverage of them. There's no need to recreate the wheel  anymore. You can lift along with the developments of these large vendors because once they have  gone in a particular direction it will take a long time before they change to something  different. So these are all stable solutions that you should consider making use of especially  because they are free and open source. Thank you.  So we have time for questions. Who has the first question? If you do have to go away  then please don't make noise and be nice.  Thank you very much. Question you asked, you talked about things being open source but  there's also the evil twin because I would be extra worried with big organizations about  patent claims coming back later to haunt me. So do you have any ideas on how to combat  that fear or take it away to some degree?  Read the FAQ of that particular project very carefully and make sure that the licensing  is okay. So in the case of the Oracle Jet Solution it's MIT license which is about as liberal  as you can go. But you need to just make sure that the licensing is really appropriate to  your needs. And in the case of an organization like Oracle, Oracle really wants people to  use this. So there's no way that afterwards anyone's going to say hey why are you using  this. So you need to really look at why is a particular technology stack out on GitHub.  Is it because it's being dumped by an organization and if you start using it, you know, be concerned?  Or is it because they want to attract more developers in their ecosystem, in which case  more than likely no one is going to come after you because they want you to use it?  Thank you.  Okay, well thank you very much for your attention. Oh, oh, oh, somebody is questioning right  here.  Hey, so an open source project, like my experience with open source projects is you get a bug  fix like someone is using it. They see that something's wrong with it. They make a bug  fix and even if it's not perfect, an open source project with not many like full time  people on it will accept that bug fix and it would be good enough and stuff like that.  But with a bigger organization, it's sometimes harder to get stuff in upstream and then you  have to basically patch them and do crazy stuff around that. So how open is Oracle?  I mean, and other big companies.  I think what you would see in all these organizations and Oracle is the same like in the first  open source release, it was only available for the partners of Oracle. It was available  for everybody but only partners could use it in production. That was the first phase.  The next phase which is right now is everything is on GitHub. You can use it whatever but  you can't do pull requests on it yet. It's always going to be in stages and the next  stage once it's all stabilized and the next stage would be, hey, let's accept pull requests.  But you should really ask these questions when you're looking at these kinds of different  offerings because exactly this. It's also, I think, a question of in the case of Oracle,  I think the community around it is growing because all of Oracle's partners and customers  have wanted to use JavaScript for years but there's never been an official way for Oracle  partners and customers to do that. So some did Angular, some did React, some did this,  some did that. So now Oracle is standardized. So now all Oracle's downstream partners and  customers, if they do JavaScript, they will do it like this. So this will create a community.  So right now one of the employees of one of the partners is writing a book on Oracle  Jet in anticipation of this becoming more and more popular. So then you build up a community.  So then you could envision the community being involved in reviewing the bugs, for example.  So it's always going to be some kind of conflict in a way between the commercial interests  of the enterprise and its open source vision. But you have to just see what's going on  per project. Thank you very much.  Thank you.
Where_is_my_error_gone__Qug9xDqcq2I_0_47.png Where_is_my_error_gone__Qug9xDqcq2I_48_179.png Where_is_my_error_gone__Qug9xDqcq2I_180_995.png Where_is_my_error_gone__Qug9xDqcq2I_996_9383.png Where_is_my_error_gone__Qug9xDqcq2I_9384_9491.png Where_is_my_error_gone__Qug9xDqcq2I_9492_11495.png Where_is_my_error_gone__Qug9xDqcq2I_11496_11579.png Where_is_my_error_gone__Qug9xDqcq2I_11580_11747.png Where_is_my_error_gone__Qug9xDqcq2I_11748_11831.png Where_is_my_error_gone__Qug9xDqcq2I_11832_11963.png Where_is_my_error_gone__Qug9xDqcq2I_11964_12407.png Where_is_my_error_gone__Qug9xDqcq2I_12408_14591.png Where_is_my_error_gone__Qug9xDqcq2I_14592_15287.png Where_is_my_error_gone__Qug9xDqcq2I_15288_15371.png Where_is_my_error_gone__Qug9xDqcq2I_15372_16043.png Where_is_my_error_gone__Qug9xDqcq2I_16044_22019.png Where_is_my_error_gone__Qug9xDqcq2I_22020_24131.png Where_is_my_error_gone__Qug9xDqcq2I_24132_24191.png Where_is_my_error_gone__Qug9xDqcq2I_24192_25211.png Where_is_my_error_gone__Qug9xDqcq2I_25212_25331.png Where_is_my_error_gone__Qug9xDqcq2I_25332_26063.png Where_is_my_error_gone__Qug9xDqcq2I_26064_26603.png Where_is_my_error_gone__Qug9xDqcq2I_26604_26663.png Where_is_my_error_gone__Qug9xDqcq2I_26664_26903.png Where_is_my_error_gone__Qug9xDqcq2I_26904_27563.png Where_is_my_error_gone__Qug9xDqcq2I_27564_27911.png Where_is_my_error_gone__Qug9xDqcq2I_27912_28031.png Where_is_my_error_gone__Qug9xDqcq2I_28032_28211.png Where_is_my_error_gone__Qug9xDqcq2I_28212_28367.png Where_is_my_error_gone__Qug9xDqcq2I_28368_28463.png Where_is_my_error_gone__Qug9xDqcq2I_28464_28523.png Where_is_my_error_gone__Qug9xDqcq2I_28524_31007.png Where_is_my_error_gone__Qug9xDqcq2I_31008_38591.png Where_is_my_error_gone__Qug9xDqcq2I_38592_38715.png