Sunday, 22 April 2012

Actions and Funcs (part 3).....Func as Selector

Hello again.
This post is the third in my exploration of the usage of Actions and Funcs in building more expressive syntax for libraries.  So far, the posts in this series are:

1. Actions and Funcs.....Intro
2. Actions and Funcs (part 2).....Actions as Builder

So, another cool simple usage of Funcs when designing an API are as a selector.  Funcs provide a nice way to select one of many options while still providing a smart default.  So lets jump into some code:

The small console program above shows a selection of an enum (Color) for a Brush.  You can see in the ChooseColor method we send in Color.Yellow as the default.  This allows us to select the input parameter itself as the Color with the first selection line brush.ChooseColor(c => c);. In the second selection line brush.ChooseColor(c => Color.Red);, the Color.Red is selected. As expected, this program outputs:

Choose Default: Yellow Color Selected: Red Press <enter> to close.

When seeing code like this for the first time, I was confused. I thought, "What exactly is returning a value?". Then I found out a cool piece of syntactic sugar built into Func<T, T>. Basically, if the implementation of the Func<T, T> is a single line (so what is on the right-hand side of the => operator), the compiler will place a return before the code for you. So after compiling brush.ChooseColor(c => Color.Red); becomes brush.ChooseColor(c => { return Color.Red });. This allows for much cleaner and expressive code for examples like this. By the way, if you want a multi-line Func<T, T> then it will require the curly braces.

Well, that is about all I have this time. I think this is a cool little example of where Func<T, T> can make code expressive in a different way and might provide another option when designing a class that selects a value type like Color. Hope this helps.

Tuesday, 10 April 2012

Actions and Funcs (part 2).....Action as Builder

Following on from my last post about Actions, Predicates, and Funcs; I want to provide an example of one place that I've seen a framework successfully use an Action as in an API.  Recently, I've been doing some work with NServiceBus (NSB).  NSB gives a nice terse way to Send or Publish a new message.  It looks like this:

This code uses an Action<T> underneath to create a new instance of the type that is going to be sent or published.  What is extra cool about this is that NSB allows you to define values for properties of an instance that it will dynamically generate.  Like the example above, this allows NSB to give the impression that it can assign values directory to interface properties!

So, how can we allow users of our API to define properties, but keep hold of the specifics about how we create an object?

Action<T> as Builder
Like NSB, we can take in an Action<T> and allow the user of the API to build the object they desire.  To show the specifics of how to do this, I'll complete a non-production version of what NSB does.  So, first we need to define the IBus interface:

And this is a simple implementation for IBus:

A bit of explanation
So, it turns out that the code is quite simple for a pretty cool API feature.  The implementation of IBus only needs to understand the type of the message, then can create a blank instance, and pass the instance to the action for building.  At this point, the action implementation (defined in the method call to IBus.Publish<T>) takes over and fills in all the properties.  This works because T has to be an IMessage (which means it must be a reference type). Nice.  Using this type of technique would also allow the framework code to make a default instance (with some properties set) and let these values to be changed during the action implementation.

More to come...

Thursday, 29 March 2012

Actions and Funcs

For a long time now, I have been wanting to better understand Action<T>, Func<T1, T2>, and Predicate<T> in C#.  I have always understood that they are generic delegates, but I never could get where they are most appropriate to be used when designing a library or framework for other developers to use.  I did see examples in libraries like linq, AutoMapper, and RhinoMocks where I thought the usage of Actions or Funcs as extension points made a lot of sense.

So, with this in mind, I'm planning to devote a couple of posts about an exploration into Action<T>, Func<T1, T2>, and Predicate<T>.  Hopefully, by recording this journey I'll take more from it and even perhaps help a few other developers to better embrace these tools.

In this post, I just want to do a quick introduction to what Action<T>, Func<T1, T2>, and Predicate<T> are.  As I mentioned, these classes seem to be just another way to express a delegate in C#.  So why are they needed?  There seem to be many answers to that question.  First off, they allow for lambda expressions in C#, they are much more terse than anonymous delegates, and in my opinion they express a function pointer in a more direct way than a traditional delegate.  Plus, they are fun and make code more expressive.

Action<T>, Func<T1, T2>, Predicate<T> and delegates for that matter are just function pointers.  They allow functions to be passed around in code as data.

The place where most people have seen this the most is with C# events.  An event needs a delegate type in order to know what type of function it can register.  Then when you register that OnLoad event for example, the compiler will only allow a callback method to register against the event that conforms to the correct signature.

In the above example, we are defining a delegate with the common .NET event signature void (object sender, EventArgs e). This comes in handy when we want to wire up a callback function that will listen out for when the event fires.  Underneath, the complier is going to make a new collection of OnLoadHandler delegate types and add (+=) or remove (-=) callbacks from the collection.  Then when the event is fired, the collection will iterate and call all the registered functions.

So, events is one place that many developers are familiar with delegates.  Since Action<T> is a void returning generic delegate, can we use it instead.  Yes, and here is the code:

