When trying to investigate networking issues, most people know about ping and nslookup. I discovered today that there's also a utility called nbtstat to get some NetBIOS info, including the hostname and MAC address from an IP address.
nbtstat -a IPADDRESS
Tuesday, December 30, 2014
Friday, December 12, 2014
RequireJS and TypeScript
Here is an example of a RequireJS module:
To make sure this is compiling through the TypeScript compiler, the first step is to convert it to use modules from TypeScript. The simplest way is:
To compile this, you then call the compiler with the right module flag, which is AMD for RequireJS:
This will then generate the equivalent JavaScript. You'll notice it adds some extra code that's probably unneccesary, but hey, I'll take that for compile time safety:
If you're working in Visual Studio, you might get an error about it not using the module flag. If you're working with an existing codebase, you might find you'll need to add TypeScript support first - adding a new TypeScript file in VS2013 does this by adding some stuff to the CSPROJ file, namely the XML element TypeScriptToolsVersion, and will need to reload the project. Afterwards, there should be a new tab for TypeScript Build options in the project properties dialog where you can choose the module style:
Labels:
RequireJS,
TypeScript,
Visual Studio,
Visual Studio 2013
Monday, October 20, 2014
JavaScript - private variables
Here's an example of the Module Pattern, read the comments to understand how it works:
So, this solves the problem of having a private variable that we don't want to expose. Now lets see an example of a "class" in JavaScript (note: future versions will have class constructs built into the language, I'm just showing how people do it today):
This works, but the property 'firstName', is being used by the getName function, and is public. This means we can just override the property.
How would we create a private property in this case? Well, what if we try the same concept of scoping things to the execution of the constructor function, first attempt:
The function now doesn't have access to the variables, so what if we move this into the scope of the constructor... second attempt:
At first glance, this seems to work, but we actually override the prototype each time the constructor runs... bad! Instead we should rather be defining the function on the actual instance being created:
This then solves the problem of keeping the variables private to each instance. One downside to this then is that each instance is referring to its own function, and not sharing one common function on the prototype, taking up more memory, but giving the advantage of private scope.
For some extra reading on scopes in JavaScript, read this - http://javascript.crockford.com/private.html
Another similar way of doing this is with the Revealing Prototype Pattern, explained in Dan Wahlin's post here - http://weblogs.asp.net/dwahlin/techniques-strategies-and-patterns-for-structuring-javascript-code-revealing-prototype-pattern
Labels:
JavaScript,
prototypical inheritance,
revealing module pattern,
revealing prototype pattern,
scope
Subscribe to:
Posts (Atom)