Category Archives: WebDev

Show me your imports, and I’ll tell who you are

Well, maybe not, but your imports may indicate, how maintainable is your code.

Have you ever written something like this:

import { SomeClass } from 'somelib';
...
const s = new SomeClass();

Or this:

import * as someFunc from 'somelib';
...
const s = someFunc();

Looks familiar, right? I’ve written a lot of lines like these, mainly because the README in every library, package recommends them. But there are (at least) two problems with this code why I am trying to avoid them.

Dependency management

If you unscrupulously follow this pattern, you will write the same line of code hundred (or more) times within a single application. Why? Because we love copy-paste. Easy, convenient, and it works, right?

However in this way it will be very difficult to determine what your app exactly needs, what it depends on, what are its dependencies. What one can easily see from your code (only after using the “Find in All Files” feature of your favorite editor), is that your code references to an external package in countless places, so it needs that package, your app depends on it.  

But reality is different: your application logic does not need a package, but a functionality, a logic, which happens to be implemented in a third party package. But it’s not what your code shows at the first sight.

Here’s a more specific example with the popular lodash package (*):

var _ = require('lodash');

This package provides a number of utility functions, and it is pretty much impossible, that your app needs all of them. How can you find out what exactly you are using? Search all your files for “_”.

But why is that interesting?

For example, because you may want to replace the referenced package with something else. In the open source world, packages come and go, today this was the best, tomorrow that will be the one. Because the old package contains a bug, that will never be fixed, or because only the new package is compatible with the latest Node version that other parts of your app requires. Or simply because you want to keep your codebase fresh, and you want to use only dependencies with active community.

You can be sure that you will not find another library or package, that is API-compatible with the old one. You need one that is compatible on functionality level, which you can only find out if you know exactly what functionality are you referring to.

When you have that, you just have to change the references in as few places as possible in your code.

This leads to the solution: make sure, that you reference third party packages only once in your code, so wrap them into classes that publish only the functionalities your app depends on. This method can also make your code more readable, for example, instead of "sha256()", you can find a much better function name, right?

This method works for me very well for a long time, though I have to note I don’t follow it fanatically, because it will be too much overhead for framework level libs (e.g. Angular).

Testability

If your class uses “import” to refer to another one, unit testing that class will be a nightmare, because you will have to hack the file loader logic to mock the class (e.g. Mocking Request-Promise).

The solution is not new: DI. Not only does it make testing easier, but typically you just have to take a look at the constructor, and you will see on what other classes this one depends on.

For example, in TypeScript, we often import interfaces just to have type description, which can make import rows very verbose, and often you cannot determine at the quick glance which import brings in functionality and which one is there for type information only. DI also helps in this, if we try to use “import” only for type descriptions, and DI for everything else.

Is this something new?

Not at all. Really. Yet these codes continue to live, even if they are hard to maintain. READMEs, tutorials, articles, blogs will always strive for simplicity, you will find examples of them that help you understand the content and get started. Their purpose is not to blindly follow them in a more complex application where maintenance and sustainability is as important as simplicity. When you write such a line next time, think about what you’re really bringing into your codebase. Do you really gain some time with it on the long run?

programming-is-thinking_thumb

 

*: The example is not perfect, because lodash provides more fine grained imports, however it is not well known or widely used.

 

Technorati-címkék: ,,
Advertisements

Write your Node.js app in C# with Roslyn

When the Microsoft Managed Languages team announced in December 2013, that they replaced the existing C# and Visual Basic compiler, and they use a new compiler to create the daily builds of the next version of Visual Studio, it became obvious to all developers, that something big is coming. The new tool, codename “Roslyn”, has far more capabilities than the previous csc.exe and vbc.exe, so it is not a coincidence that .NET Compiler Platform became its official name.

Roslyn is not only about converting our source code to an executable format, we already had a excellent tools for that for many years. The goal of Roslyn is to open the power of the compiler to developer and development environments (such as for Visual Studio), so this is a compiler-as-a-service solution.

Why do we need that? Compilers are very complicated, and during their execution they collect a huge amount of information about our source code:

compiler-architecture

