Some of us are bleeding edge. Others, well let's say that the sight of blood makes them faint. As a software engineer, one shouldn't fear the edge and must walk on it every so often in order to bask in its amazing glory. The glory of being pioneers in technology. I'd like to help others dive in. The water is fine. The technology is cool. In this section, I'm going to cover building a very simple website. Those familiar with the HelloWorld type of examples, we will do an ASP.Net 2.0 hello world. First we'll need to create the website. First you select an ASP.Net website, then you must pick the language.
Once you get used to some of the new features and play around with your hello world app. You will then want to run it to test it. The default setup for the web applications (at time of the RC release) does not automatically configure the web.config file. Luckily, VS prompts you for it and creates it for you (see below...). 
One thing to notice is that it doesn't run in IIS. I haven't truly tested it, but I assume you won't even need IIS to develop a web application. I thought that was cool. If you think about it, you could in theory develop an application on the same IIS machine and not worry about IIS configuration conflicts. For those who have done ASP.Net development on shared machines know exactly what I am talking about. You'll know that the system is running its
own web server process when you see the icon in your system tray (see below...).
Does it compile? Does it run? Good. Now how to I do something simple as publishing it? With the 2003 version, you would deploy it to an directory via file share or front page extensions using the copy method. It is a little different in VS 2005. In fact, you may initially be a bit frustrated hunting for it. The copy in the new version is more of a synch file process in case you are transferring your files (including sources). To deploy the site, use the publish web site option by right clicking on the web project.
Using the publish options, you will see that there is a target location that is prescribed for you. If you select the ellipses "..." you will have additional options (see image below and subsequent image).
You have various mechanisms for deploying the site. You even have the option from the IDE to create the web application folder so that you do not have to perform the extra IIS administration task. (Note that running framework versions side-by-side will still require this.) 
If you try and attempt to navigate to the published location, you will probably get an error like so. With most initial ASP.Net 2.0 options, you should immediately verify what framework version is associated with the published location. If you are running frameworks side-by-side, you could be running in the context of the previous framework version. A utility most of us should know by know is aspnet_regiis. You can do this via the commandline to upgrade it to the respective version. (tip: keep scrolling...there is another way!) 
After installing .NET 2.0 you will notice something different about the IIS admin tabs on accessing web application properties. There is now a tab at the end that allows you to pick the respective framework version. As an alternative to aspnet_regiis, simply pick the target framework version.
Voila! Say hello to my little friend! ;)
As an application architect, I constantly want to make sure that the "construction work" is going just fine. As I go through checklists of requirements, I can verify if we have code coverage over the system components and design specifications completed. When I feel we don't, I have to dig in to the internals and perform code/feature reviews with engineers. Even if we do have complete coverage, as time permits, I'll review code and provide tips on how to be better engineers for some and learn from others. In either case, I use the code reviews and "comments" together as a method to ensure that the code reflects the algorithms and improve future maintainability of the system.
I've always stressed commenting and, regardless of what some programmers might say, feel that it is essential to proper development when used the right way. Used the wrong way, a developer may feel that it is just another thorn in your side. The following methods are two of my favorites ways of exploiting comments in software engineering:
Aiding the Test-Driven FrontierI'm a big fan of the test-driven approach. As I write my stubs, I provide complete documentation of the software unit that I am planning to build. Along with the documentation for the stub, I'll write the algorithm behind the scenes in pseudocoded comments. I typically end with a NotImplemented exception as we all know that we haven't finished implementation yet.
Talking Through a Code ReviewWhen I review code, it helps that the variables used make sense and that the algorithm is clear and concise. The code itself becomes self-documenting. In the case that it isn't, comments come to the rescue. When sitting with one of my developers, I'll first make one pass stating what I believe it is doing. The developer corrects me if I'm wrong, and once we agree on its algorithm we document each line. One should be able to rip out all the code, leave the comments, and still be able to rewrite it based on the algorithm as described by the new comments. With a fresh set of comments in-line, we then verify the correctness of the algorithm. The unit tests updated and the world is good!