All right. Thanks for coming. My name is Justin Ruspatch. I am the author of compileify.net, an online IDE for C sharp. It lets you actually evaluate code from your browser. And together with Glenn Block and Philip Bojesen, 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 little bit like that. Either from console apps you spun up to explore an idea or a console app that you wrote to schedule 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. What ScriptCS is a lightweight scripting experience for C sharp. It's based on the Roslyn 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 Roslyn 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. Roslyn 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, namespaces 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

NuGet integration that allows you to reference NuGet packages from your script, install NuGet packages for your script to use, and restore NuGet packages from a packages.config file that NuGet 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 ScriptCS being Node and NuGet being kind of at the NPM. Glen 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 preprocessor, just the 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 nougat distributed assemblies that allow you to kind of set up your environment

for your scripts. The goal of ScriptCS is to eliminate as much boilerplate code as possible. To reduce the number of lines you need to write to have a working application to as few as possible. Unfortunately, not all of the lines that are boilerplate are related directly to C sharp. We eliminate as much of those as we could

with the relaxed scripting 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 change. 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 of 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 resolver anymore, 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 that method, 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 ScriptCS? What are the steps involved? We install and distribute ScriptCS through Chocolaty. I'm not sure how many of you have heard of Chocolaty, but it is similar to apt-get for Windows.

It installs applications through NuGet for your system to use, adds them to your path and everything. So all you need to do is install Chocolaty and run the command C install, or script CS, and we'll pull down the latest version for you from NuGet and throw it in your path.

It's actually installed to your apt-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. Glen 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 Rusbach, and gate script CS.

So I'm gonna speak about just hacking in OGS ugly, worstly, like, you know, ingloriously to make it run synchronously without doing any fibers or coroutines or anything like that. Who am I? I work for Tenjin, or MongoDB. I live in Barcelona, although I'm born here,

so I'm Norwegian as well. So why do we wanna 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 Spider Monkey

from Mozilla together with a bunch of C++ code. And we changed to V8 like in the last couple of releases, and we started thinking about, like, is it feasible to actually just use Node.js, right? 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 kinda had to get around a couple of problems. And the banana code is one of them, right? The typical Node.js code will look something like this. I mean, as you're writing callbacks, and callbacks and internal callbacks, you just 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, like, futures, right? 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 it actually, 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, something that's coming in ECMAScript 6 is called generators,

and it introduces the concept of the yield keyword and generator functions. And this is kind of a language level feature. Most people kind of, like, who's discovering JavaScript now don't really realize that, like, in probably about a year there's gonna be a massive shift in the way the language works, right? It's in Node.js under the secret harmony switch,

which I can't even spell, switch. But if you, for example, download, like, Node.js 11.2 or higher and do slash slash harmony, you suddenly have access to all of these new features that are coming in all the browsers sometime in the future. So they will all be in Node.js long before anything else.

To do, play around with it, you run the harmony thing and then you do an npm install, which is the Node package manager of a nice little library called Galaxy that will help you basically do it more simply. And code, like, would basically looks like that. You see this new kind of function declaration with a little star on it.

That's a generator, right? You have a little keyword yield, which basically yields to the system. So, 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, like, process the next kind of, like, statement. And then it returns, like, 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 coroutines like you have in C sharp, but it's close enough. So I decided this wasn't gonna work either. So I decided, like, let's just 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 meant some C++, right? And I'm gonna go real quickly through this, but this is what a C++ code for, like, 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, very simply, what we're doing is that we're creating a new function that wraps the function that we're gonna 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. Like, so think about you're, like, 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, right? 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 sync, require sync it, and then you take a function in Node.js, like the read directory function, and you do sync wrap fs read there. It gives you back a function, and now you can do, like, wire.fileamps 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 set timeout, 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, right? Here we're blocking, waiting for a second, right?

And then we see the read there asynchronous call actually executes, the one we started up here, in between, right? Because we're single-stepping 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 gonna segfault. So that's 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 DocumentDB talk tomorrow in roommate at 1.40. That's it.

Yeah, should I start? Yeah. Hi everybody. I'll be talking about the mindset to develop public API.

I will not be showing any code, so it will not be that geeky talk of two previous talks. So I will introduce myself. My name is Kajsa Mustafina and I am a developer. I've developed software for 17 years in different companies and countries and roles. And the last six years, I worked for Schlumberger 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 millions 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 an API Ocean. And that actually today, hundreds of developers develop plugin 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've 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. But 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 of all 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 the 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 in API it's 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 appeared that people handle much easier

their changes in their interfaces or functionalities than changing the API. For example, if you download an app from the iPhone app store, and I downloaded 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 don't want to do it.

And so 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 pardons 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 pattern 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 bigger deal than the coolness 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 stability promise is not there yet. You can change it still. And find the group that would be using it internally before you ship it. And maybe find someone, if you can find it just making a workshop or maybe write a set of unit tests that would be used as documentation to the API, is important thing to do it

because here we can change it. And I work 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 stage and 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. 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.

Thank you. Could I get some tech help? I need mirroring displays. No, it's got a mirror.