It would be a huge mistake, if we would lock that information into a single tool, instead let other tools benefit from this knowledge. The compiler is our only tool that really understands our source code, as it obviously knows from every single character in our source code whether it is code, data, comment etc. Using this knowledge, we can build much better tools, for example many features of the Visual Studio 2015 would never exist without Roslyn.

Here you can see the Roslyn architecture (click for a larger image):

roslyn-architecture

If you want to understand all little boxes feel free to visit the project home page, I just want to point out that you can find here everything from understanding the source code to generating the executable output, and because it is a platform, naturally you have API for everything.

The key item is the Syntax Tree highlighted with yellow, which is the inner representation of our source code, created by the Parser. The API for that is the Roslyn Syntax API, which allows you not only to analyze your source code from source code, but you can even change that on the fly. Let’s take this simple expression as an example:

Regex.Match("my text", @"\pXXX");

Roslyn builds the following syntax tree from that:

Turner_Figure4_hires

(I borrowed the example from the Use Roslyn to Write a Live Code Analyzer for Your API article of the MSDN Magazine, which shows you how to build a Visual Studio plugin on top of Roslyn.)

It is totally up to you, whether you want only analyze or modify this tree.

This has been also recognized by the TypeScript team, and they are using Roslyn from version 1.3 to provide the necessary data for several Visual Studio IDE features. As a result of that the architecture of the TypeScript compiler became much cleaner and much more understandable:

typescript-architecture

For us the two important components are in the lower box: the Parser and the Emitter. Parser is responsible for building the syntax tree – in this case from the TypeScript source –, and Emitter is responsible for generating the compiler output based on the syntax tree – in this case the JavaScript (.js), the definition (.d.ts) or the source map (.js.map) file.

It is important to note that the architecture of Roslyn and TypeScript are pretty similar: first they build a syntax tree, and then they generate the output based on the tree. For Roslyn this is C# –> tree –> IL, for TypeScript it is TypeScript –> tree –> JavaScript.

Because the two trees are similar, we can combine them, and now we have the following solution:

flow

This means we can compile C# to JavaScript with Roslyn and TypeScript!

The huge benefit of this architecture is that the input is the original C# source code (in contrary to the JSIL project for example that compiles Common Intermediate Language to JavaScript), which contains way more information (e.g. inheritance, scoping, etc.) that are lost in the output of the C# compiler. This gives us the opportunity for more efficient code optimization!

Let’s take the Raytracer demo from the JSIL project as an example. The original C# source is 429 lines, the JSIL-generated JavaScript is 793 lines. You could say, that at least it runs, however the memory management is far from optimal:

raytracer-memory

Processing the same source code with the Roslyn Parser + TypeScript Emitter combo you can get the following results:

raytracer-memory-2

We also measured the CPU utilization and Visual throughput (FPS) with the UI Responsiveness tool in Internet Explorer Developer Tools (F12), and we got better results for both metrics as well.

Obviously better memory management and better performance do not come free, the generated code is bigger, in this case 1844 lines of code. The significant increase is the result of the richness of the syntax tree: in contrast to the IL code, it contains information about the classes and member visibility, which can be translated only to complex JavaScript code, but if we do (and the TypeScript Emitter can do that), than we can get better performance with the price of more code to download. We experienced the same result when we analyzed other applications.

This method works not only with browser based applications, but also with native JavaScript apps, for example with your Node.js app. These are the required steps:

  1. Install the Node.js Tools for Visual Studio plugin, which gives you everything you need to develop Node.js apps with Visual Studio.
  2. Download and install the Node.js with C# plugin from the Visual Studio Gallery (coming soon).
  3. After installation, you will see a “Node.js application” project template within the C# project templates. Create your new project with that template.
  4. Implement your application in C#, and of course you can use Visual Studio for that.
  5. You can debug and run your code as usual, because the project template contains the necessary MSBuild targets, that compiles your code with Roslyn and TypeScript, and then passes it to the Node.js Tools for Visual Studio which in turn runs it with Node.

We are looking for beta testers! Before publishing the Visual Studio plugin, we would like to do a broader test and collect feedback from you. If you would like to try our tool, please read these guidelines and leave a comment below, and I will contact you with the download link. Thank you!

 

Update:

This article hit the top of the node.js subreddit:

