Awkward Coder

I've blogged before about hosting web services created with Web API inside a test fixture in .Net, what follows is the same idea but in this case hosting a node.js implemented web service, this is using the node.js server I created in this previous post. Jumping straight to the solution this is what I came up with: As you can I've managed to reduce the amount required to be specified for each test fixture to 3 parameters: working directory for node.js server, full path to the node executable,  node server name and any arguments (note the port number). The implementation detail has been pushed into the base class - WebServiceIntegrationFixtureBase. Before showing the implementation for this class, the test runner & fiddler outputs are shown below: The base class implementation is shown below, as you can probably guess this uses the Process class from the System.Diagnostics namespace: Loading .... As you can see there isn't much going on, the...

I needed to build a mock back-end web service this week because the middle-ware team wasn't ready (they're useless standard Java 'enterprise' developers) and @Jason challenged me to write it in node.js . He showed me an example of how this was done before and said it shouldn't take more than 5 minutes to have something up and running, I've done this kind of requirement previously in Web API and thought it would be interesting to finally do 'something' in node. All coding contexts have been changed to protect the innocents :) The requirement was for a web service returning JSON defined resources and the idea was to map the request URL to the local the file system, where the actual content to be returned is contained in a *.json file and the actual file-name represent the HTTP code to be returned, some examples are show below: 'http://localhost:1008/examples/user/1' maps to 'd:\work\node\resources\user\1\200.json' 'htt...

Currently I'm working with some UI code which has a ' domino effect ' when a property changes on a view model - the data is being rendered in a tree view, and the reason for the ' domino effect ' is because the value of a node in the tree view is an aggregation of multiple child nodes (leaf nodes hold the actual values which are aggregated up). The dataset is dynamic, it can be updated during it's visualization and when this happens we want the ability suspend NPC events being fired until recalculating all the aggregates has completed. I have the following base class for all bind-able (view model) classes: What I wanted was the ability to prevent  suspend the firing of the PropertyChanged event and then resume later, I wanted to do this via a single new method exposed on this class and the return type would IDisposable and importantly it should reference count when called multiple times without being disposed. I wanted the ability to do something similar...