So I'm here to talk about asynchronous JavaScript patterns, this is going to be the most boring presentation because I'm going to just keep reading from the slides. I'm joking, why would I do that? Anyway, so I'm talking about this because I have been a client-side developer for almost all of my career. Unlike the Ranjay, I have not been a polyglot, I have been a one-track pony. So that's the only thing I can do, I can only write JavaScript, that's all I can do. But being a client-side developer and I've lived through all of the cycles that he was talking about, so I was sort of feeling all the nostalgic and stuff. But romantic times with Dojo and Prototype and stuff like that. Finally the hatred that I have for Jack very, I hate Jack very, but that's just me. And then Node comes along and then Node changes. Suddenly there's this mind-share that Node gets, which clients at JavaScript did not get. There was just not enough smart people, people like me doing clients at JavaScript. Not enough smart people doing clients at JavaScript. So there had to be something big that happened in JavaScript and Node was that, where then people could then jump in with ideas about how to make things better. And that has sort of started influencing client-side development as well. So what I'm talking about is about how to deal with async patterns and how sort of Node has taught the client-side how to do async patterns well. And that's roughly the talk, the summary of the talk. About me, already Kiran's made the pitch, I didn't have to do this. I've been doing JavaScript for about nine plus years. Sadly that's almost like 80% of the lifetime which I was doing it itself, that's pretty sad. And I've been doing that for so long. I'm obsessed with clean code. I take a lot of pride in my code being clean. And I like robots. I've not been able to add lasers to them yet, but I've been able to work with robots, it's good fun. We should check up later if you want about how we can build robots with JavaScript. I'll be in fact showing this off at JSFOO in Bangalore, so maybe if anyone is coming along there then we could have a look at that. Have you put a robot on a shark yet? No, not a robot on a shark yet. But I'm thinking of putting a cat that could fly. So I want to sort of backtrack and I know that I've just done this as well. But I want to just step back and go over a couple of points really quick before I jump into Async. And the first thing I want to talk about is JavaScript itself, JavaScript the language. So JavaScript is a very small language. And by small I mean the amount of keywords, the amount of constructs, the amount of syntax you have to deal with, stuff like that. It's a rather small language. There are languages that are much, much faster than JavaScript in terms of its keywords and constructs, but JavaScript is not that very small. Contrary to popular belief, JavaScript is actually a sequential programming language. A lot of people think it's an asynchronous programming language. There's nothing about JavaScript that makes it asynchronous. This is a controversial statement because everybody else seems to think that JavaScript is asynchronous. It is not. It's a synchronous programming language. It goes, you know, statement after statement after statement. That's how it works. And doing that, you know, there's nothing else that can do that. That's how JavaScript works, right? So it's a single thread. It's single thread. And there is no multi-pressing at all. There is no multi-pressing at all. It's a small language. Let's just say that's the beauty of it, right? The only time when, of course, it does not go sequentially is when something breaks the control flow and that would be something like, you know, an if statement or a for loop or, you know, a function call or something. It was just as you would expect in any typical language. So that is, that is how JavaScript is. It's not very hard to understand. In fact, it's comparable to anything else like, you know, Python or what have you in terms of the flow of code, right? It just flows from top to bottom unless there is somewhere to branch out that. So, you know, yeah, so control flow could break the sequence. This is a very popular photograph. I don't know if you guys have seen this JavaScript, the definitive guide, which is the fact book at the bottom. JavaScript, the good parts. I will admit JavaScript is not very, not very, you know, cool. But then, fortunately, there is also a Brenda Mike, who is our Messiah, the creator of JavaScript. He also fortunately has a very good sense of humor. So at the top that he was giving recently, he put up a slide as a joke to counter this and to counter Douglas Crawford. He put up a slide saying JavaScript the best parts, right? And so this is what he listed out. And he said that, you know, this is what JavaScript is, basically three bullet points. That's all that is required to make JavaScript work. And that's the only thing exciting about JavaScript, right? And so functions as first class objects, closures and prototypical inheritance. I will not be diving into closures and prototypical inheritance. Already, you know, he's gone over prototypical inheritance in some amount already. But I will be looking at functions in some amount of detail. Though, you know, I don't think half an hour I'll be able to justice to it. I can count at least seven different ways of using functions in JavaScript. Functions are very, very powerful in JavaScript. But before we come to that, remember I told you JavaScript is sequential. It is the host environment that JavaScript is running in. I want to distinguish the two, right? There is the language and then there is the environment that the language runs in. The environment that the language runs in is usually interesting with JavaScript if it has an event loop. Though it is not necessary for the host environment to have an event loop, right? So most interesting host environments, for example, the browser and Node.js which are the two most popular environments for JavaScript actually have an event loop in them. That's what makes JavaScript interesting in those places. Though, of course, it's not necessary. You know, JAXER used to be a programming language that was a programming environment that had JavaScript as its host. I've actually programmed in this on, you know, printing something that never really took off. But that did not have an event loop working in it. You can also script Photoshop if you didn't know.   He scripted the... I should not be using these words here. But he scripted that thing very, very well. To the extent that he can save something in his editor and then that will update something in Photoshop, cut that up into images which then will be exported onto his file system and then cause a browser reload to happen just by hitting save in his editor. So he's just scripted this thing out so beautifully. It's amazing. I hope that we could... He's coming down to Bangalore again because he pitched a reception for me, I'm going to pitch Bangalore for him. So he's coming down to Bangalore so you should probably catch him if you can. Vishal, Vishal. Alright, so... Alright, let me talk about one more thing. Now, a lot of people mistakenly think that set time... Everyone's familiar with set time what I'm sure. A lot of people think set time out is something that JavaScript gives them. It is not. Set time out is something that the host environment gives them. It's actually the browser that is providing set time out. JavaScript does not because set time out has to work with the event loop whereas JavaScript is not aware of the event loop. There is no such concept of an event loop in JavaScript. It's the browser that's providing it. So set time out is an example that is so intertwined with JavaScript because we're so used to it in the browser that we think it's part of JavaScript. So set time out has something that has to do with the event loop. Now, you know, I'm sure you could probably figure out what this code does. It prints hello, it waits for five seconds and then it prints word. Right, and we could probably just give it a spin right here. If this works. Right, so it says hello, waits for a little time. And then word. Right, so... Now, this is expected. What I want to impress upon you though is the fact that by calling set time out what I have done is I have essentially passed this block of code, that function that says word. I have pasted this block of code and I have told it to put this code on the event loop to be executed five seconds later to roughly, you know, this is not absolutely accurate but roughly speaking this is what I'm doing. Right, so I'm saying take this block of code which is power number one of JavaScript. You are passing it blocks of code as opposed to passing it strings or numbers or whatever. You're passing it blocks of code and you're telling it take this and put this on the event loop to be run five seconds later. Now, it does not actually go out to the event loop right now because your code is executing sequentially so your processor is busy. It's going sequentially. It does not actually go out to the event loop. It's after it alerts hello, does it then go to the event loop, it builds it over there, waits for five seconds and then comes back, right? With me so far, lost, okay? Why after alerts hello, does it go to the event loop? Sorry? If it goes sequentially, the set time out should happen first and then... Right, but it has to go out to the event loop. So it depends on environments and in most environments what happens is that since it has to go out to the event loop that process is also scheduled on the event loop itself. So in this case it has to wait for five seconds so that process is actually scheduled on the event loop for that to happen. So an easy way to test this is for example, let's say you want to make an AJAX call and AJAX call is something that has to go to an event loop, right?  Just keep it in a loop. You will see the AJAX call does not even reach your server because it does not actually schedule on the event loop yet. It's when your event loop is free, when your JavaScript runtime is not doing anything is when it will actually get time to play with the event loop. So that's how the browser is sort of marrying the runtime and the language, right? You see essentially the yield is co-operative. Yes, yes, yes, roughly, yes. Or probably you are saying that you are not saying that execute this after five seconds. You are saying that try to execute this after five seconds if you are free. Yes, yes, absolutely. So there is no guarantee obviously that after five seconds it will be free. It could just be that your event loopers or your JavaScript runtime has caught the process and is not letting the process yield. So essentially it does not interrupt in the middle of anything. Right, right, right. Okay, so there are couple of people here who seem to have understood under the rest. Still good? Cool. So the lack of interruptions also means that globals are in the problem for events. In a sense, the fact that you have global state doesn't really come back and hurt you with something like this. Yeah, I mean this would not have anything to do with globals at all. Well, another example is that what if I make this zero? Now I figure it out. You have tap disabled but never mind. Okay, so let's say I make this zero which essentially is saying that set time on zero which says execute this immediately because the delay is now made zero. Execute this immediately. But even then when I run this you will say that print's hello first. Why doesn't do that when I have told it to execute word immediately? It's because it has to go on to the event. Execute this when you are free. Exactly, exactly. So that's why that happens. So, you know, with me so far? Alright. So why is this exciting? Everybody seems to be crazy about the event. Why is this exciting? First of all, this is perfect for you guys. In fact, maybe because I'm dumb but I don't know of any other way to do UI programming other than event groups.  Most of the time, right, the app is doing nothing. But you want to be interrupted whenever the user does something. So the event group is just perfect for that. And, you know, on the server everyone, this is a regular note chant so everyone's heard this. Most apps are just waiting for a connection to come up to the event. So, you know, you have to be most apps are just waiting for a connection to come in that they are to go and play the database so they're waiting for the database then, you know, they'll probably get some templates from disk and they're waiting for that to come through and only after that do they prepare a web page. So this is the gold mantra, right, saying that most of the time your app is doing nothing and so, you know, let's try to use that wasted time to do something better and event groups turn out to be, you know, great solutions to fix that. It's not the only solution it's a solution. There are other solutions as well, but, you know, that's the option that Node happened to pick and the reason they picked this is sort of two-fold. One is because we can pass functions around which is just very, very elegant in Node in JavaScript. And secondly, because there is a huge number of people who are already used to doing this on in the browser already so, you know, the learning curve is sort of easier when it comes to server-side JavaScript, right? So I want to come back to functions. Functions, you know, the disperse used to have this thing called lambda the ultimate, I don't know there he is, the disperse. Right, lambda the ultimate. So, yeah, so, you know, and this is the the only aspect of function that I'm really going to be talking about though. But the avenue to pass functions around all the jQuery guys might be familiar with this dollar.click and you pass it a function. Essentially what you're doing is, you know, here take this block of code, now wait for this thing to happen and when that happens when you get that message on your event loop, at that time use this use this function to, you know, do what you have to do, right? So that's what you're doing over here, which is a very powerful idea yet so simply expressed, right? This is another pattern. So this is a pattern where you're passing a function into another function dollar.click is a function, you're passing another function. Here dollar.ajax again something that jQuery guys must be familiar with is where you are passing it a function as part of an object literal, slightly different, you know, slight variation on the same theme and then there are the node guys who are probably seeing patterns like this Yeah, the text wrapping went crazy but, you know, so you must have seen patterns like this where you're basically saying get a file name you know, I want to read this file that's the file name and when that file, after you have done going out to the test, seeking, getting the contents, after you finish all of that call this function to do, you know, whatever you have to do, right? So basically the idea of passing functions around seems to be a very sort of common thread among all of these guys and so the node guys decided that, you know, if we have a standard way to do this, there's a lot of funky stuff we can do so let's try to figure out a standard way of doing this and they came up with this, it's called CPS or continuation passing style, I don't know why it's called that, I think it's because of the idea that you know, you code sort of continues where it left off the last time, I think that's what it is, but I'm not 100% sure So continuation passing style where you know, let's say that, so at the bottom there, I've got a function called make async call where I'm passing it, you know, value one so it does not matter what they are and the important thing though is that I'm passing the values or the regular arguments of the function first, then I'm passing the callback that has to be called which is the last argument to the function and within that callback, I always get the error object which is the first argument of the callback, right? node guys has decided it's a good idea if we stick to the standard the implementation of this would be, you know, where you've got something like that and you basically at some point when you are finished doing your asynchronous stuff, you call the callback that has been passed in either passing it an error if there was an error or passing it null if there was no error and you pass it, you know, as much amount of data that you want. The key aspects though, this is an example one more example it's too small now, isn't it? Is that visible? Not visible? Alright, so the wrapping will happen, I guess. So this is an example where, you know, you want to request some URL and you pass it a function that will do something with the response of that URL, right? Very simple question. Again to reiterate all the arguments that you want to pass in this case, the URL is passed in first and the callback is the last argument that you are passing into the function and within the callback the first argument to that is always the error, right? So I just sort of listed out what I have talked about so far. So it takes all arguments first, the last argument should be the callback, it passes an error as the first argument to the callback and then the remaining argument should be whatever data if there is a need to be passed into the callback, right? A couple of reasons why this is a huge hit. For me, one thing I'll, you know, I'm a very sloppy programmer sometimes. As much as I said that I take pride, I was just to brush you, honestly sloppy programmer. And I don't do a lot of error caching sometimes, right? I just, like, I fail at that and my servers have crashed because there's a lot of things. But the node style forces you to think about errors because you're always taking that error as your first argument. You have to do something with it now, right? So it forces you to think about errors. I like that, you know and so I feel that my code is somehow, like, you know, more resilient because of this pattern. So if you have, if you want to pass in some state into the callback, how do you do that? You can't. So usually that's done by closures. So it's not going to be passed into the, or you can bind it or you can bind it to a scope. You can bind the function to a scope if you want to. Feel free to interrupt me if you have any questions. What are you binding to a scope for? That is funky. Basically you're taking the this of the function and attaching that to an object and then you can access the this as well. That's a huge discussion by itself. We could talk about that separately. All right, I want to talk about ugliness. This is a problem with continuation passing style. I'm sorry, I'm zooming out slightly but I think it will probably help understand. You know, the example over here what it's doing is it's trying to read two files, do something with it and write a third file. That's what this is doing. So you can see there's reading file one, there's reading file two, then it's writing to the file and you know, that's how it looks. Apparently in my language returns can be capital. So, and this this is generally how your node programs look if you're a bad programmer like me. And that's why this has got an actual name for it. It's called name, it's called callback help because you're constantly passing callback after callback after callback, you know. And obviously a lot of people who come to node, this is the first thing that they complain about is that there's callback help. I don't want to... This is the ugliest form of programming I've ever seen who wants to deal with this kind of programming. It turns out they are right, they are not wrong. But there are ways to deal with it. For example, there is this framework called isync that I use a lot. It's about the same code, in fact it's slightly faster if anything. But it's doing exactly the same thing as this line. And so what it's doing is it's parallely fetching file1 and file2 and then when that's done it's writing that out to a file. So the actual library code does not actually matter. The idea is that I want to show you that it's possible to make things things look simpler. Right? Wouldn't that callback help be made to seem a lot simpler if you just declared each of the functions standard code. I think most of it is because you are declaring the function right there where you are using it. Correct. It still needs to be done smartly because you have to ensure that the declaring function does not let you take care of the depth. You still have to go deeper and deeper inside unless you decide that you want to branch off the writing and do that as well. It has to be done smartly. Though of course I'm sure the people who have a knack to do it will be able to figure it out well but usually a newcomer who's coming in will complain saying that I don't know how to make sense of this. Can you just go to the next screen? Yeah. This will work only if the two functions are independent of each other. So if I have to read from the first file and then do something with the second one then it won't work for me. Correct. So that's because I'm choosing to do it parallely over here. There is async.series as well that lets you go sequentially function after function. So after the first one completes go into the second one and third one and so on. So you can control that behaviour as you please. So it's sort of cleaner. I have only looked at the top parts of the code and it's made it slightly cleaner. But you know here's another variation of that again using async. Yeah. How in the back end it is parallely to both sides? Oh, okay. Great question. Right, right. So what happens in the async.parallel starts you're giving it an array. It starts processing this array internally. The array has got two functions and it starts executing the first function. It cannot execute both the functions parallely because JavaScript is single thread. So it starts executing the first function. The first function is doing fs.read file. So now obviously this process has to go over to the event loop because reading the file is not something that's done inside the JavaScript runtime or sorry not inside JavaScript language it has to go up to the event loop. So it schedules the read of this file onto the event loop. Now, now suddenly the event loop is free but async is now going to try executing the second function. So now the second function executes and that's also asking for reader files. The second file is also scheduled on to the event loop. So now both the functions parallely have caused the event loop to get scheduled. So whenever they will return they will return out of time the order might not matter we don't know at that point of time and whenever they are completed async figures out that they are completed together and we can go over how these figures out that they are completed together and then at the end we will call that last function that we have passed in. So it's essentially both of them scheduling stuff at the event loop one after another and then it could happen out of order or you know in order or whatever we can't be sure about that and then it will return whenever it's done. Right? You know Dharanjay was talking about functional programming and I have just you know recently started falling in love with it. It's absolutely elegant. I just love how you know you can just use and async lets you do this in over so async the library lets you do this over the event loop so you can actually do functional programming using the event loop that's actually a lot of fun. So here I've got two files that I'll just say you know I'm mapping over them and I'm saying fs.readfile you know it's that simple it's just two files are very elegant. Right? And then when they are done the callback is gone it's just beautiful. So anyway so that's that's that's our cps but cps is not it's not the solution to everything it's great when you want to do one thing and you want to do it once you know that's it's awesome in that kind of scenario but it sort of sucks when you want to do something repeatedly and it also sucks when you have to do the same when that same thing could have several outcomes like you call a function that would have several different things that could happen you know and cps does not really help very well over there so obviously there was there was an alternative pattern that was created and you know in the very early days of note I actually used to participate in the IRC rooms and you know as this as these things usually go and you go there with an opinion and you use like strongly defend your opinion and then you discover that you were a fool because they're just so much smarter than you but that sort of happened and you know ultimately this pattern is what one it's called event emitters and you know it's a very fancy name but really there are only two functions that you need to care about one is dot on and the other is dot emit dot on actually used to be called add listener at one time because it was sort of you know it was adapted from the browser so it used to be called add listener but add listener is just now sort of renamed to on or actually both of them are just pointing to each other and then there is emit as a consumer of something as a user of something that is using event emitters you actually don't need to use emit usually so most of the times you are only really using one function you're only using on so let's look at an example of that here I'm creating an HTTP server and you know every time a request comes in that function is going to be called the lambda is going to be called and you know if you look at the first request dot on data that's an example when I'm using the event emitter pattern I get a chunk of data repeatedly over so there is an example you can imagine there is an example of say uploading a file or something right so you've got a huge video which is say one gig or something and you're uploading that to a server so you know there will be passed on in chunks because that's how PCB works so you will get chunks and chunks of data and so each time you get a chunk the on data event will be fired that's the terminology the on data event will be fired which essentially means that if you have a listener that is listening to data like how we have over here then that function will be called every time that a data chunk appears similarly end is something that could happen when the stream is complete and error could happen if there was some problem in the transmission so here's an example of something that is actually having three different behaviors one of giving you chunks the second of actually stopping the stream and the third of possibly having an error in the stream and so event emitters are great for that how bad am I on time 10 minutes more so there is another pattern to use what is here in the earlier context I actually had encoding the expected sequence of how this was supposed to behave whereas this sequence now data and error could come in any sequence and your code is no longer making those assumptions which it would have had to earlier yeah so it turns out and you know unfortunately to add to the complication the fact that in CPS so elegant in terms of it sort of understood that the last argument has to be a function and here the event names are not standardized as well so you know there are some dissonance that is happening it's not very easy to use event emitters there are problems I don't know if that was your question actually I was I thought this was a big plus for event emitters that you no longer had to sequence out stopping first to handle data then handle and then end layer you are basically saying whatever shape and order it comes in I thought this was a plus for you I mean so that's the reason why it was created of course so you know the fact that things could happen in any way in any order and there could be entirely different things that are happening not simultaneously but you know very close to each other and you would be able to handle them within the same you know same block of a code at least so that's definitely a plus for you alright any questions so far on event emitters isn't the same the same programming paradigm is used in socket.io as well yes yes you are right and socket.io even on the client I believe we use the same one so it's a great example of where an idea from node crossed over and went to the client and you know it's the same pattern being used on the client as well exactly the same awesome so that's an example where you know an idea sort of went from the server to the client it's very interesting so you know obvious candidates for emitting events are DCP, UDP, sockets files as you are reading chunks of files again you know that's an example and HTTP request we just saw in the previous case so you know these are typical cases where event emitters are used but unfortunately since there's just so much code to be written to use an event emitter you know there are things like the read file function that I showed you which is generally the thing that you want you know in a lot of cases is that you know just go fetch the contents of this file for me and give it to me so sometimes you know people have created functions that sort of do all of these complications internally and give you just one chunk in the end you know because it's sort of more convenient that way right before I proceed it's the same exact same code from last time but you know can you think of any problem with this code other than the fact that can you think of any problem it's a problem that you know chunks will not get garbage I mean chunks will keep on up holding nothing on error absolutely so what happens is let's say you're uploading somebody is uploading a 5 GB file to your server your server only has one GB of RAM you know your server will start swapping and it will eventually crash and that's because you know chunks are keeping on getting accumulated in memory and you know it will not be released until you're actually doing something in the end you know you're just keeping on adding that up right so that starts getting that starts becoming a huge memory overhead so you know the solution obviously is to avoid buffering that that is classic buffering that you are doing there the solution is of course to avoid the buffering so rather than waiting for end to fire you call you do something right when you are receiving each chunk of data rather than you know trying to wait for collecting all the data together you just do it in chunks right for example let's say that you are having a file upload happening and you want to write that file to your server to the disk you could just as you get a chunk you just write that into a file and you know just keep doing this one after the other so you don't have to hold this in memory you can just keep flushing it instantly and it turns out this pattern is actually rather common in JavaScript in Node people start discovering that they are doing this actually very very frequently so they decided that this has to be formalized as well and as recently as 0.4 I think in Node is where they started talking about this and so they decided they have to formalize it they have to make it easier to give it a better API make it easier to write and so streams were spawn paraphrased and I probably won't mess up with you but I think this is by by Isaac's Isaac is the current maintainer of the Node project but yeah that's what he said he said streams are so awesome they alone justify the existence of Node that is how awesome streams are everything that has been done in Node until streams was created is essentially garbage compared to streams streams are just that awesome and let's show you an example of how that works those who are familiar here with Linux must have done something like this where you tail a log file and then grab it for a certain pattern and if you look at what's actually happening what Linux is actually doing is taking the standard out from your first application which is tail taking the standard out from that and then connecting that into the standard in using this pipe operator let's call it an operator I don't think it's an operator but connecting that into the standard in and then it's running a pattern over that so that's what's happening over here so eventually you are talking about building network applications that can be composed together of smaller applications I think this is what they must have been referring to they are very diverse over the network so you would have so you would have data coming in from different sources from across the network and then you would sort of piece them together by using small applications that are really doing each piece so to give you an example here is one where I'm reading something from a file and I'm piping that to a response so let's say you want to download a huge file I'm reading something from disk and I'm flushing that over your HTTP response so that's how you are able to download the file again obviously none of this is being held in memory this is very very efficient memory wise because it's just chunk after chunk that you're reading and you're writing and you're reading and you're writing it's essentially under the hood it's just the same but it's being packaged differently to appear more elegant as compared to the ugly limit amount of code that we were looking at so far and people have gone crazy with this there's amazing stuff that's happening people have written proxy servers that's one line of code you know essentially just take stuff from there go make a request and impact that over the response that's it and so this is one line of code that's a proxy server it's just very very elegant but I have to add that it's just very very elegant I just know how beautiful it is sadly streams aren't quite all that ready yet it's very hard to build a stream a stream that is pipeable is very hard to build it's hard so these streams that you can pipe from one location to another is called a read stream that's one type of stream there's also a write stream which is one that can accept data so there's the read stream on the write stream and then there are read write streams that can both accept and you know spit out data and these are very hard to build and you know 0.9 and 0.10 there's probably going to be a 0.10 for node which is a very weird number to have but you know whatever 0.10 they say that the focus is going to be streams and the focus is going to be to fix the API for streams and to make it really elegant if you look at github.com slash Isaacs there's already a lot of couple of ideas that he's already toying around with to make streams easier to work with Isaacs is the man he's got a lot of interesting stuff going on there and yeah let's be a little forgiving these are early days for stream streams are barely about less than a year old so there's a lot still to be evolving in the stream space quite Will it support renewable upload and download out of box so that's the thing is that you can already do upload and download out of the box this was an example where you can do download right this is an example so the problem is that to do that it's entirely possible to do that no doubt about it but to do that it's actually a lot of work which was my first point over years in the streams are hard to build right so it's entirely possible to do that your board will look very elegant after you have done all the hard work but doing that hard work is difficult so right now it's not you know it's not there yet it's not very beautiful yet so but you know it's something to watch out for in the future I think that in the future this is what will become the most interesting piece in Node same question regarding this Node.js is using in networking so its P2P communication can be totally replaced by this thing or not same thing P2P communication totally reduced reduced by this things that same thing that you can download it after some time or resume it any time so if it is in networking we are using in networking model we can directly build into the system and resume after some time if connection goes lost we'll stop there then read again from the disk and then flush again into the disk is that possible in the future I have read IEEE paper of 2010 about the Node.js I think that same same concept was that about this thing that you're using in networking scheme networking thing I don't know I guess I'll have to sit down and understand the scenario that you're talking about let's take that up right after this talk because I don't want to get everyone sitting down listening to that but that's interesting I want to explore what that means cool any other questions so far so that was the point my point was not about Node my point was not about browsers it was not like married to any one of them my larger idea was that the fact that there is activity happening on both sides of the network is helping improve APIs for everyone so now these kind of things are starting to happen on the browser socket.io is an example of that people are building much better APIs there are so many things now when you think about that that can be dealt with in terms of streams or in terms of event emitters or in terms of simple callback passing style on the browser that it's just beautiful things like there's now five system APIs that are available in the browser and you could think of that in terms of streams there is web sockets of course which we have already talked about which you can think of in terms of streams there is also the event stream spec if you are aware of which is called server sent events in some cases that's another case where streams are really useful there is also plain old where there is data coming down over the wire and you can sort of deal with it in chunks so that's another case where there is data that's happening asynchronously and then of course things like button clicks and form upload these kind of things can also be thought of in terms of events so probably in the next about six months to a year I think that there will be new frameworks that will come out that will start using APIs that mirror nodes API very closely there are already some attempts done I recommend you look at work by this guy called Max Ogden you know he's been doing some very interesting work but he's building client API that actually mirror node server API it's very interesting to work with those in terms of you know it's the same sort of paradigm that you are using both ends so that's very interesting and this is uncharted territory more or less so you know if you are a good client side developer and you are familiar with node give this a shot you could be the next guy who is doing this right it's very interesting and you probably should and that's a wrap that's all for me thanks you thanks thanks now any questions of course and if you're too shy to ask me right now you can you know catch up later go ahead this is one of my first events like this only one question of the topic since when are people giving presentations in the browser well that's been going on for quite some time congrats congrats on your first event yeah but yeah people have been giving so this particular one is by this guy called Hakeem Hakeem.se very popular on the interwebs for his work on you know generally about graphics and stuff like that he's one crazy guy this one this I think this is called reveal.js reveal.js there is also an id for it now yeah there is an id for it now as well so it's amazing impressive so Impress has Impressionist which was created by a guy in Bangor he works at Redo and reveal is by Hakeem who built his own id go ahead my question is specific to software there is something that interests me about more.js in the sockets part but when we talk about sockets we are also considering the hardware interrupt that the socket is going to in go which is pretty resource intensive so how gracefully does node handle that possibly node is great designed for that I am not sure about that I am quite unclear about that does node handle that quite gracefully or is there something else that needs to be I am not sure because I don't know too much about what is going on over there most of that code is in sea land and sea for me is like alien speak I can't understand sea there are just too many pointers flying around for me to make sense but I just want to make a quip about the fact that Anjai was talking about the worst language you said it was php I am surprised because maximum WTF was php I am not sure I am surprised because Perl still exists because I can't distinguish I don't know when Perl stops and a regular expression starts I can't make a difference correct nothing working on the keyboard could be a valid Perl code so I have a question about a paradigm man you have a system where you want to broadcast a message to let's say 50,000 simultaneous users so far I am not able to find an elegant solution for this so it works very much as if I am sending a message to 50,000 users where each message might be different is there anything which could be done where the message is seen when it is broadcast something called multicast but even then below the system it works very much in the same way it is relating to each connection individually not necessarily if your transport supports multicast it is multicast all the way so usually ISPs don't support multicast at the consumer level but what happens is distribution services like Akamai this is their primary business I mean apart from their caching business what they do is set up multicast servers at major ISPs around the world and they do a single cast to that edge point and from there it is split up into clients which means that your source server doesn't have to take off the load I don't know that myself I do know something every day we will go back to the web socket part I missed the initial session about that is it TCP over HTTP or is it web sockets I don't think anybody is sure anymore that spec has just changed so many times it is not it is not over HTTP it is negotiates over HTTP it starts from HTTP and then it moves it is almost like a TCP connection HTTP is a command that you can use to turn it into a web socket it says upgrade changes the protocol and how different it is they also claim that it is port sharing with HTTP yeah because you make an HTTP connection and then tell it okay I want to convert it into a web socket which means that your server whatever you are using must understand the web socket the conversion command and Apache doesn't support it nginx doesn't support it so I should use Nord so if the web server need to understand the web socket protocol as such then you need to have some gateways in between so usually the gateways are the ones that don't understand it like the popular gateways are what Apache, nginx neither of them understand web sockets there is one company called Causing which they provide some web sockets gateways for the other that's because the popular ones don't support it out of the box but there are patches so you can patch your nginx build a custom version which has the socket support built in and the thing is because the web socket standard itself is not final you know it's been changing a lot over the years so which is the reason why Apache refuses to make it part of the official business because that means it's becoming standard because Apache itself is so popular that once it's deployed there's no hope of changing it we can use HAProxy HAProxy can I think you can use HAProxy in front of Apache and that will sort out your web socket cuisine and I think you've tried pubnup.com you were asking what 50,000 broadcasting that message to 50,000 that was for our system we failed that problem in our system so there's this service called pubnup.com so I think and this is the specializing they have this full infrastructure they'll just give it to this other service basically so you just try that pubnup.com and go and check it out I was just saying that I think recently nginx converted to supporting web sockets in their latest builds so I think you should expect that is it in release? it's part of their roadmap now but I guess it'll again be a few months before it comes out in the next open 2 which is what motion will end up using and the guys are NTS so I have a question regarding what sort of programming style would you really like to use with the synchronicity and all this stuff what we see with Node is it's more about emitting events and callbacks there's another style which I'm not quite familiar with but something called as promises it makes it look very procedural it makes it look very easy for the developer and I constantly thought about adding a slide for that but I forgot about these relatively less common patterns but are there anyway futures, promises and stuff like that by and large I would recommend you should not use them simply because there are not enough people using them already so it must be a chicken and egg problem I'm not really sure if they're good or bad because I have not used them myself I would recommend that you don't use them anyway because it does not have enough mindshare there's not enough activity going on there and in a lot of cases you need to have buy-in that entire stack has to be using that mechanism so in a lot of cases once you take that decision then you get stuck in that world and you will not be able to come out of that so I would recommend that you don't go there usually but don't add something of support for futures and promises no it doesn't, people have done stuff with working at the sea level working with stuff like that so there's stuff available for sure you could play with that if you want to but that has not managed to garner enough community support yet so people are still playing with ideas like callback passing and event emitters it's okay for like job care developers who are very much used to callbacks and event emitting at the UI level and that's what we do in day in and day out but what about someone else coming in now that we are projecting node as the server language so what about people coming from java that reminds me of this thing that Bruce Crawford said that JavaScript is the one language that when you are starting work with JavaScript everybody thinks they don't need to learn the language that's how it works everybody just opens their editor and starts writing JavaScript everybody is a pro at JavaScript that's what everybody has used and when you are going to learn Java you would learn how Java works you would figure out what the videos in Java are you would figure out what design patterns you should use in Java but somehow when you come to JavaScript you don't bother doing that you just think that oh I know Java so I obviously know JavaScript and so I am going to do JavaScript the way I am used to doing it in Java and so I think and it's true that there are more people than not who do that honestly I did that myself when I came to JavaScript


