NDC Oslo 2013 - Lightning talks 3
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Rusbatch, Justin
Kvalheim, Christian Amor
Mustafina, Katya
Tørresdal, Jon Arild
Bjartnes, Bjørn Einar
Talk 1: ScriptCS - Justin Rusbatch Talk 2: Making node.js behave synchronously - Christian Amor Kvalheim Talk 3: From program to platform: mindset to develop public API - Katya Mustafina Talk 4: Enable Continuous Delivery for your Web/Server apps in 10 min - Jon Arild Tørresdal Talk 5: The Enterprise Clown builds SP2013 apps with node.js - Bjørn Einar Bjartnes
 All right. Thanks for coming. My name is Justin Russpatch. I am the author of Compilify.net, an online IDE for C-Sharp. It lets you actually evaluate code from your browser. And together with Glenn Block and Philip Bogeshin, I am a coordinator for the ScriptCS project. So if you're probably like me, you have a folder somewhere on your computer that looks a bit like that, either from console apps that you spun up to explore an idea or a console app that you wrote to schedule as a recurring task or something, for whatever reason, you ended up with a folder that looks like this. Up until now, there really hasn't been a good way to do any of those things without creating a brand new solution in Visual Studio. The problem with creating a new solution in Visual Studio is that you're creating 15 new files every time you go to a new solution, 15 new files in seven different directories on your hard drive. And you're waiting who knows how long for Visual Studio to just open and create the solution for you. So that's one of the reasons that Glenn Block came up with an idea called ScriptCS. And what ScriptCS is a lightweight scripting experience for C-Sharp. It's based on the Roslin compiler and inspired by Node so that you can write simplified C-Sharp in just simple text file with any editor, your favorite editor even. What we do is wrap this Roslin compiler and provide a hostable scripting environment that you can execute from your command line or include in your own application to run C-Sharp script. The C-Sharp script is a little bit different than regular C-Sharp. Roslin goes through a lot of processes to make sure that you don't need to write as much code as you would typically write in a regular C-Sharp application. For instance, name spaces and classes, top level classes, are just optional. You can write them if you want to, but you could also write a top level function, regular C-Sharp statements just in the global scope. We also go a step further and provide some new integration that allows you to reference Nougat packages from your script, install Nougat packages for your script to use, and restore Nougat packages from a packages.config file that Nougat would create for any other solution that you have package restore enabled for. Like I said, this was inspired by Node, so we kind of see a parallel between script C-S being Node and Nougat being kind of at the NPM. Glenn really wanted to create a very parallel experience. He got tired of the Visual Studio, molasses that you have to wade through, when you just want to do simple things. This is going to be a typical example of a script. Like I said, the scripting syntax is a little bit more relaxed than what you would be used to in a regular Visual Studio C-Sharp file. Scripts use a CSX extension for one. And you can see I only have four files in this directory, three of which are code, one of which is the packages config, which lists my dependencies. Instead of the 15 files that I said Visual Studio would create for you, so that right there is a lot less of a headache. There are a few other things that Roslyn adds to C-Sharp that help you get started. And one of them is a load extension, which allows you to reference additional C-Sharp scripts and divide your script or application or whatever into multiple files. Another, which is not shown here, is a pre-processor, just a letter R, is hashtag R. And that allows you to reference assemblies or DLLs that you've already built in Visual Studio. So using this scripting experience, you're able to actually reference things that you might already have laying around. So it really helps with that. As you can see, there are no top level namespaces, no need for classes or anything. What this is doing is actually spinning up a new web API host to listen on port 8080. I'm not sure how many of you are familiar with web API, but it's a simple, self-hosted server that doesn't require IIS. And it just listens on the port that you specify. And it's setting up the default route. It actually goes through a few additional steps that we need to jump through to host web API from a script. We need to write a custom script controller resolver, because web API doesn't pick up controllers and dynamic assemblies. But other than that, it's very standard web API code. We also offer an extensibility point, actually, called script packs. And what they are are new, get distributed assemblies that allow you to kind of set up your environment for your scripts. The goal of ScriptCS is to illuminate as much boilerplate code as possible. To reduce the number of lines you need to write to have a working application as few as possible. Unfortunately, not all the lines that are boilerplate are related directly to C-sharp. We eliminate as much of those as we could with the relaxed scripted syntax. But there's also things related to individual frameworks that are framework specific that you need to wade through. Web API was a great example, because you needed to set up the default routes, which almost never changed. You needed to specify the URL and include additional using statements. So what we did was we created this concept of script packs that allow you to reference additional assemblies for you and add additional using statements and expose functionality in a way that's very similar to the require statement in Node. We expose a global function called require when you call require type of script pack. And it'll add all of these things that you would otherwise need to write. So again, this is the same script that I just showed you. Not using a script pack. But what we did was we set up an example script pack for Web API. And it reduced all the code that we needed to write to that. We took the using statements out. The script pack takes care of that for us. We dropped a bunch of the boilerplate. We don't need to set up the custom controller resolve or any more. The script pack takes care of that for us and registers it with the configuration. And all we need to do is pass in a string to a method called create server. Now you'll see the require method being used there. And the script pack author, what they can do is they decide what's returned by that method. And then any function that they choose to expose on the object that they return, we expose to you. So if they wanted to simplify how you create a server, you can't get much simpler than that for Web API. But if there were some steps that you would need to go through with another framework, you could reduce it to a few helper methods on this object that's returned. So it saves a ton of time. And we're still looking for ways to reduce the number of lines of code that you need to write. But for Web API, it doesn't get much simpler than this. We have already got several script packs being written by several authors of many popular frameworks, including Nancy. We have a WPF script pack, which is very impressive. It allows you to run XAML straight from a regular script. Service stack, Azure Media Services, and Azure Mobile services all have script packs. So how do you get script.cs? What are the steps involved? We install and distribute script.cs through Chocly. I'm not sure how many of you have heard of Chocly, but it is similar to apt-get for Windows. It installs applications through Nougat for your system to use, adds them to your path, and everything. So all you need to do is install Chocly and run the command C install or C script.cs. And we'll pull down the latest version for you from Nougat and throw it in your path. It's actually installed to your app data directory, so it's per user. And it's instantly available for you. Updating is just as simple. You simply run C update, script.cs, and you get the latest version automatically. Glenn had a really genius idea. Script.cs is open source, and we have gotten a ton of community activity since we started. So if you visit us on GitHub, there are a bunch of issues out there. If you have any suggestions, any issues when you're playing with it, we'd love to hear them as soon as possible. And it would definitely help us out. So thank you very much. My name's Justin Rustbatch. And Gait scripts are yours. Thank you. So I'm going to speak about just hacking OJS ugly, worstly, like, you know, ingloriously, to make it run synchronously without doing any fibers or core routines or anything like that. Who am I? I work for Tenjin, among the B. I live in Barcelona, although I'm born here, so I'm Norwegian as well. So why do we want to make Node.js actually behave in a very unglorified, synchronous way? It all started because we have a Mongo shell that comes with the database that's actually JavaScript, right? And that's actually, it used to be SpiderMonkey from Zilla together with a bunch of C++ code. And we changed the V8, like in the last couple of releases, and we started thinking about, like, is it feasible to actually just use Node.js? Because one thing you can do with Node.js is actually you can package up your own custom Node.js distribution as a single binary. But to do that, we kind of had to get around a couple of problems. And the banana code is one of them. The typical Node.js code will look something like this. I mean, as you're writing callbacks, and callbacks, and internal callbacks, you tend to end up in a big, nice banana. And dealing with this isn't really feasible for us, because our shell was synchronous from day one. So you could do something like db.test, test, which is a collection, insert, and do something like that. So I couldn't really do that easily in Node.js. And we needed to be backwards compatible. I can't release like a shell that just doesn't work like this anymore. And to get around that issue, there's a couple of possibilities out there. There's something called Node fibers, which are coroutines. It's using actually threads in the background. It doesn't compile on Windows. It barely works. But it's out there. But it's a hack. It's not actually supported well in the runtime itself. But it's based on the same thing that you know from C Sharp about futures. So you wrap something in a context. And then as long as you're in there, you have the typical wait kind of statements that lets you kind of fire off an asynchronous call and kind of put that coroutine into a sleep mode while something else happens in the event loop and then get back when there's actually some results back. So we wanted something very much simpler and having to avoid wrapping something in a fiber. So another possibility is something that's coming in ECMAScript 6. It's called Generators. And it introduces a concept of the yield keyword and generator functions. And this is kind of a language level feature. Most people who are discovering JavaScript now don't really realize that in probably about a year, there's going to be a massive shift in the way the language works. It's in Node.js under the secret harmony switch, which I can't even spell switch. But if you, for example, download Node.js 11.2 or higher and do slash-sharmony, you suddenly have access to all of these new features that are coming in older browsers sometime in the future. So they will all be in Node.js long before anything else. To play around with it, you run the harmony thing and then you do an npm install, which is the Node package manager of nice little library called Galaxy that will help you basically do it more simply. And code like with basically looks like that. You see this new kind of function declaration with a little star on it. That's a generator. You have a little keyword yield, which basically yields to the system. And then what you're getting is back is actually some sort of iterator. So as long as you're actually doing next, it will process the next kind of statement. And then it returns an object that returns the actual value and if it's done or if it's still executing. So you kind of keep stepping through the function until you actually are done. So it's not quite core routines like you have in C-sharp, but it's close enough. So I decided this wasn't going to work either. So I decided let's do something nasty instead. And let's make blocking calls. And let's make this only feasible for scripting and make it simple. So that means C++. And I'm going to go real quickly through this. But this is what a C++ code for an extension in node looks like. So actually it's a quite nice C++ because the Google guys really did a really good job on the way the whole library works for V8. But to be fairly simple, what we're doing is that we're creating a new function that wraps the function that we're going to call. And then what we're doing is that we're running what we call the event loop in Node.js a step at a time. So think about in your debugger and you run your code one step at a time. We're doing the same thing, but with the actual event loop. So we keep running that until there's actually a result back. And since we are wrapping the function that we want to call with our own function, we can evaluate that function and check if a variable has been set so there's a result back. Once that's done, we return results to the originating caller. So we're not calling back, we're actually just doing a normal return. Everything else that is behind that blocks basically. So what's the usage of this? It's fairly simple. You do a sync, require sync it. And then you take a function in Node.js, like the read directory function. And you do a sync, wrap FS, read there. It gives you back a function. And now you can do like wire.final.ms equals read there and then dot result. If it errors out, you get a dot error as well. So you can check out the actual error that comes back. And that lets you basically just script it simply and do console.log whatever like that. And it still works with another async calls. So if you interleave this with other calls that are doing things against other IO operations, like other IO operations. In this case, we're doing a setTimeout. And then we're basically going down here and we're doing the actual sync operation. You can see from the execution time that we're doing starting a sync block on Timeout, which is like right here. Here we're blocking, waiting for a second. And then we see there a synchronous call actually executes, the one we started up here in between. Because we're single stepping in this event loop, we're still letting other stuff run. And then we finish up and we exit. So what's the problems? UV run is a no-no in any extension. You should never call this. Things that don't work like HTTP parser, for example, is not thread safe. So if you try to do this in a web application and then put some load on it more than a single thread, you're going to like sync fault. So what's the simple? Use it for a script, don't ever use it for a web app. And to install it, just do npm install dash g sync it. And check out my document db talk tomorrow in roommate at 1.40. That's it. Are we college break away? Yeah. Shall I start? Yeah. Hi, everybody. I will be talking about the mindset to develop public API. I will not be showing any code, so it will not be that geeky talk as to previous talks. So I will introduce myself. My name is Kajtse Mostafina, and I'm a developer. I've developed software for 17 years in different companies and countries and roles. And the last six years I worked for Norway Technology Center, SNTC, where we develop software solutions for oil industry. And we develop here in Norway our flagship product called Petrel. And Petrel is a product for helping people find oil. And that is considered to be one of the largest software applications in the world, software packages in the world, and consists of thousands, because there's millions of lines of code, and developed by hundreds of developers. So we have customers all over the planet in Europe, South America, North America, and Asia, and all the continents. So we started developing Petrel here in Norway as an application. And a few years ago we have created an open API for that and made it extensible. And we called it an API Ocean. And that actually today hundreds of developers develop plug-in and extensions to Petrel and use it as a platform to develop their own applications and their own needs for that. And I've been working in Petrel as an application developer for some years. And today I'm working as an Ocean API developer. So I joined the group that has been developing API last year. And what is the difference when you develop an API and then you develop an application? I'll talk in the next few minutes. So API is no different. It is also code. And so all the principles on designing a good code also apply to API. The key difference here that is the API we develop for other developers. So there will be other people and other developers who will use it in their programs to make their own, solve their own needs and write their own programs. And so what are the principles to keep in mind when we develop an API? I will talk in the next few minutes. And the first rule is to keep it simple. And when we design an API, we should think about a simplest user that will use that API to get him started. Is it easy for him to get started? Is it easy for him to just write his first Hello World program? Is it easy for him just to do these needs without going into documentation, without a big learning curve? And if you have some advanced specific user, an expert who wants to write something specific, we should actually think carefully if that scenario fits to this scenario for the simple user. And if it doesn't just go for a special API for that user, because they're already in, they already know what they're talking about, and they don't need, they can invest some time in learning on how easy it is to do. So keeping it simple for simple user is essential in developing API. And we might not think about it when we are developing an application. We think about it to some degree, but an API is really important. What classes you use, how you name them, how you actually use them in applications. And the second issue is the stability promise. So it is a period that people handle much easier their changes in their interfaces, so functionalities than changing the API. For example, if you download an app from the iPhone app store, and I don't know the Spotify recently, and it has totally different interface, but if it is intuitive and if it is easy to understand, people handle it quite easily. If it is a little bit learning, that's fine for people generally, but it's so much different if they have to go and change their code. They have to do some work. Whatever you change in API, you have to actually, you force people to change their code. They might not have resources to do it. They might, they don't want to do it. And the stability promise is much bigger in API development. And we in Ocean have two years stability promise. So we actually declare that we may change things in two years after. That works in paper more or less, but in reality, people are still very much unhappy when they have to change things. So we very often never change it ever. So stability promise is a big deal in API development. Consistency. The frameworks we develop must be consistent. If it is, if one knows part of the framework and the part is used for that, it must, the one must be actually easy to understand the code and easy to guess what this code is doing by knowing the rest of the framework. And this is very important that people can resemble, can understand the code by analogy on that. Doing that, if there is some cool part and if there is some new technology to use, that we would like to use. But it's not consistent with the rest of the framework. We probably have to drop it. And this is unfortunate, but that is, consistency is a big deal when it comes in API development. And the last, but maybe the most important thing is just to use it. Just to make sure you can use it internally before you ship it to others. Because here is stability promise is not there yet. You can't change it still. And find the group that would be using it internally before you ship it. Maybe find someone, if you can't find it just making a workshop or maybe write a set of unit tests that would be used, the documentation to the API is important thing to do it. Because here we can change it. I know working in a project that consumers we have is, they sit next door to us. So we actually ship them new versions every day. So we can change things quickly and we can change things easily before actually stability promise came to change, came to station. We can actually ship it and then we can change it probably never. So we developed that framework based on those principles. And now we have like hundreds of plugins that people download and use and people write the plugins because they, for example, have some confidential property, confidential, intellectual property that they don't want to disclose to us. But they want to use our program as a platform. And today we don't even have a special team that actually develops an API. We actually gave all the teams who develop the functionality. They have to develop their own API and keep these things in mind. Thank you very much. We appreciate everyone in the audience for taking the time and showing us your works at the forum today. I've been davonished that everything onceae, essentially everwhen they button, they see you again. Could I get some tech help? I need mirroring displays. Come on, let's go. Doesn't react. I need mirroring. Can I get some mirroring? I'll try. All right, my name is Jund Telestal. I'll show you how to do continuous deployment in about 10 minutes. Here I say, I'm going to use two things. I'm going to use an open source project called Condep and then TeamCity. This is how you, I recommend you do continuous deployment on Windows. So here I have a simple web application that you've probably all seen before. I'll just try to run it. So you can see what I mean. I need to drag in that browser so you can see it. So this should be familiar to most people on.NET. Where's my arrow? Hello, there it is. All right, and I'm going to deploy this to a server in the cloud, which we also have on a different screen. Let me see. Sorry about this. Here's a server out at Amazon, which now has a default website with no content and has a folder somewhere which doesn't have any content. So I'm just going to create a new project, a new project. Class library, just going to call that deployment. Just renamed that class. We have some name for it. NDC web app. And in order to do Condep stuff, you need to have a library, namely Condep. And here I'm just going to use the beta version. And you get, so I have include pre-lease here. Hopefully I'm on wireless. There it is. Just install that. Post all the dependencies down. And we now have a domain specific language for doing deployment in C sharp. So what I'm going to do with this class is that I'm going to inherit from an abstract class called application artifact. And I'm going to implement a method called configure that sends into objects. I'm going to use the first one that's on local machine that gives me access to this DSL. So I'm going to do a deployment to a server now. So I'm going to say to each server takes an action. You can use that action. And I get out of deploy or execute. I'm going to deploy. And I'm going to deploy an IS web application. To just make this a bit quicker, I'm just going to copy some code. And I'm just going to explain what that is. So here I have a source directory that tells me where is the source for the application that we're going to deploy. Sorry? Yep. No worries. Is that enough? And the destination directory where the application is going to end up on a server. The web application name, which is the name in IS for the application. And the website which it should belong to. So that's the only two things I need. That's the only thing I need to define in order to deploy an IS application. But I only tell or define through the DSL what I'm going to do, not where I'm going to do it. So I need to add a configuration file. So I'm just going to add an existing one to make it a bit quicker. And this has the extension dev.end.json. So this is a configuration file for the dev environment. If I want to have something for test environment as well, it would typically be test.end.json. I'm just going to make sure that this is being copied when I built. So just do like that. And here I tell a condom which servers I'm going to deploy to. There's just one server, but it can be as many as you want. And which user are you going to use to authenticate with towards that server. We have a password in clear text, but that's going to be fixed. We need to encrypt that. But right now it's in clear text. So I'm just going to build this to see that it works. And then bring up my browser again. Not that one. So here's TeamCity. I've defined a project to build the web application to standard. The only difference between this one and the regular one would be that I've defined... I don't know if you can see this, but I've defined where the content of the build output for that project ending up in a build ship, which is the artifact for the build. I'm just going to make this a bit bigger. No? Okay. And then we need a separate project in TeamCity for actually doing the deployment. Just to make it easy, I'm just going to do this. I have a project here. I'm just going to walk quickly through the settings for this project. Actually, before that, I'll need to show you just a folder. So when I did build earlier... Fantastic. That ended up in the deployment project in a bin folder. You see that I have the DLL for my deployment project, but also a CondepXC, which was pulled in when I added the NuGet packages. This is the one we're going to use in order to actually execute the deployment. So just give the project a name. There's no version control settings because it just depends on the previous build. Define a command line, which is just a name for Condep.XC, the XC file that does the deployment. And you tell it which DLL does it find the deployment definition in. And then you point to the environment that you're going to use. And then you just use convention to figure out, well, dev.n.json is the JSON file I'm going to use to find the environment settings. And then the name of the class that we defined as the definition, which is the one we saw here, right? So that's it. So what we can do then is... So I basically now set up... Well, actually, there's one more thing. That's how you define the deployment. And then you want to have a continuous deployment. So add a trigger to say that, well, whenever the previous build project is successful, this one is going to kick off. And then you set up a few dependencies. Say I have a snapshot dependency on a previous project and an artifact dependency on the build zip file. And I just unzip that into a folder so I can use those files during execution. And that means that we now can go into Visual Studio and make a change to this project. Let's say we're going to do... Change the name here and just say something like that. Just to make a change. And I'm going to check that in to GitHub. Ups. Like that. Pissed us to GitHub. I mean, you can use whatever source control system you want connected to your CI. And if we go out here, CI should kick off this process. So I'm just going to help them a bit. So trigger it. And as soon as that's finished, it's going to automatically trigger the next one, which is the deployment. By the way, if you want to know more about Condep, I have a talk on this tomorrow at 1340. So drop by if you want to know more. And then suddenly this one's going to kick off. Usually takes a bit of time. Come on, you can do it. There it is. That kicks off. Look at the build log, what's going on. Executes Condep. Condep starts doing stuff on that. Promotes server in the cloud. I can't really much say about the details here now. I'll talk more about that tomorrow. If we go to the server and have a look at this folder, it should show up very soon a folder here called Web Apps that contain the application that is going to deploy. So it's just about to do the deployment now. So in 10 seconds. So that's Web Apps. And it's also a Web App. And if you look at the website, it's the website's there. And if we go to this one, do refresh. It's getting displayed. So that's how you do the continuous deployment. Hello, everyone. This is my first public appearance as a clown. By the looks I'm getting when I'm wandering, walking around the halls. It might be my last. We'll see. So I'm Bjorn Einar Bjartnes, developer in Kompitas. But today I'm here as the enterprise clown, my alter ego. And I just have to give a little bit of warning. There might be some rants in here. We'll see. So at some point, Bjorn, he took the red pill and he saw what was outside the enterprise world. And he saw what the cool kids were doing on GitHub. And he saw how lean software they built. He saw that with his own eyes. And he learned that the true battle is not the battle between Eclipse and Visual Studio. It's between Wim and Emax. He learned about the history of our industry, of which little is spoken in the enterprise. And his eyes seeing clearer every day, the way of the enterprise makes Bjorn really sad. And to stay sane, he sometimes lets his inner enterprise clown out as today. And the clown does stuff that does not really belong in the enterprise, but cunningly disguised as a clown, he gets away with it. And sometimes he even manages to put a smile on the depressed Bjorn's face. And the clown helps Bjorn stay sane while he dreams of better days for our industry. So the blue pill represents enterprise software of today, whereas the red pill represents what's out there, what's out there on the Internet. So I figured, let's eat the red and the blue pill and go on this purple trip. It might expand our consciousness. Let's build SharePoint apps in Node.js. So not to be too abstract. I'm just going to show you what we did at Hackathon, me and some friends. I'll have their names later. It was the Arctic SharePoint Challenge earlier this year. And so what we're seeing here is this multi-user real-time application on SharePoint. So you see we're using leap motion to drag and drop these tasks. You can control priority and completeness date and you can add new tasks. And you see how they're synchronized with the iPhone and the iPad using WebSockets across Atlantic in real time. It's not your typical SharePoint application, right? So Node.js has been mentioned before. The key thing I wanted to think of here, drop that JavaScript runtime thing, but it's a platform that's built to do scalable network applications. I'll come back to that. You're talking about SharePoint apps, right? Why are you suddenly talking about distributed network applications? We'll come back to that. That's really all we need to know. And the other part about leanness. And the NPM part was mentioned before, so I don't really have to go into that. But that's really core here, that we have like this really simple understandable core and you can pull in modules and build on those modules. And the Hipstru factory is also pretty good on Node.js. It's starting to fade off. I think it's close to Erlang and close to Closure, almost there. So that's a plus as well. Whereas this guy, SharePoint, has a Hipstru factory like Near Zero, maybe negative. And it's this big enterprise monolithic product. And we're doing this IDE driven development by Wizards. So we have this Wizards that leads us through and pretends to help us. And the cool thing about SharePoint though is that in 2013, Microsoft opened it up. They created their API. They call it a REST API. It's pretty REST, part of it is RESTful anyway, which allows you to connect with whatever web technology you like. So since I don't know Erlang, I've tried to do something with Node.js on it. So we all know this guy, right? He's a powerful wizard. He's a very good wizard. He helps you do stuff. He helps good people do good stuff. Then we have this wizard. He's an evil wizard. He blurs your vision. So you hardly can see what's going on. And I'm thinking, I'm trying as hard as I can, and I guess a lot of you are as well, to be good programmers. And then we get this Joe Sixpack IDE that Microsoft thinks is going to help us to build better stuff. This is their idea of DevOps, right? That you're supposed to choose your dev environment by a drop-down list, and press F5 and everything is going to be okay. Either they've solved DevOps with a drop-down, or it's the major leak abstraction that is going to ruin your project when you're going live. You might work for one guy and one machine doing dev stuff. If you're lucky, it's going to work in one instance when you deploy it. I'm not going to go into detail on this part. This just shows what you have to start to do manually when you're building a SharePoint app. You have the client. You have your SharePoint application here. You have SharePoint itself. And you have the Azure ACS, which gives you does all authorization and authentication and all of that stuff. So there's a lot of tokens flying around here that you need to understand in order to build this if you're doing it from scratch. All of this stuff, the wizard wants to hide from you, but sooner or later, you need to understand this anyway. So this is the architecture of a SharePoint, typical SharePoint application. So you have this is your SharePoint instance in the cloud. So these are all your clients that are connecting to SharePoint. Then you have ACS, that does the authorization part. Then you have your application. In my case, it was Node.js running on Node.jitsu just to really show it's decoupled. I'm building on Linux. I'm deploying on Linux and running on Node.jitsu. So it could have been Azure, but I'm trying to stay all enterprise clowny. You need to do it on non-Microsoft technology. And you might be using some Azure backend services as well. And this is where these distributed network applications come into play. Because in a real-time app, you have secure web sockets. You have HTTPS to multiple clients. Clients can talk directly to SharePoint, and SharePoint will talk. So everybody's talking to everyone here. And this is where this Node.js event loop model fits really well in. Not if you do it synchronously as shown before, but if you let Node do its job normally. So again, just a screenshot from how you can deploy stuff when you're running and building on a proper operating system. You have a proper shell that can deploy. You see the package, and you can run commands to deploy it wherever you want. And you have full control of what's going on, which is very, very nice if you're building applications that are supposed to work. So I'm going to a little bit more just to show you an example of how this looks like. So you see now we're on ByardWolf SharePoint.com. So this is a SharePoint instance in the cloud. And I can launch my application. So I'll launch my application, and all this authorization dance is going on. And we're on Node.jitsu. And we have cute cats on tasks. And you see, this looks very much like SharePoint. You can pull in all the Chrome. Everything is web-buried. I mean, you can do this. You would think this is a typical SharePoint application, but it's running on Node. So you can create new tasks. And when you create something, it's sent to SharePoint. And when you just drag stuff around for the real-time stuff, SharePoint doesn't even know about it. Your application is just relaying this to all authenticated clients. So we can go back to SharePoint to see our task is back here, and we can add that to the task list. So what do we get? We get this lightweight application, which is cheap to host. It's cheap to scale. It's possible to understand, which is very good. And you can leverage all these cool NPM modules. I want to give a few shout-outs to MacRotter at Qport. He made this passport strategy for Node. I stole everything from him. I'll scale your NARA, and I'd love if you're helping me build this thing in the Hackathon. Here's the code if you're interested. This code is Hackathon code. I wouldn't use it for anything serious. And if you're into building cool apps on SharePoint, but more for real, not as a clown, I would really recommend this next talk in Room 1 on building enterprise IPs to apps with SharePoint and JavaScript. So all I can say, dare to wear the foolish clown face, go out, experiment, have fun, enjoy the rest of the conference. Thanks. Thank you.
 All right.  Thanks for coming.  My name is Justin Russpatch.  I am the author of Compilify.net, an online IDE for C-Sharp.  It lets you actually evaluate code from your browser.  And together with Glenn Block and Philip Bogeshin,  I am a coordinator for the ScriptCS project.  So if you're probably like me, you  have a folder somewhere on your computer that  looks a bit like that, either from console apps  that you spun up to explore an idea or a console app  that you wrote to schedule as a recurring task or something,  for whatever reason, you ended up  with a folder that looks like this.  Up until now, there really hasn't been a good way  to do any of those things without creating a brand new  solution in Visual Studio.  The problem with creating a new solution in Visual Studio  is that you're creating 15 new files every time you go  to a new solution, 15 new files in seven different directories  on your hard drive.  And you're waiting who knows how long for Visual Studio  to just open and create the solution for you.  So that's one of the reasons that Glenn Block came up  with an idea called ScriptCS.  And what ScriptCS is a lightweight scripting  experience for C-Sharp.  It's based on the Roslin compiler and inspired by Node  so that you can write simplified C-Sharp in just  simple text file with any editor, your favorite editor  even.  What we do is wrap this Roslin compiler  and provide a hostable scripting environment  that you can execute from your command line  or include in your own application to run C-Sharp script.  The C-Sharp script is a little bit different than regular  C-Sharp.  Roslin goes through a lot of processes  to make sure that you don't need to write as much code as you  would typically write in a regular C-Sharp application.  For instance, name spaces and classes, top level classes,  are just optional.  You can write them if you want to,  but you could also write a top level function, regular C-Sharp  statements just in the global scope.  We also go a step further and provide some new integration  that allows you to reference Nougat packages from your script,  install Nougat packages for your script to use,  and restore Nougat packages from a packages.config file  that Nougat would create for any other solution  that you have package restore enabled for.  Like I said, this was inspired by Node,  so we kind of see a parallel between script C-S being Node  and Nougat being kind of at the NPM.  Glenn really wanted to create a very parallel experience.  He got tired of the Visual Studio,  molasses that you have to wade through,  when you just want to do simple things.  This is going to be a typical example of a script.  Like I said, the scripting syntax is a little bit more relaxed  than what you would be used to in a regular Visual Studio  C-Sharp file.  Scripts use a CSX extension for one.  And you can see I only have four files in this directory, three  of which are code, one of which is the packages config, which  lists my dependencies.  Instead of the 15 files that I said Visual Studio  would create for you, so that right there  is a lot less of a headache.  There are a few other things that Roslyn adds to C-Sharp  that help you get started.  And one of them is a load extension,  which allows you to reference additional C-Sharp scripts  and divide your script or application  or whatever into multiple files.  Another, which is not shown here, is a pre-processor,  just a letter R, is hashtag R. And that  allows you to reference assemblies or DLLs  that you've already built in Visual Studio.  So using this scripting experience,  you're able to actually reference things  that you might already have laying around.  So it really helps with that.  As you can see, there are no top level namespaces,  no need for classes or anything.  What this is doing is actually spinning up a new web API host  to listen on port 8080.  I'm not sure how many of you are familiar with web API,  but it's a simple, self-hosted server that  doesn't require IIS.  And it just listens on the port that you specify.  And it's setting up the default route.  It actually goes through a few additional steps  that we need to jump through to host web API from a script.  We need to write a custom script controller resolver,  because web API doesn't pick up controllers  and dynamic assemblies.  But other than that, it's very standard web API code.  We also offer an extensibility point, actually,  called script packs.  And what they are are new, get distributed assemblies  that allow you to kind of set up your environment  for your scripts.  The goal of ScriptCS is to illuminate as much boilerplate  code as possible.  To reduce the number of lines you need to write to have  a working application as few as possible.  Unfortunately, not all the lines that are boilerplate  are related directly to C-sharp.  We eliminate as much of those as we could with the relaxed  scripted syntax.  But there's also things related to individual frameworks  that are framework specific that you need to wade through.  Web API was a great example, because you  needed to set up the default routes, which almost never  changed.  You needed to specify the URL and include  additional using statements.  So what we did was we created this concept of script packs  that allow you to reference additional assemblies for you  and add additional using statements and expose  functionality in a way that's very similar  to the require statement in Node.  We expose a global function called require when you call  require type of script pack.  And it'll add all of these things that you would otherwise  need to write.  So again, this is the same script that I just showed you.  Not using a script pack.  But what we did was we set up an example script pack for  Web API.  And it reduced all the code that we needed to write to  that.  We took the using statements out.  The script pack takes care of that for us.  We dropped a bunch of the boilerplate.  We don't need to set up the custom controller resolve  or any more.  The script pack takes care of that for us and registers it  with the configuration.  And all we need to do is pass in a string to a method called  create server.  Now you'll see the require method being used there.  And the script pack author, what they can do is they  decide what's returned by that method.  And then any function that they choose to expose on the  object that they return, we expose to you.  So if they wanted to simplify how you create a server, you  can't get much simpler than that for Web API.  But if there were some steps that you would need to go  through with another framework, you could reduce it to a  few helper methods on this object that's returned.  So it saves a ton of time.  And we're still looking for ways to reduce the number of  lines of code that you need to write.  But for Web API, it doesn't get much simpler than this.  We have already got several script packs being written by  several authors of many popular frameworks, including  Nancy.  We have a WPF script pack, which is very impressive.  It allows you to run XAML straight from a regular  script.  Service stack, Azure Media Services, and Azure Mobile  services all have script packs.  So how do you get script.cs?  What are the steps involved?  We install and distribute script.cs through  Chocly.  I'm not sure how many of you have heard of Chocly, but it  is similar to apt-get for Windows.  It installs applications through Nougat for your system to  use, adds them to your path, and everything.  So all you need to do is install Chocly and run the  command C install or C script.cs.  And we'll pull down the latest version for you from Nougat  and throw it in your path.  It's actually installed to your app data directory, so it's  per user.  And it's instantly available for you.  Updating is just as simple.  You simply run C update, script.cs, and you get the  latest version automatically.  Glenn had a really genius idea.  Script.cs is open source, and we have gotten a ton of  community activity since we started.  So if you visit us on GitHub, there are a bunch of issues  out there.  If you have any suggestions, any issues when you're playing  with it, we'd love to hear them as soon as possible.  And it would definitely help us out.  So thank you very much.  My name's Justin Rustbatch.  And Gait scripts are yours.  Thank you.  So I'm going to speak about just hacking OJS  ugly, worstly, like, you know, ingloriously, to make it run  synchronously without doing any fibers or core routines or  anything like that.  Who am I?  I work for Tenjin, among the B. I live in Barcelona, although  I'm born here, so I'm Norwegian as well.  So why do we want to make Node.js actually behave in a  very unglorified, synchronous way?  It all started because we have a Mongo shell that comes with  the database that's actually JavaScript, right?  And that's actually, it used to be SpiderMonkey from  Zilla together with a bunch of C++ code.  And we changed the V8, like in the last couple of releases,  and we started thinking about, like, is it feasible to  actually just use Node.js?  Because one thing you can do with Node.js is actually you  can package up your own custom Node.js distribution as a  single binary.  But to do that, we kind of had to get around a couple of  problems.  And the banana code is one of them.  The typical Node.js code will look something like this.  I mean, as you're writing callbacks, and callbacks, and  internal callbacks, you tend to end up in a big, nice banana.  And dealing with this isn't really feasible for us,  because our shell was synchronous from day one.  So you could do something like db.test, test, which is a  collection, insert, and do something like that.  So I couldn't really do that easily in Node.js.  And we needed to be backwards compatible.  I can't release like a shell that just doesn't work like  this anymore.  And to get around that issue, there's a couple of  possibilities out there.  There's something called Node fibers, which are coroutines.  It's using actually threads in the background.  It doesn't compile on Windows.  It barely works.  But it's out there.  But it's a hack.  It's not actually supported well in the runtime itself.  But it's based on the same thing that you know from C  Sharp about futures.  So you wrap something in a context.  And then as long as you're in there, you have the typical  wait kind of statements that lets you kind of fire off an  asynchronous call and kind of put that coroutine into a sleep  mode while something else happens in the event loop and  then get back when there's actually some results back.  So we wanted something very much simpler and having to  avoid wrapping something in a fiber.  So another possibility is something that's coming in  ECMAScript 6.  It's called Generators.  And it introduces a concept of the yield keyword and  generator functions.  And this is kind of a language level feature.  Most people who are discovering JavaScript now don't  really realize that in probably about a year, there's going to  be a massive shift in the way the language works.  It's in Node.js under the secret harmony switch, which I  can't even spell switch.  But if you, for example, download Node.js 11.2 or  higher and do slash-sharmony, you suddenly have access to all  of these new features that are coming in older browsers  sometime in the future.  So they will all be in Node.js long before anything else.  To play around with it, you run the harmony thing and then  you do an npm install, which is the Node package manager of  nice little library called Galaxy that will help you  basically do it more simply.  And code like with basically looks like that.  You see this new kind of function declaration with a  little star on it.  That's a generator.  You have a little keyword yield, which basically yields to  the system.  And then what you're getting is back is actually some sort of  iterator.  So as long as you're actually doing next, it will process  the next kind of statement.  And then it returns an object that returns the actual  value and if it's done or if it's still executing.  So you kind of keep stepping through the function until  you actually are done.  So it's not quite core routines like you have in C-sharp,  but it's close enough.  So I decided this wasn't going to work either.  So I decided let's do something nasty instead.  And let's make blocking calls.  And let's make this only feasible for scripting and  make it simple.  So that means C++.  And I'm going to go real quickly through this.  But this is what a C++ code for an extension in node looks  like.  So actually it's a quite nice C++ because the Google guys  really did a really good job on the way the whole library  works for V8.  But to be fairly simple, what we're doing is that we're  creating a new function that wraps the function that we're  going to call.  And then what we're doing is that we're running what we  call the event loop in Node.js a step at a time.  So think about in your debugger and you run your code one  step at a time.  We're doing the same thing, but with the actual event loop.  So we keep running that until there's actually a result  back.  And since we are wrapping the function that we want to call  with our own function, we can evaluate that function and  check if a variable has been set so there's a result back.  Once that's done, we return results to the  originating caller.  So we're not calling back, we're actually just doing a  normal return.  Everything else that is behind that blocks basically.  So what's the usage of this?  It's fairly simple.  You do a sync, require sync it.  And then you take a function in Node.js, like the read  directory function.  And you do a sync, wrap FS, read there.  It gives you back a function.  And now you can do like wire.final.ms equals read  there and then dot result.  If it errors out, you get a dot error as well.  So you can check out the actual error that comes back.  And that lets you basically just script it simply and do  console.log whatever like that.  And it still works with another async calls.  So if you interleave this with other calls that are doing  things against other IO operations, like other IO  operations.  In this case, we're doing a setTimeout.  And then we're basically going down here and we're doing the  actual sync operation.  You can see from the execution time that we're doing  starting a sync block on Timeout, which is like right  here.  Here we're blocking, waiting for a second.  And then we see there a synchronous call actually  executes, the one we started up here in between.  Because we're single stepping in this event loop, we're still  letting other stuff run.  And then we finish up and we exit.  So what's the problems?  UV run is a no-no in any extension.  You should never call this.  Things that don't work like HTTP parser, for example, is  not thread safe.  So if you try to do this in a web application and then put  some load on it more than a single thread, you're going to  like sync fault.  So what's the simple?  Use it for a script, don't ever use it for a web app.  And to install it, just do npm install dash g sync it.  And check out my document db talk tomorrow in  roommate at 1.40.  That's it.  Are we college break away?  Yeah.  Shall I start?  Yeah.  Hi, everybody.  I will be talking about the mindset to develop public API.  I will not be showing any code, so it will not be that geeky talk as to previous talks.  So I will introduce myself.  My name is Kajtse Mostafina, and I'm a developer.  I've developed software for 17 years in different companies and countries and roles.  And the last six years I worked for Norway Technology Center, SNTC, where we develop  software solutions for oil industry.  And we develop here in Norway our flagship product called Petrel.  And Petrel is a product for helping people find oil.  And that is considered to be one of the largest software applications in the world, software  packages in the world, and consists of thousands, because there's millions of lines of code,  and developed by hundreds of developers.  So we have customers all over the planet in Europe, South America, North America, and  Asia, and all the continents.  So we started developing Petrel here in Norway as an application.  And a few years ago we have created an open API for that and made it extensible.  And we called it an API Ocean.  And that actually today hundreds of developers develop plug-in and extensions to Petrel and  use it as a platform to develop their own applications and their own needs for that.  And I've been working in Petrel as an application developer for some years.  And today I'm working as an Ocean API developer.  So I joined the group that has been developing API last year.  And what is the difference when you develop an API and then you develop an application?  I'll talk in the next few minutes.  So API is no different.  It is also code.  And so all the principles on designing a good code also apply to API.  The key difference here that is the API we develop for other developers.  So there will be other people and other developers who will use it in their programs to make  their own, solve their own needs and write their own programs.  And so what are the principles to keep in mind when we develop an API?  I will talk in the next few minutes.  And the first rule is to keep it simple.  And when we design an API, we should think about a simplest user that will use that API  to get him started.  Is it easy for him to get started?  Is it easy for him to just write his first Hello World program?  Is it easy for him just to do these needs without going into documentation, without  a big learning curve?  And if you have some advanced specific user, an expert who wants to write something specific,  we should actually think carefully if that scenario fits to this scenario for the simple  user.  And if it doesn't just go for a special API for that user, because they're already in,  they already know what they're talking about, and they don't need, they can invest some  time in learning on how easy it is to do.  So keeping it simple for simple user is essential in developing API.  And we might not think about it when we are developing an application.  We think about it to some degree, but an API is really important.  What classes you use, how you name them, how you actually use them in applications.  And the second issue is the stability promise.  So it is a period that people handle much easier their changes in their interfaces, so functionalities  than changing the API.  For example, if you download an app from the iPhone app store, and I don't know the Spotify  recently, and it has totally different interface, but if it is intuitive and if it is easy to  understand, people handle it quite easily.  If it is a little bit learning, that's fine for people generally, but it's so much different  if they have to go and change their code.  They have to do some work.  Whatever you change in API, you have to actually, you force people to change their code.  They might not have resources to do it.  They might, they don't want to do it.  And the stability promise is much bigger in API development.  And we in Ocean have two years stability promise.  So we actually declare that we may change things in two years after.  That works in paper more or less, but in reality, people are still very much unhappy when they  have to change things.  So we very often never change it ever.  So stability promise is a big deal in API development.  Consistency.  The frameworks we develop must be consistent.  If it is, if one knows part of the framework and the part is used for that, it must, the  one must be actually easy to understand the code and easy to guess what this code is doing  by knowing the rest of the framework.  And this is very important that people can resemble, can understand the code by analogy  on that.  Doing that, if there is some cool part and if there is some new technology to use, that  we would like to use.  But it's not consistent with the rest of the framework.  We probably have to drop it.  And this is unfortunate, but that is, consistency is a big deal when it comes in API development.  And the last, but maybe the most important thing is just to use it.  Just to make sure you can use it internally before you ship it to others.  Because here is stability promise is not there yet.  You can't change it still.  And find the group that would be using it internally before you ship it.  Maybe find someone, if you can't find it just making a workshop or maybe write a set of  unit tests that would be used, the documentation to the API is important thing to do it.  Because here we can change it.  I know working in a project that consumers we have is, they sit next door to us.  So we actually ship them new versions every day.  So we can change things quickly and we can change things easily before actually stability  promise came to change, came to station.  We can actually ship it and then we can change it probably never.  So we developed that framework based on those principles.  And now we have like hundreds of plugins that people download and use and people write the  plugins because they, for example, have some confidential property, confidential, intellectual  property that they don't want to disclose to us.  But they want to use our program as a platform.  And today we don't even have a special team that actually develops an API.  We actually gave all the teams who develop the functionality.  They have to develop their own API and keep these things in mind.  Thank you very much.  We appreciate everyone in the audience for taking the time and showing us your works at  the forum today.  I've been davonished that everything onceae, essentially everwhen they button, they see  you again.  Could I get some tech help?  I need mirroring displays.  Come on, let's go.  Doesn't react.  I need mirroring.  Can I get some mirroring?  I'll try.  All right, my name is Jund Telestal. I'll show you how to do continuous deployment in about 10 minutes.  Here I say, I'm going to use two things. I'm going to use an open source project called Condep and then TeamCity.  This is how you, I recommend you do continuous deployment on Windows.  So here I have a simple web application that you've probably all seen before.  I'll just try to run it.  So you can see what I mean.  I need to drag in that browser so you can see it.  So this should be familiar to most people on.NET.  Where's my arrow?  Hello, there it is.  All right, and I'm going to deploy this to a server in the cloud,  which we also have on a different screen.  Let me see.  Sorry about this.  Here's a server out at Amazon, which now has a default website with no content and has a folder somewhere which doesn't have any content.  So I'm just going to create a new project, a new project.  Class library, just going to call that deployment.  Just renamed that class.  We have some name for it.  NDC web app.  And in order to do Condep stuff, you need to have a library, namely Condep.  And here I'm just going to use the beta version.  And you get, so I have include pre-lease here.  Hopefully I'm on wireless.  There it is.  Just install that.  Post all the dependencies down.  And we now have a domain specific language for doing deployment in C sharp.  So what I'm going to do with this class is that I'm going to inherit from an abstract class called application artifact.  And I'm going to implement a method called configure that sends into objects.  I'm going to use the first one that's on local machine that gives me access to this DSL.  So I'm going to do a deployment to a server now.  So I'm going to say to each server takes an action.  You can use that action.  And I get out of deploy or execute.  I'm going to deploy.  And I'm going to deploy an IS web application.  To just make this a bit quicker, I'm just going to copy some code.  And I'm just going to explain what that is.  So here I have a source directory that tells me where is the source for the application that we're going to deploy.  Sorry?  Yep.  No worries.  Is that enough?  And the destination directory where the application is going to end up on a server.  The web application name, which is the name in IS for the application.  And the website which it should belong to.  So that's the only two things I need.  That's the only thing I need to define in order to deploy an IS application.  But I only tell or define through the DSL what I'm going to do, not where I'm going to do it.  So I need to add a configuration file.  So I'm just going to add an existing one to make it a bit quicker.  And this has the extension dev.end.json.  So this is a configuration file for the dev environment.  If I want to have something for test environment as well, it would typically be test.end.json.  I'm just going to make sure that this is being copied when I built.  So just do like that.  And here I tell a condom which servers I'm going to deploy to.  There's just one server, but it can be as many as you want.  And which user are you going to use to authenticate with towards that server.  We have a password in clear text, but that's going to be fixed.  We need to encrypt that.  But right now it's in clear text.  So I'm just going to build this to see that it works.  And then bring up my browser again.  Not that one.  So here's TeamCity.  I've defined a project to build the web application to standard.  The only difference between this one and the regular one would be that I've defined...  I don't know if you can see this, but I've defined where the content of the build output for that project  ending up in a build ship, which is the artifact for the build.  I'm just going to make this a bit bigger.  No? Okay.  And then we need a separate project in TeamCity for actually doing the deployment.  Just to make it easy, I'm just going to do this.  I have a project here.  I'm just going to walk quickly through the settings for this project.  Actually, before that, I'll need to show you just a folder.  So when I did build earlier...  Fantastic.  That ended up in the deployment project in a bin folder.  You see that I have the DLL for my deployment project, but also a CondepXC,  which was pulled in when I added the NuGet packages.  This is the one we're going to use in order to actually execute the deployment.  So just give the project a name.  There's no version control settings because it just depends on the previous build.  Define a command line, which is just a name for Condep.XC, the XC file that does the deployment.  And you tell it which DLL does it find the deployment definition in.  And then you point to the environment that you're going to use.  And then you just use convention to figure out, well, dev.n.json is the JSON file I'm going to use  to find the environment settings.  And then the name of the class that we defined as the definition,  which is the one we saw here, right?  So that's it.  So what we can do then is...  So I basically now set up...  Well, actually, there's one more thing.  That's how you define the deployment.  And then you want to have a continuous deployment.  So add a trigger to say that, well, whenever the previous build project is successful,  this one is going to kick off.  And then you set up a few dependencies.  Say I have a snapshot dependency on a previous project and an artifact dependency on the build zip file.  And I just unzip that into a folder so I can use those files during execution.  And that means that we now can go into Visual Studio and make a change to this project.  Let's say we're going to do...  Change the name here and just say something like that.  Just to make a change.  And I'm going to check that in to GitHub.  Ups.  Like that.  Pissed us to GitHub.  I mean, you can use whatever source control system you want connected to your CI.  And if we go out here, CI should kick off this process.  So I'm just going to help them a bit.  So trigger it.  And as soon as that's finished, it's going to automatically trigger the next one, which is the deployment.  By the way, if you want to know more about Condep, I have a talk on this tomorrow at 1340.  So drop by if you want to know more.  And then suddenly this one's going to kick off.  Usually takes a bit of time.  Come on, you can do it.  There it is.  That kicks off.  Look at the build log, what's going on.  Executes Condep.  Condep starts doing stuff on that.  Promotes server in the cloud.  I can't really much say about the details here now.  I'll talk more about that tomorrow.  If we go to the server and have a look at this folder,  it should show up very soon a folder here called Web Apps that contain the application that is going to deploy.  So it's just about to do the deployment now.  So in 10 seconds.  So that's Web Apps.  And it's also a Web App.  And if you look at the website, it's the website's there.  And if we go to this one, do refresh.  It's getting displayed.  So that's how you do the continuous deployment.  Hello, everyone.  This is my first public appearance as a clown.  By the looks I'm getting when I'm wandering, walking around the halls.  It might be my last.  We'll see.  So I'm Bjorn Einar Bjartnes, developer in Kompitas.  But today I'm here as the enterprise clown, my alter ego.  And I just have to give a little bit of warning.  There might be some rants in here.  We'll see.  So at some point, Bjorn, he took the red pill and he saw what was outside the enterprise world.  And he saw what the cool kids were doing on GitHub.  And he saw how lean software they built.  He saw that with his own eyes.  And he learned that the true battle is not the battle between Eclipse and Visual Studio.  It's between Wim and Emax.  He learned about the history of our industry, of which little is spoken in the enterprise.  And his eyes seeing clearer every day, the way of the enterprise makes Bjorn really sad.  And to stay sane, he sometimes lets his inner enterprise clown out as today.  And the clown does stuff that does not really belong in the enterprise,  but cunningly disguised as a clown, he gets away with it.  And sometimes he even manages to put a smile on the depressed Bjorn's face.  And the clown helps Bjorn stay sane while he dreams of better days for our industry.  So the blue pill represents enterprise software of today,  whereas the red pill represents what's out there, what's out there on the Internet.  So I figured, let's eat the red and the blue pill and go on this purple trip.  It might expand our consciousness.  Let's build SharePoint apps in Node.js.  So not to be too abstract.  I'm just going to show you what we did at Hackathon, me and some friends.  I'll have their names later.  It was the Arctic SharePoint Challenge earlier this year.  And so what we're seeing here is this multi-user real-time application on SharePoint.  So you see we're using leap motion to drag and drop these tasks.  You can control priority and completeness date and you can add new tasks.  And you see how they're synchronized with the iPhone and the iPad using WebSockets  across Atlantic in real time.  It's not your typical SharePoint application, right?  So Node.js has been mentioned before.  The key thing I wanted to think of here, drop that JavaScript runtime thing,  but it's a platform that's built to do scalable network applications.  I'll come back to that.  You're talking about SharePoint apps, right?  Why are you suddenly talking about distributed network applications?  We'll come back to that.  That's really all we need to know.  And the other part about leanness.  And the NPM part was mentioned before, so I don't really have to go into that.  But that's really core here, that we have like this really simple understandable core  and you can pull in modules and build on those modules.  And the Hipstru factory is also pretty good on Node.js.  It's starting to fade off.  I think it's close to Erlang and close to Closure, almost there.  So that's a plus as well.  Whereas this guy, SharePoint, has a Hipstru factory like Near Zero, maybe negative.  And it's this big enterprise monolithic product.  And we're doing this IDE driven development by Wizards.  So we have this Wizards that leads us through and pretends to help us.  And the cool thing about SharePoint though is that in 2013, Microsoft opened it up.  They created their API.  They call it a REST API.  It's pretty REST, part of it is RESTful anyway, which allows you to connect with whatever web technology you like.  So since I don't know Erlang, I've tried to do something with Node.js on it.  So we all know this guy, right?  He's a powerful wizard. He's a very good wizard.  He helps you do stuff.  He helps good people do good stuff.  Then we have this wizard.  He's an evil wizard.  He blurs your vision.  So you hardly can see what's going on.  And I'm thinking, I'm trying as hard as I can, and I guess a lot of you are as well, to be good programmers.  And then we get this Joe Sixpack IDE that Microsoft thinks is going to help us to build better stuff.  This is their idea of DevOps, right?  That you're supposed to choose your dev environment by a drop-down list, and press F5 and everything is going to be okay.  Either they've solved DevOps with a drop-down, or it's the major leak abstraction that is going to ruin your project when you're going live.  You might work for one guy and one machine doing dev stuff.  If you're lucky, it's going to work in one instance when you deploy it.  I'm not going to go into detail on this part.  This just shows what you have to start to do manually when you're building a SharePoint app.  You have the client.  You have your SharePoint application here.  You have SharePoint itself.  And you have the Azure ACS, which gives you does all authorization and authentication and all of that stuff.  So there's a lot of tokens flying around here that you need to understand in order to build this if you're doing it from scratch.  All of this stuff, the wizard wants to hide from you, but sooner or later, you need to understand this anyway.  So this is the architecture of a SharePoint, typical SharePoint application.  So you have this is your SharePoint instance in the cloud.  So these are all your clients that are connecting to SharePoint.  Then you have ACS, that does the authorization part.  Then you have your application.  In my case, it was Node.js running on Node.jitsu just to really show it's decoupled.  I'm building on Linux.  I'm deploying on Linux and running on Node.jitsu.  So it could have been Azure, but I'm trying to stay all enterprise clowny.  You need to do it on non-Microsoft technology.  And you might be using some Azure backend services as well.  And this is where these distributed network applications come into play.  Because in a real-time app, you have secure web sockets.  You have HTTPS to multiple clients.  Clients can talk directly to SharePoint, and SharePoint will talk.  So everybody's talking to everyone here.  And this is where this Node.js event loop model fits really well in.  Not if you do it synchronously as shown before, but if you let Node do its job normally.  So again, just a screenshot from how you can deploy stuff when you're running and building on a proper operating system.  You have a proper shell that can deploy.  You see the package, and you can run commands to deploy it wherever you want.  And you have full control of what's going on, which is very, very nice if you're building applications that are supposed to work.  So I'm going to a little bit more just to show you an example of how this looks like.  So you see now we're on ByardWolf SharePoint.com.  So this is a SharePoint instance in the cloud.  And I can launch my application.  So I'll launch my application, and all this authorization dance is going on.  And we're on Node.jitsu.  And we have cute cats on tasks.  And you see, this looks very much like SharePoint.  You can pull in all the Chrome.  Everything is web-buried.  I mean, you can do this.  You would think this is a typical SharePoint application, but it's running on Node.  So you can create new tasks.  And when you create something, it's sent to SharePoint.  And when you just drag stuff around for the real-time stuff, SharePoint doesn't even know about it.  Your application is just relaying this to all authenticated clients.  So we can go back to SharePoint to see our task is back here, and we can add that to the task list.  So what do we get?  We get this lightweight application, which is cheap to host.  It's cheap to scale.  It's possible to understand, which is very good.  And you can leverage all these cool NPM modules.  I want to give a few shout-outs to MacRotter at Qport.  He made this passport strategy for Node.  I stole everything from him.  I'll scale your NARA, and I'd love if you're helping me build this thing in the Hackathon.  Here's the code if you're interested.  This code is Hackathon code.  I wouldn't use it for anything serious.  And if you're into building cool apps on SharePoint, but more for real, not as a clown,  I would really recommend this next talk in Room 1 on building enterprise IPs to apps with SharePoint and JavaScript.  So all I can say, dare to wear the foolish clown face, go out, experiment, have fun,  enjoy the rest of the conference.  Thanks.  Thank you.
Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_0_4619.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_4620_7595.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_7596_9743.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_9744_11159.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_11160_11639.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_11640_12227.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_12228_14315.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_14316_14795.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_14796_14843.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_14844_15023.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_15024_15251.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_15252_15323.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_15324_17699.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_17700_18095.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_18096_21335.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_21336_22331.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_22332_24491.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_24492_27107.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_27108_29759.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_29760_31763.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_31764_40595.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_40596_41651.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_41652_41735.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_41736_41831.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_41832_42719.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_42720_43019.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_43020_43163.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_43164_43403.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_43404_43823.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_43824_46259.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_46260_46391.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_46392_52463.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_52464_52523.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_52524_52571.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_52572_54923.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_54924_56243.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_56244_59243.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_59244_62339.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_62340_62519.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_62520_63275.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_63276_63647.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_63648_63791.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_63792_67175.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_67176_67487.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_67488_67547.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_67548_68903.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_68904_72347.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_72348_76103.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_76104_76163.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_76164_76331.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_76332_77579.png Justin_Rusbatch__Christian_Amor_Kvalheim__Jon_Arild_T__rresdal__Katya_Mustafina_and_Bj__rn_Einar_Bja_77580_77602.png