As you can see, we have eliminated the need for a delegate to be defined in the Page class.  And what is better, we got rid of that Page.OnLoadHandler scoping issue when we registered the event.  The Action<T> can be registered against the event and all the functions stay roughly the same.  This is pretty cool, however, with EventHandler<T> out there not that useful.  This is more of an example to get warmed up for more to come.

Alright, got it
It's easy to see what is going on here.  Action<T> allows us a better way to express a delegate.  So now it's time to define these guys.

Actions are delegates that always return void.  Each generic type defined (and in the same order) become the type of the parameter in the function.

Func<T1, T2>
Funcs are the most expressive generic delegate form.  They take at least two generic type arguments because the last one is always the return type of the delegate signature.  So, in this case T2 is the type that you want to return.

Predicates are Funcs that always return a boolean value.  All of Predicate's generic type arguments define the parameters in its delegate signature.

In the next post, I'll dig a bit deeper into some more typical usages for API design.  See ya then!

Saturday, 17 March 2012

First node.js unit test with nodeunit

Well, my little practice app has a few features now.  In fact, it is already getting a bit out of hand.  If I'm going to add more to it, I need to treat the project with a little more respect.  So, carrying on from my last node.js post about a simple module, I'm going to add a unit test.  Then, I begin the journey of placing most of my controller logic in modules (carefully) and unit testing everything.  Then, I can start to develop with much more confidence.

There seems to be a few unit testing frameworks out there for node.js.  So far I've checked out Expresso and nodeunit as well has having a glance at vows for a more BDD approach.  For this project, I'm choosing nodeunit because it seems like it will do the job and I like the syntax a little more than Expresso.

Nodeunit Install
Like most every package, nodeunit installs very smoothly with npm.

npm install nodeunit -g

In my environment (ubuntu), nodeunit needed to be globally installed (-g) in order for the nodeunit command to be available on the command line.

First Test
The first test I'm going to write is going to make sure that my format method in the dateFormatter.js module is working as expected.  So I first created a directory for tests (mkdir tests), then I added a new file named dateFormatterTest.js into the new directory.  Here is the code for the test module:

I've got my /tests directory on the same level as my /modules directory so I just go up a directory to require the module I want to test.

First Test Run
So, I'm ready for my first test run.  nodeunit will run all the tests in a directory so I can just type nodeunit /tests in the root directory to run the test.  And here is the result:

Looks good.  Now I'm ready to start breaking this thing up and adding more tests.

Friday, 9 March 2012

Who logged on? Get the source IP of a windows session

I've been looking after a few servers in a virtual host that is stretched for resource.  I started to notice that merely by the fact of many people logging on to the servers (and forgetting to log off) resources were being taken up and slowing down the entire virtual infrastructure.  Each login would spin up a few more services on the server and slowly deprive the rest of resource.

qwinsta and rwinsta to the rescue!
Two tools that are built into windows and often overlooked are qwinsta and rwinsta.  qwinsta will query the server for all the sessions (active or disconnected) that are registered on the server.  rwinsta will allow you to reset a session (again active or disconnected) by the session's id.  These tools have been invaluable for me to see if there are any sessions on the servers and be able to clean off the disconnected sessions left open.

qwinsta /server:<server name>

And then you can use rwinsta using the ID to kill the session:

rwinsta /server:<server name> 1

Administrator, who are you?
This left me with another problem.  As you can see somebody logged on as the local Administrator account and then left the session open.  How can I get the source IP address for this disconnected session so that I can track down who done it?  Enter CAD_UtilPack.

The CAD_UtilPack (free version) is a rich tool set for doing all sorts of admin tasks.  Inside there is a tool called ENVTSCIP.  This tool can easily be configured on a server to log the IP of someone requesting a new TS session, perfect.

*Disclaimer: I don't think I have to say it, but what comes next is not supported and not even tested that well.  But I did get everything to work on my Windows Server 2008 R2 box.

Ok, well now we have the tools.  I'm going to log all the connections and qwinsta info to the file C:\temp\logons.txt, then I'll be able to look up a logon and correlation the qwinsta ID.

To do this, I need to:

  1. Create a script to run at windows logon
  2. Edit the registry to include my script
  3. Drop the logon script and the ENVTSCIP in  %SystemRoot% \System32\ directory
  4. Sit back and wait

So, this is my registry script (tslogon.reg):

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Userinit"="C:\\Windows\\system32\\userinit.exe, C:\\Windows\\system32\\tslogon.cmd,"

The userinit.exe was already in the registry so I'm just appending the tslogon.cmd to what exists already.

Here is the script that runs at logon (tslogon.cmd):

%SystemRoot%\System32\envtscip.exe >> c:\temp\logons.txt
echo %DATE% %TIME% >> c:\temp\logons.txt
echo. >> c:\temp\logons.txt
qwinsta >> c:\temp\logons.txt
echo. >> c:\temp\logons.txt
echo. >> c:\temp\logons.txt