Hi everyone, Sean with JasperiesCaseBrates.com here doing 2019-2020 Upperedeck the Cup Hockey Three Box One Half Case Random Team Number One. So all card ship, all card teams are in. Here is our list of customers from Sean Maddock down to Oliver Soria and the teams from the Ducks down to the Jets. Dice roll to randomize both lists and pair them up. Four to five, nine times. Good luck. Ninth and final time from Sean O'Leary down to Sean O'Leary. So nine times on the randomizer, now nine times on the teams. Ninth and final time from the Kings down to the Penguins. So nine times on the teams, nine times on the customers, and nine times on the dice. So Sean O'Leary with the Kings, Danny Geonsopoulos, Blues, William LaMika with the Lightning, Jacob Johnson, Blackhawks, Daniel Katz, Coyotes, Sean Maddock Jets, Mike Tower Rangers, Mike Gregorian, Ducks, Steve Wright, Wilde, Sean Maddock Leafs, William LaMika, Bluejacket, Sean O'Leary Predators, John Loverty, Canadians, Peter Aang, Sabres, Bennett Page, Redwings, Daniel Katz, Panthers, Ronto, Vynan, Bruins, Fred Williams, Oilers, Stephen Staphonic, Hurricanes, Fred Williams, Nights, William LaMika Islanders, Danny Geonsopoulos, Flames, and Devils, Oliver Soria Capitals, William LaMika Flyers, Sean O'Leary, Knucks, Mike Gregorian, Senators, Chris Parent Stars, Daniel Katz, Sharks, and Avalanche, and Sean O'Leary with the Penguins. So trade window is open. While you guys are considering trades, let me sort this, get it all on one screen, I'm going to open up this case and figure out which half case or which three boxes we are going to do. So there's your full list. Here is the case. Let's pop this open. You should be able to, Oliver. I don't recall if I've ever pulled one from this, but I don't know the checklist on hand. So here are the boxes. Dice roll, one, two, three for the left boxes, four, five, six for the right boxes. So it'll be the boxes on the right. Which means these boxes here will be four. Random teams, or random team number two. Two on the top. Okay, so it doesn't look like there's any talks of trades. I'll pop back over to the screen one more time just in case anybody didn't know who they had. Turn on the Nik cam just so you guys can see all the boxes are there. I'll give it another 15 seconds for trades. If nothing, then we'll go ahead and close it as the Bruins available for trade. Or Ron, sorry Ron. Joe says no on OV, Oliver. Okay, 15 seconds on trade window guys. So trade window going once. Bruins for fliers, Ron. You have that option. So Ron, if you want to do that trade, let me know. If not, trade window is going once. Trade window going twice. Trade window going three times. Trade window closed. So try to trade couldn't trade mojo, Bruins and fliers. There you go. Ron says thanks, but no thank you on that offer. And here are our boxes. There you go. First up is Alexander Barkoff for the Florida Panthers. I have my list. I just didn't print it. Hold up. There you go. Final list. What's up, zoom in. Happy Wednesday, sir. Florida Panthers is Daniel Katz. Nice Dante Fabro three-color patch and Otto 188 out of 249 for the Predators. That is Sean O'Leary. Nice start. Elvis Merlinkin's three-color patch, Otto 68 out of 99 for the Blue Jackets and William LaMica. And Mario Lemieux, 15 out of 25 for the Penguins. Sean O'Leary. Love that guy. I used to play him in NHL 94. Used to play the Penguins. Used to use the Penguins all the time. I think it was him in Jagger. What's the shit? You got a triple relic for the Canucks, Elias Pedersen, Brock Besser and JT Miller, 10 out of 33. Canucks, Sean O'Leary and Nick Suzuki, 26 out of 249 for the Canadians and John Loverty. To finish off box number one. I mean, it's a very nice hit. I don't know if that's the best thing we're going to get out of the case. That's for sure. But it's very cool. That's for sure. You've got Steven Stompkos for the Lightning. That is 118 out of 249. Tampa Bay Lightning and William LaMica. What's up Jake? How are you sir? And Nicholas Haig, three-color patch, Otto 229 out of 249 for the Knights and Fred Williams. Nice Eric Stahl, one out of eight three-color patch Otto for the Wild. Really nice patch there. Sorry. Yeah, Minnesota Wild Steve Wright. Yeah, the cuff is the nicest stuff there is, Roger. When it comes to patches and everything. Very nice hit there. And Quinn Hughes, enshrinments, 76 out of 99 for the Canucks and Sean O'Leary. Very nice man. Very nice. Canucks again. And Quad Relic for the Oilers. That is seven out of 24. Leon Dryside or Ryan Nugent Hopkins, Miko Koskinen and Oscar Clefbaum. Oilers, that is Fred Williams. And Cody Glass, 228 out of 249 for the Knights, Fred Williams. I was here. I was here. I was online every day last week, which was cool. So you got to see me every day. Just not in person if you were at the National. Last box guys. Gregorian. That is one 74 out of 249. And another Quinn Hughes, 76 out of 99. Canucks again. Sean O'Leary. And got Sean. Very nice patch there too. Nice break for you. John Klinsberg, three-color patch, 51 out of 99 for the Dallas Stars. Chris Parent. And Dustin Brown, scripted sticks autograph, Silver Ink for the Kings, 14 out of 15. LA Kings, Sean O'Leary. Off to grab another big top-liber for that one. We do have a redemption there. And Barrett Hayton, 15 out of 249 for the Arizona Coyotes. And Daniel Katz. Okay, so the redemption. 1920 NHL the Cup, base set rookie auto-patch, number to 249. Daniel, you're taken. Daniel, you're taken. Don't know that needle of hand. Let's look. Group break. 1920 the cup. Nope. Yeah, don't want to work here. What are you doing a group break checklist? Sharks, Mike? Okay. Let me just try to get back to this and see why it's not. Let me search the cup. Here's the cup. I don't know why I typed in 1920 the cup hockey. Apparently their search doesn't want to work. Team Daniel. Yes, that is San Jose Sharks. So San Jose Sharks is going to go to Daniel Katz. There you go. Yeah, I'm looking at the cardboard connection one too. Why would I know who Bill Allen was? Bill? And there you go guys. That's the break. That was the first half of the case. That was 2019-2020 upper deck, the cup hockey, three box, one half case, random team, number one from jaspyscasebreaks.com. I'm Sean, jaspyscasebreaks.com. Second half of the case is in the store.  Find stuff like that. jaspyscasebreaks.com. Thanks for hanging out. We'll see you next time.


