Posted by lee jones on Jun 3, 2014 in JavaScript
Referencing angular partials from a jade view I recently ran into a weird problem whereby I couldn’t get a jade template to reference an angular partial using the ng-include directive. I assumed it was as simple as passing in the relative path to the partial view as per: div(ng-include="/partials/featured-courses/") 1 div(ng-include="/partials/featured-courses/") or: div(ng-include='partials/featured-courses') 1 div(ng-include='partials/featured-courses') but this was just completely ignored by Angular – I could see from Firebug that no HTTP request was even being made for this file, so I knew there was some syntax issue here. So I googled it with Bing, as you do, and found this StackOverflow article entitled ‘JADE templating engine does not render ng-include‘. As the answers specify, there’s an odd syntax to getting this working. I followed the guidelines and it worked. The syntax is as folows: div(ng-include='\'partials/featured-courses\'') 1 div(ng-include='\'partials/featured-courses\'') I have no idea why this particular syntax is required – if anyone knows, please feel free to drop me an email and I’ll update the...
Read More »
Posted by lee jones on May 22, 2014 in JavaScript
I was recently playing with a node.js and Express application and ran into a small issue that wouldn’t let me render any templated content to the client. The issue was presenting itself in a number of ways, firstly: The first error I was getting was: app.configure(function() { ^ TypeError: Object function (req, res, next) { app.handle(req, res, next); } has no method ‘configure’ If you look online for express documentation, most will be using the app.configure syntax. However, as of version 4.0.0 of express, the app.configure method has been removed. See here (these release notes) for more detail. Looking in my package.json file I had the dependency for express set to latest: JavaScript "dependencies": { "express": "latest", "jade": "~1.3.1" } 1234 "dependencies": {"express": "latest","jade": "~1.3.1"} This is inherently dangerous for this very reason. As node and express are evolving so quickly, the likelihood of breaking changes between versions is great. The quick fix for me was to enforce an older (compatible) version that I know worked with the rest of the app: JavaScript "dependencies": { "express": "3.4.0", "jade": "~1.3.1" } 1234 "dependencies": {"express": "3.4.0","jade": "~1.3.1"} Then, once I rolled back the version of express (this is only a test app – the forward thinking thing to do would be fix the now obsolete code!) I started getting the following error: Error: No default engine was specified and no extension was provided This is strange as I clearly had specified a view engine: JavaScript app.configure(function () { app.set('view engine', 'jade'); app.set('views', __dirname + 'srv/views/'); }); 1234 app.configure(function () {app.set('view engine', 'jade');app.set('views', __dirname + 'srv/views/');}); After searching online and reading lots of solutions (most related back to daft errors like this transpired), I started to doubt the validity of the error message. Turns out that it was in fact the path to the views folder that was failing and it was nothing to do with the view engine (jade) at all. A quick fix to the path and everything started working: JavaScript app.configure(function () { app.set('view engine', 'jade'); app.set('views', __dirname + '/srv/views'); }); 1234 app.configure(function () {app.set('view engine', 'jade');app.set('views', __dirname + '/srv/views');}); The simplest mistakes often cause the biggest headaches. Despite its rapid change/release cycle and constantly battling with new versions and breaking changes, I do love the ‘bare metal’ feel of programming in...
Read More »
Posted by lee jones on Feb 28, 2014 in JavaScript
If you dabble a bit with node.js in your spare time you may have noticed that as of Feb 27th 2014, NPM no longer works. If you look at the output from npm, you will probably see the following error: npm ERR! fetch failed https://registry.npmjs.org/connect/-/connect-2.13.0.tgz <strong>npm ERR! Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN</strong> npm ERR! at ClientRequest.<anonymous> (C:\Program Files (x86)\nodejs\node_modules\npm\node_modules\request\main.js:525:26 ) npm ERR! at ClientRequest.g (events.js:192:14) npm ERR! at ClientRequest.EventEmitter.emit (events.js:96:17) npm ERR! at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1462:7) npm ERR! at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:111:23) npm ERR! at CleartextStream.socketOnData [as ondata] (http.js:1367:20) npm ERR! at CleartextStream.CryptoStream._push (tls.js:526:27) npm ERR! at SecurePair.cycle (tls.js:880:20) npm ERR! at EncryptedStream.CryptoStream.write (tls.js:267:13) npm ERR! at Socket.ondata (stream.js:38:26) npm ERR! If you need help, you may report this log at: npm ERR! <http://github.com/isaacs/npm/issues> npm ERR! or email it to: npm ERR! npm-@googlegroups.com 1234567891011121314151617 npm ERR! fetch failed https://registry.npmjs.org/connect/-/connect-2.13.0.tgz<strong>npm ERR! Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN</strong>npm ERR! at ClientRequest.<anonymous> (C:\Program Files (x86)\nodejs\node_modules\npm\node_modules\request\main.js:525:26)npm ERR! at ClientRequest.g (events.js:192:14)npm ERR! at ClientRequest.EventEmitter.emit (events.js:96:17)npm ERR! at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1462:7)npm ERR! at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:111:23)npm ERR! at CleartextStream.socketOnData [as ondata] (http.js:1367:20)npm ERR! at CleartextStream.CryptoStream._push (tls.js:526:27)npm ERR! at SecurePair.cycle (tls.js:880:20)npm ERR! at EncryptedStream.CryptoStream.write (tls.js:267:13)npm ERR! at Socket.ondata (stream.js:38:26)npm ERR! If you need help, you may report this log at:npm ERR! <http://github.com/isaacs/npm/issues>npm ERR! or email it to:npm ERR! npm-@googlegroups.com The key is in the second line here, an SSL exception is being thrown due to the use of self-signed certificates: npm ERR! Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN After a bit of digging about I found a post on the official npm blog confirming that as of 27/Feb/14 self-signed certificates are no longer supported and that npm is effectively broken. Quite humorously, this same blog post recommends installing an updated version of npm using npm itself, which would be fine, if the entire problem wasn’t an inability to use npm due to the cert errors. Whoops! Some people are suggesting disabling SSL on npm by changing the config, but this is risky for a number of reasons, not least because that opens you up to man-in-the-middle attacks and no longer validates that you are indeed talking to the authentic npm repository. Personally I took both of these and ran the following: npm config set strict-ssl false npm install npm –g npm config set strict-ssl true 123 npm config set strict-ssl falsenpm install npm –gnpm config set strict-ssl true Here we are disabling SSL to allow us to grab the latest version of npm (which doesn’t suffer from the self-signed cert. problem) then immediately re-enabling SSL. This to me is a quick solution to this problem. The other option is to uninstall node.js, download the latest version and install that. The above option should be quickest and most hassle free I’d...
Read More »
Posted by lee jones on Sep 30, 2013 in JavaScript, SignalR
I recently met the challenge of getting SignalR to talk to a hub on a different domain to the one it was running on the client. Finding working and up-to-date information on how to do this is a challenge given the rapid release cycle of the SignalR library. This raises all kinds of security concerns as the same-origin request issue comes-to-light. However, it can be done using the following configuration. In the project file, edit the Global.asax file as follows: C# protected void Application_Start(object sender, EventArgs e) { RouteTable.Routes.MapHubs(new HubConfiguration() { EnableCrossDomain = true }); } 1234 protected void Application_Start(object sender, EventArgs e){ RouteTable.Routes.MapHubs(new HubConfiguration() { EnableCrossDomain = true });} This instructs the SignalR ‘server’ component (i.e. the hub) to accept requests from domains other than that the site is currently configured on. Without this the request will be blocked. That’s the server side taken care of, but CORS is a major client-side security concern (although not much these days given the prevalence of client-side JavaScript services). On the client, the proxy used to communicate with the server needs to be re-directed to the new host. If you don’t do this, signalR will try and initiate a hub connection on the current domain, so will make a request to /signalr/negotiate/?_=123456789 Which will be on the same host/domain as the site is running, not the alternate domain intended to be targeted. Therefore you will need to set the URL for the client connection as follows: var connection = $.connection(window.location.protocol + "//url.to.the.server/"); $.connection.hub.proxies["hubName"].connection.url = window.location.protocol + "//url.to.the.server/signalr" 12 var connection = $.connection(window.location.protocol + "//url.to.the.server/");$.connection.hub.proxies["hubName"].connection.url = window.location.protocol + "//url.to.the.server/signalr" note: the window.location.protocol just ensures the connection retains the HTTP/HTTPS setting then, when starting the hub, be sure to tell it that it will be connecting cross-domain: C# $.connection.hub.start({ xdomain: true }); 1 $.connection.hub.start({ xdomain: true }); Once you’ve done the above, you should be good to...
Read More »
Posted by lee jones on Sep 18, 2013 in JavaScript
The more you work with JavaScript, the better you understand its nuances. One particular gotcha that forms a great technical interview question is what is the produced output from the following snippet of code: JavaScript for(var i=1; i<=5; i++){ setTimeout(function(){console.log(i);},0); } 123 for(var i=1; i<=5; i++){ setTimeout(function(){console.log(i);},0);} Obviously the result is: 1 2 3 Right? Given that the timeout is zero, so the code executes immediately doesn’t it? If fact, the output is: 4 4 4 That is because, by the time the loop exits the value of i has been incremented to 4 before termination. The important factor to note here is the single-threaded nature of JavaScript. In fact, what is happening is that the loop executes to completion before any event handlers fire (i.e the setTimeout). By the time they do fire, i===4 and therefore it is written out as per the above. In other languages such as C#, Java etc. this would have output as expected,but with JS? Nope. Understanding this is key to understanding eventing in...
Read More »
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.