This script is going to run ENVTSCIP from the %SystemRoot%\System32\ directory, log the date and time, and finally log out the current qwinsta result.

Finally, I create a logons.txt file in the C:\temp\ directory and give write permissions to everyone (yes not the best idea, but this is only a first stab).

I see you...
This is now what I get logged when the local Administrator logs on:

09/03/2012 17:42:08.99 

 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE 
 services                                    0  Disc                        
>rdp-tcp#0         Administrator             1  Active  rdpwd               
 console                                     3  Conn                        
 rdp-tcp                                 65536  Listen  

You can see that ENVTSCIP gives us the WTSClientAddress, and qwinsta gave us the session ID when the session was initiated.  From there I can do an nslookup on the IP and get the machine name of the user that made the session.

Yes! However, there is some set up here.  I scripted the install and it was pretty easy to roll out, but I'm still not convinced this is the right solution.  Anyone know of a better way?

Thursday, 1 March 2012

WCF: Tracing the Raw SOAP XML

Recently, I needed to get a look at the actual SOAP message that was being sent between an app and a web service. Back in the .asmx days, I remember having to through a proxy between the app and the service, but WCF now allows for much better message inspection. This is done through the SvcTraceViewer.exe tool that ships with the Windows SDK.

The SvcTraceViewer, if configured correctly, can give you both the activities take place during a service call and the message body itself.  Using the config in the here, you only get the activities.  Here is the configuration if you want both the activities and the message body:

The initializeData attribute on the sharedListener node will define the log file that you want to create with the trace information.  Then you are ready to run your trace.  For my set up, after I run, I see an Accounts.svclog file appear in the root directory of the application.  This file can then be opened by the SvcTraceViewer.exe and analysed:

If you see the 'Received a message over a channel' and 'Received a reply over request channel' then your config is correct.  Now its time to figure out if the message coming back is correct!

Monday, 27 February 2012

simple node.js module

Recently, I've been looking at node.js just to see something completely different than .NET.  In doing so, I'm building a small web application on top of express with jade.  Disclaimer: I'm not a javascript developer.  So, this for me is about both learning more about javascript and checking out alternative technologies.

I recently wanted to format a date in node.js like this: dd/MM/yyyy hh:ss.  There may be a better way to do it, but I decided to create a dateFormatter.js module so that I could see how to reuse some javascript code in node.js.

My first thought was that I needed to expose a new javascript object DateFormatter with the method format(d). Makes sense right?

So I set off by creating a file named dateFormatter.js that looked something like this:

And no, it didn't run at all.  Like I said, not great at using javascript in an OOP way!

What I didn't understand was that modules in node.js are wrapped as objects for you.

So by using the exports. I was really defining the public interface of my object.  So, I changed the code to this:

And then I reference and use it like this:

At the moment, this works for me.

Saturday, 25 February 2012

.NET Application Performance Degrades Over Time

So what do you do if your .NET application performance degrades over time and you don't know why?

There could be lot of reasons for a slow down over time. Anywhere from a slow memory leak to anti-virus. The best you can do is try to build evidence (data) about what area of the application to look first. Try not to talk it over with many devs because everyone will have a different opinion about what might be wrong. Get the data!

How to get the data:

perfmon perfmon is your friend. There are a lot of counters that you can look at (system wide as well as process specific). So you can start by profiling the big 4 (that's memory, disk usage, cpu and networking). There are a lot of posts out there about what counters are best, so I won't go into too much detail about the perf counters here.

windbg If you indeed see that memory is growing and not being collected it's time to bring in the big guns. .NET is great at abstracting memory usage away from developers, but this means we have to get underneath .NET sometimes to find out what is not allowing the Garbage Collector to do its work.windbg with the sos.dll (managed extensions) is a great tool for this. The hardest part of windbg (in my experience) is just getting the sos extensions loaded properly. You have to pay close attention to what target architecture (64 or 32) you are analysing and what CLR version you are running on.

procdump procdump by sysinternals is a great little utility to take memory snapshots from a running process. These snapshots (.dmp files) can then be analysed by windbg.

sos The sos.dll has shipped with the .NET Framework since v2. With v4, Visual Studio 2010 has integrated sos and allows you to analyse .dmp files!

The sos commands for memory leaks that I have found most useful are:

!eeheap -gc (overview of what is in each generation of each heap)

!dumpheap -min <size> (dumps out all objects and types, over a particular <size>)

!dumpheap -type <type> (dump out all objects of a specific <type>)

!gcroot <address> (prints out a stack so you can see what parent object is pinning in the GC)

!do <address> (prints out memory of a specific object)

Some other pointers:

Usually, you want to snapshot memory under load, so it would be good to have some way to simulate that from outside the system. So, it is good to get this running ahead of time and even work it into the QA process for the application.

For performance problems it is usually best to take regular snapshots over time with a running application. Then you can compare the snapshots when you analyse.

Well, that was a bit longer than I intended, but hopefully worth it!