VTdotNET August Meeting Recap – Ali Aghareza on Threading

dotNET

 

Vermont.Net’s August meeting featured a fantastic presentation on Multi-Threaded Applications in .NET by local .Net plumber, Ali Aghareza. Ali has a weblog, by the way where he posts some awesome tidbits.

Although threading is a very complex topic, Ali knows it inside and out. This was his very first time presenting, but because he knew the topic so well,the presentation and demos and his ability to answer any question, was fantastic.


I think one of the most valuable parts of this presentation was that Ali explained some of the areas where you couldl really get yourself in trouble if you didn’t know what  you were doing and showed some demos of the funny effects that could be had by what seemed like reasonable coding.

We also learned a few cool tidbits. Ever notice that EVERY single class, method and function in the .NET Reference starts off with a sentence about thread safety? Ever pay any attention to that? If you are manually doing threading, you definitely should! We learned about background threading, safepoints and how the machine is involved with this whole process.

It was definitely fascinating – impressive to watch him do all the coding on the fly as well – and I was so impressed by the talk, that I have recommended that he do this at Code Camp II!

We will put his slides up on the user group website soon.  Go to the VTdotNET site’s Past Meetings page to get his powerpoint deck.

A couple of notable points about this meeting. Although it was on one of the very rare NICE nights we have had this summer, there were still 20 people there (I was surprised) and more impressively there were 5 totally new people that had never come to a VTdotNET meeting before!

Next month (Sept 20th) Michele Leroux Bustamante is coming as part of a northeast tour thanks to INETA. She will be talking about HTTP Handlers in ASP.NET. I saw part of this talk on a webcast she did during ASP.NET Week on the MSDN Webcasts, but had to cut out early. So that will be 2 plumbers in a row at Vermont.NET. Very nice.

(wierd format of this post is because I can’t left align images. When I do, they don’t appear.. so I used a table, but that’s all goofy too)

Longhorn buzz

Just Rambling

So far, I’ve only seen positive feedback on today’s Longhorn announcements by .net developers in the blog space. I am not referring to any Microsoft employees, but regular developers. From what I’ve read, developer feedback had a role in this decision. Biggest gripe was waiting for enough “longhorn capable boxes” on the market to make developing Longhorn (as planned) viable anytime soon. This will now change.

update – finally seeing some WinFS mourning. I can commiserate with you guys. I didn’t have anything planned (so I can wait) …just excited about the possibilities of it.

Private & Public Keys

Just Rambling

I give up – I want to call private keys “locks” because there’s only one and then public keys can be keys because it’s a different entity than a private key and can be duplicated. Isn’t that easier to understand?

So when you are signing, you put your lock on the message and anyone who has the key can unlock it. And they know that it’s ONLY from you because those keys only work on that one lock. [BTW – you are not literally locking the message. It’s more complex than that. The message is not actually safeguarded, but with digital signatures, you have a mechanism of letting the recipient compare the message they received with the message that they were supposed to receive, which is a little digest you created and locked up and sent along with the message. They are not unlocking the message, but this digest. Then they do the same thing to the message that they received that you did in creating the digest. The digests should match. All that we achieve here is determining if someone tampered with the message on the way. If so, you dont want to accept it.*]

When you are encrypting you only want one person to read the message. So you attach a key, that anyone could have, but it only unlocks ONE lock. That is the lock of the designated recipient. So only that person has the lock that they key fits into.

Well, although you can’t stretch the analogy too far, it still works for me.

*see??? I can explain it in my own words now!! BIG GRIN!