reddit-node

http://www.reddit.com/r/node/comments/31r872/write_your_nodejs_app_in_c_with_roslyn/

 

Error subclasses may lose their message property

You have probably already seen a code like this:

try {
  throw new Error('Oh, nooooo!');
} catch (e) {
  console.log(e.message);            // Oh, nooooo!
  console.log(e instanceof Error);   // true
}

If you create many of those blocks, sooner or later you will decide that you are going to use custom error classes, even in JavaScript. It may seem to be a great idea to implement them this way:

function OhNoooError() {
  Error.call(this, "Oh, nooooo!");
  this.name = "OhNoooError";
}

But you may be surprised by the results:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // undefined
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // false
}

So the error you catch is not a classic error (does not inherit from the Error base class), and it does not have a message property! Oh, nooooooooooo!

Here is one way to fix it:

OhNoooError.prototype = Object.create(Error.prototype);
OhNoooError.prototype.constructor = OhNoooError;

function OhNoooError() {
  this.message = "Oh, nooooo!";
  this.name = "OhNoooError";
}

And now you have a much nicer output:

try {
  throw new OhNoooError();
} catch (e) {
  console.log(e.message);                 // Oh, nooooo!
  console.log(e instanceof OhNoooError);  // true
  console.log(e instanceof Error);        // true
}

The point is that you have to set the message property explicitly in the derived class – even if you use the extends keyword in CoffeeScript to do the inheritance magic.

 

Technorati-címkék: ,

Hey WebStorm, don’t search in the node_modules folder!

How annoying is that whatever you search for in a node.js project, WebStorm gives you thousand hits from the node_modules folder?

Calm down, and go to the Project window, right click on the problematic folder, and click Mark Directory As –> Excluded:

webstorm-exclude-folder-from-search

The folder won’t disappear from the Project window, but won’t pollute your search results any more.

You can undo this in the same place: Mark Directory As –> Cancel Exclusion

webstorm-exclude-folder-from-search-cancel

 

Technorati-címkék: ,

Updating node.js on Windows

Last week the node.js team released version 0.10.36, which was much anticipated by many of us, as it contains a fix for a debugger and strict mode regression issue.

If you are working on a Windows machine, the easiest was to update your node.js runtime is to download the latest MSI installer, and go through it with next-next-finish. After that you can use the node –v command to verify the version number of your local installation.

 

Technorati-címkék:

The file is there, but returns with 404

I am trying to load an ASPX URL, but it fails. Well, it loads when I try from IIS Express with the source code, but after I publish it to IIS, it fails with 404.

The file is right there where it should be, it just cannot be downloaded. I turn on Failed Request Tracing, hopefully it will show something. It does: 388 log entries for a single HTTP request. Fortunately the Request Summary view highlights the only warning:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName: ManagedPipelineHandler

Notification: EXECUTE_REQUEST_HANDLER

HttpStatus: 404

HttpReason: Not Found

HttpSubStatus: 0

ErrorCode: The operation completed successfully. (0x0)

Not a big help, but it shows which module is guilty. Little joy. I look up the entry in the Complete Request Trace and check the previous entries. AspNetParse and AspNetCompile entries. Hmmm, maybe something is wrong with the ASPX file? Probably not, because it runs on IIS Express, and I have it from a NuGet package.

Anyway, I check the source code. The first line looks suspicious: the @Page directive contains a CodeFile attribute. Unusual. I change it to CodeBehind. Compile, publish.

It works.

 

Technorati-címkék: ,,

Visual Studio: Unable to check out the current file

I’ve received the following error message in Visual Studio right after I’ve tried to add a new service reference:

Unable to check out the current file.  The file may be read-only or locked, or you may need to check the file out manually.

The message was really strange because the Add Service Reference dialog seemed to recognize the service perfectly, and although the project was under source control, we have Git on the server so “check out” did not seem to be the right term here.

The sad truth is that the above error message is completely wrong and the issue has nothing to do with source control. The solution is to click the Advanced button in the Add Service Reference dialog, then click the Add Web Reference button and use the old Add Web Reference dialog to add that particular service to your project even if the URL points to a .svc file.

 

Technorati-címkék: ,,