In a binomial experiment, we repeat a simple experiment a fixed number of times, an outcome of interest has a fixed probability, and we're interested in the number of times an outcome of interest occurs. But sometimes we repeat an experiment until an outcome of interest occurs a number of times. For example, calling customers until you make five sales, drawing cards until you get a pair, litigating until you get your way. And this gives us a negative binomial probability. So for example, suppose you flip a fair coin until you get three heads, find the probability this will take five flips. So to understand the negative binomial distribution, here's an obligatory riddle. Why is it that your keys are always in the last place you look for them? And the answer is that once you find them, you stop looking. And this is an important idea to keep in mind when looking at these negative binomial probabilities. If it took us five flips to get three heads, then we know that the fifth flip had to be the third head. And in fact, we can go a little bit further. In order for it to take five flips to get three heads, the fifth flip had to be a head result, and the first four flips had to have two heads. And this is the only way it would have taken us five flips to get three heads. If the first four flips had more than two heads, we would have stopped earlier. And if the fifth flip wasn't a head, then we'd keep going. And so what we sometimes call the negative binomial probability really is a special case of a binomial probability. So let's analyze that. The probability of getting exactly two heads in four flips is a binomial probability, and we can calculate that to be. And the probability of getting a head result on the last flip is 0.5. And so the probability that it takes five flips to get three heads is the probability that we got exactly two heads on the first four flips, 0.375, times the probability we got a third head on that last flip, 0.5, and our probability is... Now we can derive a formula for the negative binomial probability, but it's actually easier to reason your way through it, and there's less chance of making a mistake somewhere along the way. For example, suppose a con artist could get a mark to give them their vote. I mean, suppose they can con a mark to give them their money with probability 0.05. What is the probability the con artist will have to talk to at least ten people before finding two victims? So again, if the keys are in the last place they look, if they need to talk to at least ten people, well, let's rewrite that, ten or more people to find two victims. This means they didn't find two victims among the first nine. In other words, of nine people, zero or one were swindled. So the probability that zero of the first nine were swindled, again, that's a binomial probability, and we can calculate that. The probability that one of the first nine were swindled, again, a binomial probability that we can calculate, and this event, ten or more people, is the same as saying of nine people, zero or one were swindled. And so those probabilities give us about a 93% chance that this con artist will need to talk to at least ten people.


