WHAT I READ–Update

March 21, 2012

I am still engaged in the reading initiative, but haven’t been doing daily posts primarily out of laziness.

I have spent the last several days reading this book:

http://www.amazon.com/NET-Parallel-Programming-Experts-Voice/dp/1430229675/ref=sr_1_1?ie=UTF8&qid=1332305884&sr=8-1

There’s a lot to TPL. The book really dives into all of the details. I’m very pleased with it, and I’m learning a lot. There are some things that I probably won’t ever need to do, such as writing my own partitioner, but now I know what that is, how it works, and how to write one if I wanted to.

It covers the built in locking primitives, explains the difference between the old ones and the Slim ones, and gives examples of each one in progress. It covered BlockingCollection<T>, which I hadn’t used before.

Chock full of useful info. It’s immediately valuable.


DevDash Update

March 21, 2012

Nope, I haven’t forgotten about it. Progress was slow for a few weeks due to being pretty busy at work. But, I’ve been able to get some time in recently.

I spent a lot of time yesterday creating some batch files to create a TEST ENVIRONMENT on your local machine. It creates a directory structure that contains three nodes and the hub. Basically, it’s just three copies of the code base, each with a different configuration file. The HUB is all of the same code as the nodes; there’s nothing special about it. It’s just that it uses a different Unity Container so it loads different things.

This setup allowed me to thoroughly test several aspects of Node/Hub communication and failure recovery, and make sure that the website is showing reasonably up-to-date information. The website works by polling, so there’s always some latency, but you always know what’s going on.

The HUB and NODES can start without each other. That’s normal for the HUB, as it is the hub, but for a long time there a node couldn’t start unless the hub was up. One of the reasons for this is the WS-DISCOVERY behavior that comes with WCF. It’s a real handy behavior that will announce the services to discovery server, but only if the server is up. If it can’t get to it, then the service host throws an exception during startup, and the service doesn’t start.

That’s no good. I don’t want the service to not start just because the discovery server isn’t available. I eliminated the behavior and wrote a DevDash ANNOUNCE scheduled task. Every 20 seconds it attempts to announce all of the services. Once the announcement is successful, it increases the scheduled interval to 10 minutes. (The task fires immediately on load… it doesn’t wait the 20 seconds for the first attempt.)

There’s another scheduled task that sends a HELLO message from the node to the hub. This is service independent. The HELLO messages just says “hidey ho good neighbor”. The Hub responds with either “HEY, YOU’RE BACK!”, or “WHO THE HECK ARE YOU?”. If the response is WHO THE HECK ARE YOU, then the node makes sends another message stating “THIS IS ME, AND HERE IS EVERYTHING YOU NEED TO KNOW ABOUT ME”. At that point, the node becomes KNOWN, and subsequent HELLOs will received a HEY, YOU’RE BACK! response.

A key feature of DevDash is that all of the nodes keep in sync. The hub has all of the live assemblies in a distribution folder. There are two sub folders: SERVICE and APPLICATION. The SERVICE is DEVDASH itself and all of it’s services and tasks. APPLICATION contains node-level functionality, such as all of the out-of-the-box widgets, and new ones that you write for your own needs. The assemblies in the application folder are loaded into their own app domain so that it exists with, but outside of, the main devedash appdomain.

If files in that structure is changed, DevDash broadcasts to the nodes, and the nodes initiate a synchronize. They each download all of the latest assemblies, then determine if a restart is needed. A restart can occur at either the SERVICE level, or the APPLICATION level. This is initiated by an event on the local bus. When the synchronize is complete, it publishes an event. Elsewhere, a subscriber of the event initiates the restart.

The sync/restart feature is pretty cool. It took a lot of work and testing, and is solid at this point. I fire up all three nodes, then redeploy an assembly (changing only the file version number), then watch the nodes drop off the status page and reappear a few seconds later with the new version number. Yes, I get a little giddy. The restart works for both the server console application, and also the windows service.

It’s coming along. The TODO list gets longer every day, but the TODO NOW list continues to get shorter. I have rudimentary admin pages to just get things to work. You can break them if you tried. I have one more such page to create, and that will be it for the TO DO NOW list, as far as development.

I just installed ScrewTurn WIKI on my server. I’m going to start documenting things, but that could take weeks. It’s really a lot of work for a one-man show, but I’ll just keep picking away.

I only have 9 days left to work on this. I made a self commitment to try to write a book this year, and I can’t push it much longer. I’d like to get DevDash out there and maybe get some people to help with it if anyone has any interest in it as a learning tool, or as an actual product. My goal with it has been to finish something, which I did, and learn some new stuff along the way.