Can you show me the mirroring display? Hmm? Can you show me the mirroring display? Hmm. I'll show you the screen.

I'll show you the... Yeah, I'll show you the screen.

Okay, I'll try. So I'll try and do this while looking at the screen at the same time. Which is not gonna be easy, but I'll try. All right, my name is Joon Telestal.

I'll show you how to do continuous deployment in about 10 minutes. Here's a, I'm gonna use two things. I'm gonna use some open source project called Condap 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. And 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 gonna deploy this to a server in the cloud.

Which we also have on a different screen. Let me see. Sorry about this. So 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 gonna create a new project.

New project. Class library, I'm just gonna call that deployment. And just really rename that class. That's, has some name for it.

And you see web app. And in order to do Condapp stuff, you need to have a library. Namely Condapp. And here I'm just gonna use the beta version. That's on NuGet. So I have include pre-release here.

Hopefully I'm on wireless. There it is. Just install that. Pulls all the dependencies down. We now have a domain specific language

for doing deployment in C sharp. So what I'm gonna do with this class is that I'm gonna inherit from an abstract class called application artifact. And I'm gonna implement a method called configure that sends in two objects.

I'm gonna use the first one that's on local machine that gives me access to this DSL. So I'm gonna do a deployment to a server now. So I'm just gonna say to each server. Takes an action. You should use that action. And again, either deploy or execute. I'm gonna deploy. And I'm gonna deploy an IOS web application.

To just make this a bit quicker, I'm just gonna copy some code. And I'm just gonna explain what that is. So here I have a source directory

that tells me where is the source for the application that we're gonna 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 IOS 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 IOS 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 gonna add an existing one to make it a bit quicker.

And this has the extension dev.env.json. So this is a configuration file for the dev environment. If I wanna have something for a test environment as well, it would typically have the test.env.json. I'm just gonna make sure that this

is being copied when I build. So just do like that. And here I tell Conda which service I'm gonna deploy to. So there's just one server, but it can be as many as you want. And which user are you gonna use to authenticate with towards that server. With a password in clear text,

but that's gonna be fixed, right? So we need to encrypt that. But right now it's in clear text. So I'm just gonna 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 sip, which is the artifact for the build. Just gonna make this a bit bigger. No, okay.

And then we need a separate project in TeamCity for actually doing the deployment. So just to make it easy, I'm just gonna do this. I have a project here. I'm just gonna 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 Condap XE, which was pulled in when I added the NuGet packages. This is the one we're gonna use in order to actually execute the deployment.

So just give the project a name. And there's no version control settings because it just depends on a previous build. Define a command line, which is just a name for Condap.exe,

the XE file that does the deployment. And you tell it which DLL does this find a deployment definition in. And then you'd point to the environment that you're gonna use. And then you just use convention to figure out, well, dev.n.json is the JSON file I'm gonna 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 basically now set up continued, 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 gonna 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 gonna change the name here and just say something like that. Just to make a change.

And I'm gonna check that in to GitHub like that.

Push it 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 gonna help them a bit.

So I'll trigger it. And as soon as that's finished, it's gonna automatically trigger the next one, which is the deployment. By the way, if you wanna know more about Condap, I have a talk on this tomorrow at 13.40.

So drop by if you wanna know more. And then suddenly this one's gonna kick off. Usually it 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 Condap, Condap starts doing stuff on the remote 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, have a look at this folder. There 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 there's Web Apps, and you see also 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, thanks.

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 Bjornes, a developer in Competas,

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 Emacs. He learned about the history of our industry, of which little is spoken in the enterprise. And his eyes seeing clear every day,

the way of the enterprise makes Bjorn really sad. And to stay sane, he sometimes lets his inner enterprise clone out as today. And the clone does stuff that doesn't really belong in the enterprise, but cunningly disguised as a clown, he gets away with it. 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 represent 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 a 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 state, and you can add new tasks. And you see how they're synchronized with the iPhone and the iPad using WebSockets

cross-Atlantic in real time. It's not your typical SharePoint application, right? So Node.js has been mentioned before. The key thing I want you 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 this really simple, understandable core,

and you can pull in modules and build on those modules. And the Hipster 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 Hipster 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 these 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 RESTful. Parts of it are 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 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 six-pack IDE that Microsoft thinks is gonna help us to build better stuff. Like 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 gonna be okay. Like either they've solved DevOps with a drop-down or it's like the major leak abstraction

that is going to ruin your project like when you're going live. It might work for one guy and one machine doing dev stuff. If you're lucky, it's gonna work on one instance when you deploy it. I'm not gonna go into detail on this part. This just shows like 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 a 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 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.js just to really show it's decoupled. I'm building on Linux. I'm deploying on Linux and running on Node.js.

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 this distributed network applications come into play. Cause like 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 like 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 like an example of how this looks like. So you see now we're on beartwolfsharepoint.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 Nojitsu. 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 Webberry. 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. And you can go back to SharePoint. You 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 Mac Rotor at Qport.

He made this passport strategy for Node. I stole everything from him. I'll scale your note. And I'd love it for 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 hip straps 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.