Introduce yourself, starting with you, John. Yeah, so my name is John Moore. I am with the Kamarazzi Corporation. I'm from Canada, actually Ottawa, Canada, where I think last year's event was held. And I've been in IT, somebody said it yesterday, they wouldn't admit to doing over 20 years, but I'm over 20 years. And been in the business a long time. So bringing in Canada anyway, to the whole transformation movement, Stephanie's movement, the whole transformation movement is taking off. And I think there's no real IC vision or process like IT for IT. So that's what Kamarazzi is bringing to the table is focusing on IT for IT, focusing on mapping to business value, mapping back to the services. And I love hearing Stephanie talk about services because IT never talks enough about services. So, yeah, so that's what we're doing and pleased to be here. Thank you. Hi, I'm Mike Fulton, 25 years in IT, last 10 plus in strategy and architecture roles. I am currently working for Nationwide. We are on your side. And for all of the international folks, you may not know that as our jingle, but I am currently heading up their technology innovation department. Before Nationwide, I spent 20 years at Procter & Gamble, and then a couple of years as an IT strategy and architecture consultant and chief digital officer. So, oh, and I co-chair the forum. I was gonna say, there's something about the chair of the forum in there too. Something about that. Okay, so, Lars Rosen, I know a lot of you guys here in the room. I've been in IT for more than 25 years. Just, this seems to be the standard thing to say when you're in this forum. I work in micro-focus. I didn't get a job there. I was acquired in and I've been through the acquisition route and four or five times or something like that. It's always fun, but it also implies a lot of transformation. So, I'm kind of indirectly becoming expert in that, but my day job is cross-portfolio strategy for our organization. And I had the core group that stewarded the normative part of the IT for IT standard. Yes, so yeah, Lars and Carl here, kind of the key sort of founders and kind of instigators, I guess, for getting the standard off the shelf into the real world here. So, we can have them to thank for that. Somebody to blame, yeah, for all this work and all this great knowledge. The most emotional posters there. Yeah, and some I'm sure resonated more than others. Okay, so with that, I'm gonna get started with the panel. And so, the one thing that kind of struck me is digital enterprise. So, I know we're working through some opportunities to define that as a forum, some of the forums are working on that. But in your words, please define digital enterprise. So, Mike, I'm gonna pick on you first. Okay, so for me, a digital enterprise is all about an enterprise that is using technology to transform its business model and its engagement with customers. Simple, sweet, okay. Lars, anything to add? Sure, you could say that in many ways, an awful lot of companies today are becoming digital enterprises.  It's something around using more technology in the delivery of the service. But another way of saying it is, if what's in your service catalog on your webpage is something you sell to the customer, not something you sell to your internal organization, then you're probably a digital enterprise. But it's not a precise definition, nevertheless. And how about you, John? I think it's about, like Mike said, driving business acceleration, innovation, and using technology. I mean, if you think about the digital-only or native digital organizations that thrive on, that's all they make money on is using digital. Yeah, and I've seen that. Companies are predicated on the technology they have. They don't exist unless the technology's there assisting to deliver their products or services. Yeah, I think there's an important point around what's different about digital enterprise today versus what we've been as organizations for a long time. And for me, we have applied technology to improve our businesses for as long as IT's been around. It's been the job of enterprise architects to transform businesses. For me, though, I think that the shift from digital that is really key is that rather than looking primarily inside the company within our control, which is where we historically have operated as IT, we're turning outside. We're starting to look at things beyond the walls of our company, and that's to me the biggest shift that's happening in this digital evolution. I would agree. Ideas come from anywhere, anywhere and everywhere. But it's always important when a new trend comes around and the digital enterprise is a buzzword these days, honestly, to think about, well, what's the first digital enterprise we had? And I guess it's probably AT&T started about 120 years ago because fundamentally it was technology service that was delivered as a service. And nothing really changed since. Well, that's not completely true, but if you look at the telco business and what they did, especially when they digitized the telco transmission net, it was very much a digital enterprise. But it's also interesting to see all the pitfalls they had and all the wrong things they did in that process. And let's make sure we don't repeat that when we do it for the rest of the industries. Agreed, agreed. No, great definitions. I love all those. Next thing I wanna really expand on here is what are your concerns with the increased challenges facing the businesses today, given that shift to digital enterprise? So, and I'll pick on you, Mike. You're the quietest. You said you're the quietest. How often does that happen? I'm the quietest, right? Give me a few minutes to get warmed up, apparently. So, I think for me, when I look at the biggest challenges, the pace of change, first and foremost, is the number one challenge that I see facing enterprises all around the world. I think as we look at how rapidly technology is evolving, it's just becoming very difficult for organizations to keep up with that. And so I think we have to think about new ways of working to be able to keep up with that pace of change. Yeah, it's, again, I'll go back to my Telco example. Learning from the past, one of the things they didn't manage to transform when they transformed into digital was to be agile. They took 20 years to introduce their ISDN and 12 years to introduce ADSL because there wasn't this competitive environment. And also, at the same time, it was very clear that they absolutely hated IT and didn't use the knowledge in IT in being smarter about what to do compared to doing it the way they've always been doing it. So I think that Charlie, if he's in the room, maybe he's not, said it correctly the other day around, not the other session earlier today, that finance is an example of a line of, or a corporate function that people sort of respect. You need to understand finance, but you also respect that finance are the ones that really understand the bigger scheme of how it all works across the countries and what have I. But that doesn't seem to be the same respect of saying, well, there are some professional IT people that can help the line of business and vice versa that doesn't exist. And if you don't establish that, you're gonna fail. So, I mean, really the incorporation of IT into the business mix basically is involving IT versus being smarter together. Good point, good point. How about you, John? I find, and I don't necessarily think it's geographic, but I find, you know, I like the fact that Stephanie came before us because she talked about the silos. I found that over the many years, the struggle that organizations have in just changing the way they do things. And with what Mike said, the pace of change that's happening, they have no choice but to now start to change the way they deliver services, not from a silo perspective, et cetera. But the disciplines in changing that and the force, I guess, the mandate to be able to do it, it's a big cultural shift that has to go on. I find that one of the challenges as well. Yeah, some say that changing culture is harder than anything else, right? Yeah, there's another thing that we talked about earlier that you were highlighting as we were prepping for the session, John. The one of the things that's going on that's an increasing challenge for organizations all over the world is data privacy and legislation associated with that. And the introduction of GDPR and all of the various implications of that. It's a challenge for businesses to understand how to handle that, how to keep up with that, how to anticipate what's coming next. So I think that's another challenge we mentioned. I would also kind of build on that to say just the importance of data and what's possible with data. I'll give a shout out to my colleague, Don Brancato, over there from the Open Platform 3 form. And all of the work that they're doing in there to identify standards around data interchange and standards around data lakes and big data platforms. I think the volume of data that is available to businesses and the ability to make decisions in different ways using advanced technologies like artificial intelligence, it's increasingly becoming difficult to understand what are the right things to do and what are the things not to do. I could talk for a long time and we will get into some of this about how that's impacting us in the insurance industry. You're getting warmed up? I am starting to get warmed up a little. All right, all right, well, that's good, that's good. Well, and this next question is for you, Lars, because you touched on it in your last answer, which is what's the role of IT and how is it becoming more important to these digital businesses as they try to transform? What can we do in IT to make that better? I don't think there is a single answer at the moment. Everybody is struggling with it and unfortunately many organizations also struggling with the fact that culturally everybody hates IT because they are the ones that are hindering stuff to happen, et cetera. Everybody also hates finance, but they accept it exists, right? I guess. They sign the paycheck. They sign the paycheck, it's not the same with IT. I think that's a couple of places. One is the sort of on the corporate level, you can simply say, well, governance, risk and compliance, the GDPR things and also security in general. Lines of business can't figure out how to do that, period, right? It needs to be something that is handled by a professional unit that concentrate on that, corporate-wise, but do it with all of these digital service that is being introduced. The other thing is that IT itself needs to think much more about being a platform provider. So creating that catalog, operational catalog where you have service available that the lines of business IT really needs and that's the shift of thinking for IT from being a cost center where if you want something to do you come with a pack of money and then wait nine months and you get it to a business center that predicts what the lines of business need and provide those platforms and services that the lines of business needs. That's a cultural shift and that's the biggest hindrance we have at the moment. See you at the table. How about you, John, what do you think? Well, just to go from cost center to no pun intended for gas and oil, but service center, right? The idea of that, exactly. I think IT's role just because of what's coming down from a technology perspective I think is much more important. What I've also seen is that over time as to what Lars said where IT seemed to be the wall to get beyond and I work a lot with the federal government in Canada that went from 78 different departments into one shared services and could not deliver services for years to those departments. Took all their money, but didn't deliver any services to the point where the departments went out and started getting cloud services, bypassing shared services in IT altogether. So it's like there's an important delivery role there and the other point I look at is the fact that if you think about traditional organizations with IT, a lot of compliance, regulatory, all of those things and then let's think about the digital native organization where they kind of have forgotten about compliance altogether. That's why the IT role for traditional organizations I think is very important. One of the struggles I think then digitally native organizations are gonna have is within the compliance side of it. They're gonna have to engineer it backwards. Come back in. Exactly, yeah, where I think that's why the role as we start seeing more data coming in, artificial intelligence, a lot of the standards and compliance pieces of the puzzle that need to be addressed by IT. Agreed. I kind of just making one more comment to what you're making of statements here is that again, comparing to the financial department CFO, I don't think any company in their right mind would believe that they outsource the CFO role. They might use a lot of service providers, Deloitte, Pricewaterhouse, whatever to help them doing the finance but they know that they are responsible. And so there is this trend or was this trend that, okay, the IT is something we outsource because we can't figure out how to do it. We get somebody else to do it, right? And it's okay to outsource some functions but you are still responsible for IT, right? And that's what the organization needs to learn, unfortunately for some, it's gonna be the hard way. Yeah, as we've seen in Mike, I know you've got some, you're sort of right in the path of that, how can IT help innovate in the business, right? Yeah, absolutely. So it's interesting. I think it's an interesting time that we're in right now and to use Lars's example of the finance organization, you would never hear nationwide turn around and say we're an accounting company. But our CEO recently was heard saying that nationwide is no longer an insurance company. Nationwide is now a technology company that happens to sell insurance. And I think that speaks to the transformation that's going on in industries all across the world. It speaks to the importance of information technology. It speaks to the transformation and the role that IT is playing in the business. And it's really important for us to step up to the plate as IT professionals to that challenge. So I think we all have to be doing more. I think we all have to be looking out ahead, trying to set the path for the organization. And figure out how we're going to take these emerging technologies, I think we'll talk about in our next question, and identify the new what's-possibles, and help utilize those what's-possibles to solve real customer problems. Yeah, well, and so keep the mic there because what I would like to understand is how you're doing that. I know it's part of your role is to go out there and look externally and bring some of this interesting technology back to the business. What technologies are you finding? What are you drawing? What's driving your business? So for my team specifically, we have a couple that we're looking at. We're looking at blockchain. We think that's gonna be fairly impactful to the financial services and insurance industry. We're looking at artificial intelligence. Again, with all of the data we have as we try to do underwriting on our customers, the artificial intelligence that we'll be able to use to do better underwriting is really important to us. We're still continuing to look at ways that we as an organization can leverage kind of a platform model. Utilize APIs and microservices in a platform mentality. So that's another key area. And we're starting to take a look at non-artificial intelligence, virtual reality and augmented reality, and trying to figure out how that's going to change how we interact with and embrace our customers going forward. But probably the most interesting thing I would say that we've come up with as a team over the last year has been that we don't believe that the new technologies are the important piece. What we think is actually the really critical thing is identifying not the one technology that's gonna be most impactful, but what are the technology convergences? How are multiple technologies going to come together and combine in new and interesting ways and allow us to do things that we were never able to do before? And so to me, that's the kind of thing that we're trying to focus on. How are we gonna use IoT and blockchain and artificial intelligence together and converge those into an interesting solution? As we look a little further out, how are we going to leverage quantum computing and AI and 5G? When we think of, as was mentioned in one of the keynotes this morning, living in a world of abundance, quantum computing and 5G really dramatically change what's possible when it comes to compute capacity. And so we're trying to think about how those convergences are really gonna change, fundamentally change the game. Yeah, I would agree. Quite a number of things. I'd like to put it under the hat of Frickler, Frick, I can't say that word actually, Frickler and so that the compute that is easy to do. I know I did not drink beer today, but anyway, I'm getting to it eventually. The concept of actually making stuff easy to use. Monetization. It's not just it's commoditized, but actually make complex stuff easy and because that goes back to the agility. So you can say that's part of making platforms work seamlessly. It's also something like the old technology to make sure that you can use old technology in the new settings. We got, I don't know how many billion lines of Cobalt code running on mainframes. It happens to be my business, so it's shameless plot here, but how can, but nevertheless, it's actually a gross business for us. Double digit gross in Cobalt, right? And that's because all of these back end systems written in Cobalt, they will support the digital enterprise and you're not gonna rip out in your insurance business necessarily all your Cobalt mainframes, but how can we make it frictionless? It was almost correct. Frictionless. Frictionless. Got it. You got it, right? I didn't have to think about the word, then it was easier. And to make sure that you can actually make those updates in an agile manner so that you can get your stuff out the door. And that's, again, not thinking about the next new technology, but thinking about this thing. The other one is obviously big data and what comes with that. It's gonna change the world. So how to consume, how to leverage the technologies that are complicated much more easily every day. I would even say that aside from, and Mike, you're in that role of looking at newer technologies coming, but even just using technologies that have been around for a while and maybe to the point that Lars saying it not necessarily being easy to use them, but I think of how many organizations, specifically in IT, are not automated to the max or not using orchestration and tools and solutions that are around to be able to do that for a long time. So even existing technology, I think that IT is not necessarily using for benefit. And then the other thought that I was thinking about is when you think about what's happening with container technology and not just the technology, but the ability to build applications. Somebody said this a few months ago about everything being designed and built now from an application is meant to fail. Think about that for a second. It's meant to fail. Whatever happened to when we backed up systems and we did synchronous replication and all of those things, those things are gonna go away when you start having applications that are meant to fail and recover. And that's happening now. So I think the implication, and this is a little off topic, but I think the implications to how IT manages those services as new applications as well. Come on, I think it's important. Yeah, I would build on that. This is something that I was having a conversation with earlier and maybe it's a little provocative for the open group, but I would say the technologies that we're faced with now as well as some of the methods we're using as IT professionals to deal with those are in some ways making architecture obsolete. And I would also profess to say that the pace of change, the speed with it which were being impacted by technologies is making architecture more important than it's ever been before. And so there's an interesting dichotomy there where I think a lot of organizations are struggling with the mixed message and they're struggling with what to do with this role of an architect and where it fits in their world. And so particularly in this open group conversation, I think the role of an architect in a digital enterprise will continue to be an interesting conversation as that role morphs going forward. I think some of the DP box stuff is trying to address that in a way, is kind of define the new jobs and the new requirements for those roles. A little bit. Yeah, very good. So we're here in Houston, gas energy is sort of the theme. Any thoughts about the impacts of going digital? We heard some pretty interesting things earlier today around, again, was it sub, looking under the ground? Subterranial data, so this whole new, subsurface, that's right, subsurface. Yeah, of course our shell folks would know. But yeah, I think there's gonna be some interesting evolutions we're seeing. I would never expect to see that new forum pop up but I can understand why it's there. Any thoughts around the gas and oil industry and the impacts of all going digital? Anything else? Yeah, maybe I can. Because I got to sit in on a lot of the process automation stuff the last, yesterday. And as I was listening to the open process automation forum and the discussions around it, OT isn't my thing, but IT is. I kind of looked at those worlds converging and we're using digital everywhere in the oil and gas space or we will be. So certainly looking at, from that perspective, I have, being from Canada, there's a lot of oil and gas in Canada. And some of the challenges I think that we face, at least in Canada, is the cost of the oil and gas getting it out of the ground. We have tariffs now, trade wars going on, all sorts of things that's driving the cost of pulling that out of the ground. So what I see is that those organizations need to find innovative ways of getting the oil out, selling the products, et cetera. And they really have to think of it from a business perspective, how they can use technology to be able to do that. And I think we've seen the pricing of oil going up and down continually. One of the other things, and I made the comment before, in working with oil and gas in Canada, they are extremely siloed when it comes to their organization and even from the IT perspective. And one of the things that they should be looking at, but they're really not driving towards, is a lot of the automation. I heard about the concept yesterday about the maintenance of a lot of the assets that are involved in the whole process. A lot of these things that can be automated, even to the point where automated failover of devices, et cetera, a lot of these are controlled now through, as they add, smarts into these devices and assets can be controlled. And also can be made more reliable and start to reduce the amount of manpower involved with it. So I think there's a tremendous amount of savings and business drivers of using technology and oil and gas. And I can see it as the whole open process automation part becomes more. Kind of converges with the IT. Exactly. That's a good point. And I know not everybody on the stage has the gas and oil experience. And Lars, you've had some telecom, some deep telecom experience there. What do you say? Well, the telecom experience was also that they were really slow in uptake on automation and in general making the digital business truly efficient until there were disruptors coming in, Skype being the classical example, but there was others coming along, right? And I guess it's the same in oil and gas. It's to really get a fundamental shift in how you think and how you operate. You need to look at what are the disruptors coming in. And obviously one of them in that sector is, well, the other kind of energy sources. So I come from Denmark, 100% of our electricity is from wind on a good day. And electricity prices gets negative and stuff like that. And it's a completely different industry that has popped up that is very digital actually in how you operate windmill parks and stuff like that. And that gives another pressure into the energy business. I do think there is another thing happening and that could be a disruptor which is coming from the perspective of traditionally energy has been a very physical business. So it's people and trucks and pipelines and stuff like that. But as it gets digitalized, everything is controlled, everything is networked, et cetera. The threat model, how do you disrupt the business is certainly something that can happen from North Korea or whatever. And there is a disaster waiting to happen. I'm pretty sure that it isn't good enough what we're doing and something will happen. And then there will be a shift going on. Unfortunately, I think we need to learn the hard way typically on this, but it's bound to happen in the oil and gas in my view. Agreed, agreed. How about your industry? Yeah, I've talked already about insurance, but I'll talk a little bit from my background at Proctoring Ambul about consumer packaged goods and retail. Both of those industries have been fundamentally transformed by digital and you can look at retail with Amazon, how it's completely flipped the entire model. But in the packaged goods space, I'll use the example of Dollar Shave Club. Gillette, if you're not familiar with Dollar Shave Club, Gillette, it was, at least in the US, the number one brand in the razor business with something like, I wanna say it was like 75 or 80% market share. Just incredibly unheard of from a standpoint of dominating a single line of business. Well, this little company that was basically out of somebody's garage started selling subscriptions for razors over the internet and eventually was bought by Unilever for, I don't know what it was, but it was some astronomical figure after taking a massive chunk out of that Gillette business.  And that's an example of how digital enterprises are impacting things around the world. I think you can't go anywhere anymore and not notice some sort of disruption, right? Transformation, transportation, there's even rockets, right, that guide themselves back to Earth, which was unheard of a couple of years ago. It's also just to add something that Mike had said about Amazon. We all remember Amazon starting off and buying books and then compute. And then I'm watching yesterday, I think it was a presentation about the electric grid deregulation and I'm going, okay, at what point it would be able to buy electricity from Amazon? Well, in Texas, we can buy our electricity from any source, actually, because we are, the market's opened up. So I don't know, anybody else here in Texas? Ah, you know what I'm talking about. So yeah, you can sign up for your own provider and there's different suppliers. Actually, in Denmark, we can do that as well. We are very happy that both Google, Facebook, and I don't know, Amazon, but Apple plays data centers in little small Denmark. But yes, we can sell them a lot of energy, but they bought it in Norway because it's an open market as well. So I think that idea of open market and really that supply chain optimization is kind of ruling the roost here and it comes from just getting a ride to the airport or getting a product at your door. Well, and it's interesting because it's no longer just digital disruption, but it's actually now the fear of disruption is fundamentally impacting markets. A real life example that's only a couple months old, Amazon announced that they were, I think it was with Berkshire Hathaway and Atna maybe, going to take a look at rethinking health insurance. And I believe in the next couple of days, the market basically took 20% out of every other healthcare provider that was publicly traded because of that fear of disruption. And so digital is even just the thought of it is having an impact. Yeah, you can't stay still anymore. There's no room for staying still and waiting for things to happen. They won't happen. So I think we're at time, we only have about 10 minutes left. I wanted to ask to see if anybody from the audience has a question for the panel. Don, you've got to have questions. Turn it on for us in the back. Thank you very much. You want to say your name and company? My name is Wout Lost from Hint. I have a question related to process automation. There's a lot of data coming from sensors and all those data is going into data historian, but it's all unvalidated. What are your thoughts about dealing with those kinds of data? So it's not a, it's not a simple silver bullet to solve it. There's a lot of experimentation going on. I think there's two things that we see. One being that there's a need for a platform and platform is more than just a database. It's really a platform that allows you to collect, normalize, enrich and then explore the data and then act on it. And if you need to build all of that yourself in order to get your business goals out of it, it's gonna take too long. So having such a platform and being able to buy that or consume it from the cloud is gonna be important. The other thing is the, and Don, my good colleague and friend, would talk at length on this is the latency thing. We just had a discussion yesterday. You can't necessarily expect that you would put all the data from all of these things into the cloud because you need to react faster. There's too much data. So you will have much more distributed compute and storage at the edge. And that's a new model. We're not used to managing that. So it'll create an enormous management challenge to get to that point. Yeah, and when you say at the edge, you mean where it's produced, basically? Correct. Yeah. So as we think about all of the sensors and what they're producing data, one of the things that we did within my technology innovation team was we actually looked at utilizing some of the advanced technologies that we had to create new ways of visualizing the data. So for a real specific example, what we did, we took the telematics data that was coming off of the vehicles. And typically when we get that data from our telematics providers, we get 100,000 columns and a couple million rows worth of data about all of the various trips that your car would go on. And historically what we'd done was we would try to put together some graphs and things to show this. Well, what my team did was we actually took that data and created what we called trip replay. Basically, we were able to emulate the trip and show you on a map your trip as it happened.  We showed you what the weather was and we were able to help you visualize in a different way what really happened in that trip. And it was interesting because that gave a human being who had a completely different mental model around what shouldn't, shouldn't happen a different way to look at and evaluate the data. And so I think as we look at all the data coming off of the sensors and all of the different use cases, I think we have to be creative and think of different ways to visualize and be able to comprehend that data as human beings because I think that's gonna how we're gonna gain really truly unique insight from it. Insight's the key. Any other questions, yes? Wait, for me. We got a mic. What I heard from Johann who gave the presentation from Schell, he said that you needed to separate the data from the application. He also made it very, very crystal clear you have to add the metadata to it before you get it into this neutral central repository of some nature. Call it a data lake if you want to, but you need to add the metadata to it. And that's I think key to everybody. Separate the data from the application and get, add the metadata so that any application that needs that data is able to use that data and generate new data, which obviously is the reason you would extract the data is to generate something new. But then when that new data gets created, it goes into the repository with additional metadata so that you know what that new data is. And that's, I think that's key for everybody. Yeah, and it's always been key, right? I think, you know, if you see ones and zeros, you don't know why they're there. You can't do anything with it. Linda, I think there's one in the back, Linda. Way in the back. You're going to make Linda work for this one. Yes, you made a comment earlier about the President of the United States being a contract worker or something like that. That made me think because I talked to a lot of the petroleum refineries here in Houston regarding cybersecurity and cyberterrorism on their chemical plants, but they're all using windows. So when I tell them, how can you be secure using windows, why don't you just download open source Linux, reconfigure it, put all the patches in where you know it is, and say, well, we're not in the IT business. We're in the oil business. And so I think they should be more in the IT business because they're responsible, as you were saying, right? How can we get there? I think we're moving away from there. So, it's a good observation and it sort of confirms my suspicion about what is going on. Unfortunately, I think you need to have a disaster before you really get people to change their mindset. But there is an aspect and that goes back to saying, well, there is an IT department within that organization. There is a CIO and a risk officer of some sort. So they should think about these kind of things. And IT needs to make it easier. It isn't necessarily easier to download the open source Linux and get it running because somebody had invested something in a closed platform and then you need to recompile all of that before you can actually get it secured. But IT needs to be that equivalent to the financial officers that really takes responsibility. And I think you said it also, Michael, earlier. You got to change the mindset. You're a technology company that's getting oil out of the ground and transforming it to something that you can consume. I think that's where the digital business flip kind of comes into play in my mind. Yeah, coming back to the role of IT in enterprise. So our observation, we hear from a lot many companies. The technology and IT spending of every enterprise is going up and up. But CIO budget is going down and down. So how do you explain this or interpret this contradiction? Anybody want to take a shot at that, yeah? Everything goes in waves and there is a degree of saying who has the responsibility for the budget is not the same as who has responsibility for the rules and regulations of what is going on. But eventually technology will consume the business and be the entire expenditure you have anyway. Anybody else? Well, I guess I had mentioned it before, but if that, and I've seen that exact case as Lars pointed out, I think IT's got a simplified process have to look at more automation and can look at the reduction in costs. I don't think they look at it. I don't think, I think just through the changes that can happen from organizationally and to a different model of service delivery, if think about them bringing IT, bringing more to the table and innovation and again getting away from the cost center that Lars had mentioned. I think they can drive cost out of running IT and they can also drive innovation that will bring more into the business. I don't think, and visiting a lot of different organizations, enough organizations map what IT is doing to the business and saying, what are my business goals? What are my business initiatives? If I wanna increase my profit by 10% or my margin by X or whatever else, how can I use technology to do that and then map the services that IT is delivering to that? I think that's where you can start to look at saying, okay, I have a shrinking budget but I'm driving innovation, I'm driving bottom line to the business. Yeah, and I think a lot of it's becoming, being transparent, I was showing basically what's where the money's going. I think a lot of organizations can't do that very well and it becomes a bit of a back black box so they create the alienation and they can create their own grave basically as a result. Yeah, I would build on that just a little bit. I think the bar is higher than it's ever been before and I think that's why the spend is shifting. The chief digital officer can go out and swipe his or her credit card and have IT and if they wanna go to the IT shop within their organization, they probably have to talk to a business relationship manager who's going to work through the portfolio management process to approve the budget who's then gonna bring in a business analyst who's then gonna gather all the requirements, who's then gonna talk to a project managers, then gonna go get a developer to go build it out after they work with their architect who's blah, blah, blah, right? So for them, it's okay, I can swipe my credit card or I can go spend the next six months talking to IT to figure out how to do the same thing and so they swipe their credit card. And it's endless. Yeah, so I have an example of a service provider in the medical industry in Denmark that we work with and they were originally an internal IT department and had all of these problems. They were split out as a separate organization needed to compete with the Amazon and they compute, I can't remember the exact number, maybe a factor five more expensive to get a server within that service provider than in Amazon but they realized, well, they need to explain, not to make it cheaper, but explain why it was five times more expensive. It was five times more expensive because it was a compliant server. And so it's a backed up, it was following all the change processes that FDA requires, et cetera. And so, okay, if you only just want a server, swipe the card and get going, that's efficient. They don't want to compete with Amazon on that. But if you want all of these things with it, then you can take it here, but they also put it in the catalog so you can get it within, if not an hour, then a day and not three months because that was needed in order to compete. So there's a lot about making it explicit what is the value you're bringing with your services which implies you need to think about services and not about technology. And that's a big shift for IT and the ones that can't shift, they're gonna be relevant eventually. And we have to think about seamless service delivery. Absolutely, there you go. Exactly. All right, I think we're a little past our time now. I wanted to thank the panelists here, John, Michael and Lars. Thank you. And excellent questions also from the audience. Thank you very much. Thanks, Mark.


In the battle dress, the NCO wears boots, he always has, well, almost. Many soldiers at Valley Forge did not have shoes, much less boots. They marched and fought with no more than rags that were wrapped around bleeding, frostbitten feet. Those volunteers literally knew the meaning of a come as you are war. From the crude rough and soiled moccasins worn by soldiers more than 225 years ago to the smooth and polished jump boots to the tansway boots of today boots have been basic to soldiering. Whether strapped, laced, buttoned, buckled or wrapped by leggings boots have marched, paced, sloshed, trampled, jumped and charged over or threw dirt, mud, snow, brush, rock, sand and water. In peace and war, the boots of the American soldier left their prints in many places. From Yorktown, Littlebighorn, Shiloh, San Juan Hill, Luzon, Cantigny, Koblenz, Omaha Beach, Iwo Jima, Kaison, St. George's, Sinai, Yander, Panama City and Kuwait City to name just a few. With boots on, U.S. soldiers have fought wars. Police cities stood between hostile forces, provided humanitarian relief, rescued civilians and died. Boots have been buried with soldiers, removed from bodies, amputated along with legs and shattered by mines. No matter where, when or what the mission, an Army non-commissioned officer was there wearing boots.