Node.js Tools for Visual Studio: Deployment Hiccups

Next steps sometimes can be cumbersome. Yesterday, I was trying to deploy a node.js application with express.js to an Azure Website. I was following this tutorial. I figured I’d never make it on first attempt.

Much to my surprise, I did in just six minutes.

On a personal note, I’d like to add that publishing to Azure Websites using git (and getting this really useful deployment history) is something that makes me happy on every single deployment.

So today I was ready for the next step. I am usually working with Visual Studio, so I wanted Node.js Tools for Visual Studio. This give me a lot of benefit out of the box that I’m not even going to mention here, but Scott Hanselman was pretty excited about it some time ago.

So after installing I created a blank Node.js app. To be precise, it was this option.

NodeToolsProject

I was not using any of the Azure variants listed here, as I did not need the deployment scripts they add in this case. For a difference overview of these project types, check out the “Converting to an Azure project type” section on their deployment wiki page.

After the project wizard did it’s job, I created a new commit, created an azure website, added its git endpoint as remote, and pushed. After yesterday’s experience, I figured it would work in about 30 seconds.

Much to my surprise, it didn’t. Not even in six minutes.

Turns out there were two problems.

Problem 1

The project wizard creates a .gitignore file. This seems to be a variation of the standard Visual Studio .gitignore file, which excludes everything beneath bin folders. However, for some reason the project template uses a www file instead of server.js. Guess its path? Right, bin/www. Which means it gets excluded, so I had to make sure to explicitly add it.

Problem 2

Are we good now? Not quite. Contrary to the tutorial I followed yesterday, my “real code” does not live in the root of my git repo. Instead, that’s where the .sln file lives, the project is one level deeper.

| root
| – mynodeapp.sln
| – mynodeapp/
| – mynodeapp.njsproj
| – app.js
| – package.json
| etc …

Which means, Azure will get confused about the nature of your project (won’t recognize it as node.js application) and fail more or less miserably. It just didn’t tell me, as deployment history showed green.

The second last paragraph on this Kudu help site brought me on the right track, as well as a comment on the first tutorial mentioned above: it is necessary to tell Azure website to look one level deeper. The most flexible way of doing so is an app setting entry in the Azure Management Portal itself, under the Configure tab of your website.

The key needs to be Project, and the value has to be <projectfolder>.
Notice the dot at the end. Like so:

NodeWebsiteAppSetting

Saved the settings, headed over to the deployment history and forced a redeploy of my last commit.

And sure enough, it was running as expected.

Hope that helps

Contents and Topics Covered in Microsoft Exam 70-480: Programming in HTML5 with JavaScript and CSS3 Part 2

As mentioned in Part 1 (Javascript), Tekaris is currently undergoing recertification for our Microsoft Gold Partner Status. As a part of this, I was collecting topics addressed by possible questions and thought it might be helpful for others.

This post is targeting HTML5 and CSS3 aspects of the exam. See Part 1 for an overview of Javascript topics.

To get an overview, I have compiled a list of topics. Some are only listed by name, others have links which you can follow, others are even detailed with a few words.

HTML5

Figure seemed to be important to Microsoft. During my exam, I even got the same question twice, one directly following the other. Only the answer had to be provided differently.

CSS3

… and some others, of course 🙂

Hope that helps
.jonas

Contents and Topics Covered in Microsoft Exam 70-480: Programming in HTML5 with JavaScript and CSS3 Part 1

At Tekaris, we are currently undergoing recertification for our Microsoft Gold Partner Status. As a part of this, I was collecting topics addressed by possible questions and thought it might be helpful for others.

This post is targeting Javascript aspects of the exam. Future posts will cover different areas.

It definitely helped me to revisit some concepts by identifying required knowledge for that exam and digging into it. To get an overview, I have compiled a list of topics. Some are only listed by name, others have links which you can follow, others are even detailed with a few words.

Then there’s that slightly broader topic of that little keyword this and closures.

This (yes, this) really stumped me when I, coming from an object oriented programming style, first encountered Javascript years ago.

Why on earth do we see

var that=this;

a lot and what makes this hack actually work? I recommend “How this works“, especially section “common pitfalls” and “Closures and References“.

And then, be sure to head over to Html5 Rocks for their introduction to Web Workers. Some points to take away:

  • There are actually two types of Workers defined in the spec: Web Workers and Shared Workers
  • Use postMessage() to communicate between the parent javascript code and the Worker (works in both directions)
  • Some things a worker cannot access: DOM, localStorage or sessionStorage. They do have a list of options, though, but I’ll shamelessly refer you to these details on SO for that.

As you can see, there is nothing too fancy covered in this test as far as Javascript is concerned. It’s important to have a general grasp of the language and only sometimes there are details required to answer a question. Generally speaking, I want to highlight two helpful resources here. I have used them for my research and also linked to them for this list.

The obvious one is the Javscript section of the comprehensive Mozilla Developer Network (MDN). It has a wealth of information, sometimes along with helpful side notes when it comes to details.

The other one, not-so-well-known but essential source of nitty-gritty Javascript details is the much beloved Javascript Garden. You are guaranteed to learn a thing or two over there.

Hope that helps
.jonas

An IEnumerable is not a List, it’s just a promise of a List

It is actually quite obvious, but figuring out the implications still took me a few minutes today.

Suppose you have a simple list of objects:

List<Object> list = new List<Object> { new Object(), new Object() };

And for some reasons you’d like to create a projection from this list using a wrapper class. One reason why you would do this is wrapping business objects into ViewModels.

var enumerable = 	from o in list
					select new Wrapper(o);

The Wrapper class only adds the capability of being flagged to the whole story:

public class Wrapper
{
    public bool IsFlagged { get; set; }
 
    private Object Obj;
    public Wrapper(Object o)
    {
        Obj = o;
    }
}

So what you now have in enumerable is an IEnumerable<Wrapper>. Next, you’d like to use the wrapper functionality and flag the two elements in enumerable:

foreach (var e in enumerable)
{
	e.IsFlagged = true;
}

And then you go forth using your enumerable, only to discover that none of the contained elements are flagged.

What!? Why?

It’s because an IEnumerable is not a List. One needs to understand that prior to calling .ToList() or using foreach() to enumerate over it, no constructor of wrapper has been invoked. Put another way, only because we used this nifty LINQ projection, no Wrapper instances exist yet.

They came into life when we foreach’ed them and disappeared right after that. Whenever we try to use enumerable again, we are enumerating this LINQ expression again. Which means we call the constructors again and we get totally different instances of Wrapper.

For example, suppose we’d use this expression in order to check how many elements are actually selected as an effort to find out why the program doesn’t work as expected:

int numberFlagged = enumerable.Count(e => e.IsFlagged);

This will return 0, as we already know. The best way to find out is to step through the provided code and put a breakpoint into the Wrapper constructor. Please find the whole source code ready for copy & paste at the end of this article.

Although i knew how an IEnumerable behaves, it took me 10 minutes today to find my error in a slightly more complicated example. I guess it’s the special case of using a linq projection together with an IEnumerable that got me.

class Program
{
    static void Main(string[] args)
    {
        List<Object> list = new List<Object> { new Object(), new Object() };
        var enumerable = from o in list
                            select new Wrapper(o);
        foreach (var e in enumerable)
        {
            e.IsFlagged = true;
        }
        int numberFlagged = enumerable.Count(e => e.IsFlagged);
    }
    public class Wrapper
    {
        public bool IsFlagged { get; set; }
        private Object Obj;
        public Wrapper(Object o)
        {
            Obj = o;
        }
    }
}