Tech Ed Day 4 - Hands on Labs and Virtual Tech Ed

I was due to attend a session today in one of the Interactive Theaters (which is kind of like a seminar, rather than the lecture-like Breakout Sessions) called Why Software Sucks, but as I got there it was far too full. All seats inside were taken, people were sitting on the floor, and the crowd at the entrance was about 5 or 6 deep (and all were taller than me), so I could neither see the slides and white board, and could barely hear the man speaking.

So I went to try my hand at one of the Hands On Labs, soft of like interactive computer based learning. You sit at a dual screen PC and have a document on one screen telling you want to do, and (in this case) a copy of Visual Studio on the other where you can work.

I first tried the Introduction to LINQ, as this has sparked my interest this past week. However, I soon found that this example was in VB.Net, not C#. No matter, I thought, I'll try it anyway.

So I tried to get to grips with the VB syntax, but after nearly 4 years of C# it's really not nice. I thought I'd pick up the basics from it, but the syntax is different so there wasn't much point. Plus, the section I really wanted to do (an example of using LINQ to SQL--which is using LINQ as a high-level method for accessing databases) wouldn't work as the example Northwind database wasn't installed on the machine I was on.

So not much luck with that one.

So I tried the Introduction to the Windows Communication Foundation. I can't remember the exact name, but it was pretty much that. This was in C#, so it was looking better from the start.

I found this to be a pretty well laid out introduction to WCF. It walked you through the steps of setting up the "Contract" (or interface), and hosting this both in a console app (or potentially any .exe process, like a Windows Service), and on IIS.

From this example it's clear that the actual code you write is relatively simple. There's a bit of a ball ache you need to go through from the client side in order to consume the service though. You have to run a command line utility to generate the proxy code and then add this to your project, but maybe this is integrated into Visual Studio 2008, or will be included as an addon to 2005 eventually.

The difficult work is in the configuration files. You need to specify all the things that will make the channels work here instead of in code. But this should be resolved if you follow the Stock Trader example previously mentioned this week, which shows how to load this information from a centralised database.

After this I stopped by Virtual Tech Ed, which looks to be a large projector screen playing interviews with various people who may or may not have hosted sessions. I didn't see it from the beginning, but my attention was drawn to a talk about developers and security.

There are certain things you can do in code that make it easy for a hacker to gain access to your system--common things like script and SQL injections for example. Instead of relying on the developer to know about all the latest hacking methods being employed, this talk was about treating security like just another programming component.

For instance, if you're writing a web application and you need the user to enter some text information, you'll use an ASP.NET TextBox, you don't write your own text box. Likewise, you don't create your own encryption algorithms--you use ones that are already available.

So why does the developer have to know every single way to secure their systems if there are utilities and components out there that can do it for you?

The product highlighted that can do this is called DevInspect, from SPI Dynamics. I've not tried it out, but the sales pitch was certainly interesting. It was said that this tool can not only tell you when you are doing something wrong, it will tell you the right way of doing it. I'm sure there must be alternatives to this particular product, but what I found interesting is the concept of handling your security this way.

As with everything security related you can't, of course, rely on just one counter measure, and you can't expect any one component to tell you exactly how to do something the right way.

But if we can use tools like this to highlight where vulnerabilities lie, then it's one less thing to worry about. It can only make our own systems, and our customers' data, more secure.