So I’ve been doing a bit of an experiment. I’ve seen that those community updates are normally rather small. I’ve waited a whole week before posting something new to see if we have better content.
I like the “Massive Community Update” for the amount of links it provides and for the occasion to put James Chambers whole series in perspective.
If you’re still thinking about it… read it. It’s worth it.
So I was at the MVP Open Days and I’ve missed a few days. It seems that my fellow MVP James Chambers has started a great initiative about exploring Bootstrap and MVC with lots of tips and tricks. Do not miss out!
Otherwise, this is your classic “I’ve missed a few days so here are 20,000 interesting links that you must read” kind of day.
So I’ve had the big idea of building an integration of Nancy and Superscribe and try to show how to do it.
Sadly, this is not going to happen.
Nancy doesn’t treat routing as a first class citizen like Superscribe does and doesn’t allow interaction with routing middleware. Nancy has its own packaged routing and will not allow Superscribe to provide it the URL.
Nancy does work with Superscribe but you have to hard-code the URL inside the NancyModule. So if you upgrade your Superscribe graph URL, Nancy will not respond on the new URL without you changing the hardcoded string.
I haven’t found a solution yet but if you do, please let me know!
We’ll start from my previous post with a single console application with a self-hosted OWIN instance.
The goal here is to provide a routing system so that we can route our application in different section. I could use something like WebAPI but the routing and the application itself are tightly linked.
I’m going to use a nice tool called Superscribe that allow to do routing. It’s Graph based routing but it should be simple enough for us to hook it up and create routes.
Installing Superscribe
Well, we’ll open up the Package Manager Console again and run the following command:
1
Install-Package Superscribe.Owin
This should install all the proper dependencies to have our routing going.
Modifying our Startup.cs to include Superscribe
First thing first, let’s get rid of this silly WelcomePage we created in the previous post. Boom. Gone.
Let’s create some basic structure to handle our routes.
public IOwinRouteEngine CreateRoutes() { var routeEngine = OwinRouteEngineFactory.Create(); routeEngine.Base.FinalFunctions.Add(new FinalFunction("GET", o => "Hello world")); routeEngine.Pipeline("welcome").UseWelcomePage(); routeEngine.Pipeline("Home").Use((context, func) => { context.Response.ContentType = "text/plain"; return context.Response.WriteAsync("This is the home page"); });
return routeEngine; } } }
That was simple.
Basically, we build a simple pipeline to an OWIN middleware.
So I know there’s a lot of demo that cover this already but this is normally part of my demo on OWIN/Katana and I always forget which package to install so… you dear reader are going to see my reminder on how to do it.
Creating a new console application
The first step is to create a new Console application. I’m not going to include screenshots of that since I’m pretty sure that you are all smart enough to not need a how-to on creating console app.
Startup.cs
Every OWIN app need a Startup.cs file. If you don’t have SideWaffle installed, you’ll need to copy/paste my code but why do that when you can have a template for it? Here’s my barebone one.
The only thing that won’t work yet for anyone is the “UseWelcomePage”. We’re fixing that right now.
In the Package Manager Console run the following command:
1
Install-Package Microsoft.Owin.SelfHost
There. We should now have something that compiles! Not working yet but compiling. Baby step.
Starting the server itself
Since it’s a console application, we only have an empty Main() that does nothing and adding Startup.cs will not do any magic. We still need to wire-up things up neatly before going any further. Ready?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
using System; using Microsoft.Owin.Hosting;
namespaceMySelfHostedApplication { classProgram { staticvoidMain(string[] args) { using (WebApp.Start<Startup>("http://localhost:8888")) { Console.WriteLine("Server started... press ENTER to shut down"); Console.ReadLine(); } } } }
That’s it. You could remove the WriteLine but I like to have something in my window instead of a blank screen. The ReadLine is required or the server is going to be disposed.
Testing it
Now press F5 and open your browser to http://localhost:8888 and you should see a nice welcome page.
This is a special edition with the Xamarin 3 that was just announced. Don’t miss out on the other content! We have Darrel Miller (BizCoder.com) that talks about WebAPI and OWIN, we have Bootstrap with RequireJS, NodeJS new release of Socket.IO and way more!
Ensure to create an EDMX for your database using EF6. On my side, I’m using the Not-Northwind simple database using all the available tables and none of the views.
Once this is created, we’ll start by creating a brand new service that we’ll call Northwind.svc:
The class it will generate your will not be compilable right away without injecting our classes.
The class will be called “Northwind” and inherit from DataService<…>.
We’ll replace this:
1
public class Northwind : DataService<MySourceClass>
By this:
1
public class Northwind : EntityFrameworkDataService<NorthwindEntities>
This will allow EF6 to connect with WCF Data Services to create a model on your database.
We can test this by hitting F5. It should return you this:
We see that we don’t have anything exposed. Let’s fix that now shall we? Going back to the code, we can add the following line to Northwind.svc.cs InitializeService method.
If you are European and were among the 13 who registered for MonkeySpace in Dublin, please be aware that the event was cancelled and for obvious reasons. We are always in need of good conferences and MonkeySpace had a great list of speakers.
Maybe it was a lack of promotion but anyway. Next year? They’re trying again. Keep an eye open!
If you haven’t seen the debate on “Is TDD Dead?”, you should definitely take a look at it. The debate include Kent Beck, Martin Fowler and David Heinemeier Hansson (creator of Ruby On Rails). The debate is basically around “Is TDD making your code badly design?”. There is currently 3 videos and there is going to be one more on next Tuesday.
For those reading daily, I’m sorry about not posting yesterday. Sickness strikes everyone and sadly, I was struck too in the process and was not able to be present.
Well to start, what is AMD? This acronym means Asynchronous Module Definition.
In the old days of JavaScript development, we defined functions in JS files (or maybe you just wrote them inline in the HTML) and included them in our master page. Those modules got defined in the order we defined them whether we used them or not. Some errors could be possible by defining a JS file before another it depended upon. This would cause an errors when the page loaded without a clear answer of what was the problem. We would reorder our file declaration, hit save and reload.
Did you do that? I sure still do it (kinda) today. Especially for everything that is related to jQuery and its plugins. You make sure to define jQuery before the other modules and it’s almost guaranteed to always work. But here’s where it gets hairy.
When you write application code, there is many ways to do it. 10-15 years ago, people used to put all their code into one file called “app.js” or something along those lines. When you are downloading file at the blazing speed of 5 kilobytes per seconds, it’s important to minimize the amount of requests on your website and every request chewed precious seconds for your user.
Things have changed.
With tools like the built-in .NET Bundler and Minifier or packages like BundleTransformer, it’s now easy to package up your applications in one big file and have everything compressed to save on space. So the excuse to not separate your application in multiple files has been rendered moot in the last 5 years.
So we did. We split all our code in plugins, accessing the DOM with jQuery like never before. Splitting every component in a global namespace “window.MyApp.MyPage.myProperty” but it didn’t feel clean. Having to handle namespaces is boring very fast. You write a lot of boilerplate code like this:
And you had to write this at the beginning of every file to ensure that in whichever order things were loaded, you could actually use them. There had to be another way.
Introducing requirejs
requirejs is a tool that allows you to work with modules (one per file) instead of blocks of code. When writing a module, you can request dependencies.
So you tell requirejs that you want some plugin and requirejs will ensure to download the required file, ensure that this file had their dependencies resolved and so on. All of this being auto-magically downloaded for you.
Another free bonus is we return a static contract. An object which will represent your whole module. This is way better than global function. First, you keep your private to yourself and expose what you want to be exposed. This allows for a behaviour similar to a class.
However, there’s a problem. Do you see it?
It downloads file individually, which is fine in development but becomes a problem in production even with our super fast connections. Even if connections have goten faster, latency (the milliseconds taken for the server to send you the first byte) can kill your performance if you request 20 files (20 files at 200ms is 4 seconds of wait). The classic .NET bundler is not the best tool with those kind of app since they are not contextually aware of the structure of your app.
It works best with something like NodeJS where access to files are local and not remote.
How can we fix this?
With NodeJS and r.js. Why? Because NodeJS allows you to run JavaScript outside of a browser and access your file system to retrieve all the required files. The RequireJS team wrote an optimizer for NodeJS that will compile all the modules you write into a single file.
Basically, you just show him what you want optimized, run the command line and let it go.
First, a module is highly testable. If you want to finally cover your client-side code with unit tests… it’s one of the more efficient way to do it. You define a module, you test its public components.
Second, splitting files for each part of your app instead of having a global file will definitely give a cleaner vision of what is going on in your application. The single application.js file with 20,000 lines of code is not funny anymore. It was fun when we saw an IDE crash from opening the file the first few times but we’re getting serious now. One file per page, widget, dialog and what not is the norm in most serious JavaScript application.
Third, having your dependencies resolved like your favorite package manager (npm, NuGet, etc.) is what we expect out of our tools. Tell the tool what you want, let the tool find your dependency. No more playing with global variable and playing the classic JavaScript Russian Roulette. Changing global state and hoping my code doesn’t break when I don’t click on the right buttons in the right sequence is not the way to go. Know what you are modifying at all time by looking at the requested dependencies.
Finally, having the peace of mind of knowing that your helped make Web Development a little bit better.
So I know that I haven’t covered everything but the point was to help convince you that asynchronous modules are the way to go. Have I convinced you?
