Okay, completely off topic from what I normally write about; but I had a chance to think today (yes, frightening isn't it?) while driving 60 miles home. As I was entering Lincoln, I noticed a black squirrel and it reminded me of a friend of mine who had one living in his tree a few years back that had a white ring around its tail. It was a very weird looking squirrel. I thought to myself, "Isn't it weird how its genetics not only made it black and white, but also made the pattern rather symmetrical and neatly placed at the end of his tail?" In my usual state of way-too-much-reflection I also realized that I, too, was the product of genetics and, in an odd way, what was going on was genetics appreciating the result of genetics (me appreciating the form of the squirrel).

I took it another step further and realized that, actually, genetics is a product of the laws of nature - and that I was nature appreciating nature - which is true in an odd, contrived fashion. The premise here is that when we look on nature and on the laws of things and notice how fascinating they are because they behave in certain ways, realize that our appreciation may simply be the result of the same thing which makes nature that way.

So, we look outside and appreciate the symmetry of, say, a snowflake; but what IS the the symmetry of the snowflake IS ALSO the producer of our appreciation of that same symmetry. Why is this important? To me this shaves away a bit of the mysiticism in regards to nature - the whole "there must be a creator for these things to happen" is somewhat nullified. The argument becomes somewhat cyclical.

I finished the rough draft for the article this afternoon and my compadres are going through it, looking for mistakes et al. I may take a break this weekend from anything related to technical writing - so if you don't see me for a day, that's why :P

I'm working on another article. I'm hoping to have it done within the week and start looking for people to publish it (I'm aiming for MSDN this time). So - that's where my spare mental CPU cycles have gone....

The conference is over and I'm really, really, really ready to get back home. I'm tired and my brain is full. I'll probably take a couple days to digest some of the information I gathered from the conference and hopefully have some interesting content to put up....see you all in a couple days....

 

I went to a fairly good talk this morning on the topic of managed/unmanaged interop issues when programming for VISTA. The core problem is that many of the development tools you'd use to program for this platform won't be ready by the time of release, and so some of the fancy .Net tools and short-cuts we're accustomed to won't be available. As a result, certain situations may require interop to the native APIs of the platform. Cases discussed included:

1. UAC-aware applications
1. User Access Control
2. Windows VISTA desktop search,
1. Integrated into the client experience in many ways
3. CommandLinks
1. The new "button" that's available in Windows VISTA giving allowance for a more descriptive text region.
4. Common File Dialogs
1. Presenting the new file dialog interface to clients.

...and so forth. The actual points made, however, wasn't of special interest to me as I believe I could find my way around them if I encountered them, but the fact that I may have to do interop to catch up to certain user interfaces was the most important "point" I took away from the talk.

 

Unfortunately I just haven't had time to totally wrap my head around all the new features coming out in the Windows VISTA security infrastructure; namely those in the firewall. One technology I'd like to look at more is the Windows Filtering Platform.

If you are interested in platform security or the firewall or anything related to these things, I would recommend checking it out.

http://www.microsoft.com/whdc/device/network/WFP.mspx
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWNE05008_WinHEC05.ppt
http://windowssdk.msdn.microsoft.com/en-us/library/ms686658.aspx

A good link for the new Windows SDK in general is here: http://windowssdk.msdn.microsoft.com/en-us/library/aea8d91a-0889-4e48-ba45-91433a191e48.aspx

I had a chance to speak with a Russ Humphries who is the Sr. Product Manager for the Windows VISTA Security team and was very impressed with this man's overall intelligence, but especially impressed with a technology called BitLocker. I dont' want to go into it at the moment as I'm a bit short on time, but it's basically a mechanism for very securely encrypting content on disk in such a manner that nobody can retrieve it regardless of their manner of attack.

Check out this site here for more information (I'll try reducing it to something more palletable later): http://www.microsoft.com/technet/windowsvista/security/bitlockr.mspx.

Clemens Vasters gave a great talk on WCF today concerning binding and contracts; I got a lot out of it even though a lot was review, but it was good review because it solidified a lot of things that were nebulous to me still. Here are some basic notes:

1. There are three basic types of contracts
1. Service: which concerns the ports, operations and behaviors.
2. Data: data types,
3. Message: which define the format of the message on the wire.
2. There are three ways to talk:
1. One way: send the message and "forget" about it,
2. Request/Reply: where there is a request .... wait ..... response model,
3. Duplex: most easily thought about in terms of "callbacks"
3. One way requests are important because they're effecient. If the protocol is reliable that it's being sent on, you don't ahve to worry about it not getting there...you can send the message and forget about it. This is a good choice for several solutions.
4. Duplex is back channel, callback based.
5. Take note of "Channel Builder",
6. You can declare the back channel as [OperationContract(IsOneWay=True )]
7. Take note of "Dispatcher"
8. Duplex: [ServiceContract(Session=true), CallbackContract=typeof(IMYCALLBACKTYPE)]. The IMYCALLBACKTYPE is the interface the client is going to be using to reach the methods to call back.
9. Fault tolerance:
1. [FaultContract(typeof(SOMETYPE))] .....
2. ......
3. throw new FaultException<SOMETYPE>
1. These things are handled as soap exceptions
10. If you wish to work on the actual XML format, use the XMLSerializer
11. Bindings:
1. BasicHTTPBinding: "Old style"
2. WSHTTPBinding: "New style". Secure, reliable.
3. NetTCPBinding: Becoming very fast, almost as fast as COM+/DCOM. Instant firewall feedback/ NAT feedback.
4. NetNamedPipeBinding: maximum performance, same machine, on windows.
5. NetMSMQBinding: robust, reliable, queue-based transport.
6. MSMQIntegrationBinding: integration with old-style MSMQ applications.
7. NetPeerTCPBinding: for building peer to peer meshes.

The remainder of his talk was very informative, but difficult to express here as he went through particular case scenarios. This was an excellent way of seeing these protocols actually walk and therefore very a very expressive way of showing how to use the various binding types and why.