Old trends aren't necessarily antiquated

I was working on rewriting an old ASP 3 application into ASP.Net 2.0 today and came into an interesting thought that caused me to look at the past 5 years of ASP.Net. Back in ye' old ASP 3.0 days, everything was inline code. Then came .Net and the trend of Code Behind files. Everything seemed good aside from the initial runtime compilation upon the site's first request. Now in the ASP.Net 2.0 world, we're blessed with the truly pre-compiled/published sites that only hold marker files in place of the traditional files that would house the mark up.

Now, looking at the history of the application that I am rewriting, this specific application tends to have a few pieces (usually just presentation layout) that requires changing on a frequent basis. Now, this is where the difference of opinion lies. Some people see these changes as a cause for a full deployment and along with that, some QA representatives would also deem that a full deployment requires a full application test (I've worked with people who demand such even if the change was only the order of text boxes). There are also others that think that one would only need to deploy only the updated files. While this seems logic, it comes with the price of having the ASP.Net 1.x initial lag once the file is accessed. In addition to the lag issue, there's also the requirement of deploying the solution in an "updatable" mode. As in most cases, this would be a trade off between security and convenience. I'll let you decide on when such a trade off is applicable.

Assuming that the convenience is agreed upon as necessary for the project, there's two ways that could accomplish this task. One is to simply replace/update the markup of an ASPX or ASCX file. While this is great, what if the UI needed to change from a drop down list to a series of cascading drop down lists to obtain the "same" value in a more refined manner?

At this point, I would advocate a full deployment in order to maintain a consistency of code (or in the case code-behind); however, curiosity got the best of me on this one. :)

Never trying it myself, I created 2 simple user controls where the code was inside of a <script runat="Server" > tag. I chose to Register the controls via Web.Config instead of directly on the page for a single location, should I find myself wanting to use the control elsewhere. Upon updating the SRC of the registration entry, the user control flips.

After doing this, I realized that it would work if I modified the user control logic a bit. Many developers create user controls that are nothing more than a segmented section of the page that houses it. This tightly couples the control to the page and is considered a bad practice in many groups. A better way is to just encapsulate the functionality of the control so it doesn't rely on any external piece of information. Yet an alternative way (and the way that arguably works best for this situation) is to create the user control where any data that would need to be passed to the page itself be exposed through properties and events. Ensuring that all controls that a person will be swapping out implement the same interface(s), the page's code behind should be able to implement the logic without a full deployment needed.

Base on this information, I'd have to argue that Code behind with a non-updatable deployment may be the best and most secure form of deployment, there may come a situation where it's not the best option.

The 4 Paths of 3.0

Microsoft.Net v3.0 has been out and around for a good couple of years now (including its days under the WinFX name) and it seems like just now people are beginning to use it. With in the past year and a half, more and more advances in development paradigms have caused the need for a better interface along with easier ways to do things. .Net 3.0 was to help in the areas of authentication (CardSpace), processing (WF), UI (WPF & Silverlight), and SOA (WCF). The 4 aspects pack a huge impact once one dives into them and applying them together makes them a true force of development.

So, if one was to start pick one up of these up, which of the 4 paths would one choose?

CardSpace:
CardSpace provides a quick and easy way to provide digital authentication. Unlike Passport, CardSpace provides better management, an easier API, and a significantly better cost structure (if anyone priced the Passport authentication licenses, you know what I mean by this). Many other bloggers view it as probably the most important piece that's getting the least amount of attention. I have a feeling that I'll be diving into CardSpace in the next few months, but not initially given some of my direct needs.

Workflow Foundation (WF):
I started reading up on WF about a month ago, randomly chosen from the 4 technologies. An embedded runtime specifically for workflows that would take compiled or xaml-based workflows was quite nice. It provided an easy interface for design and was quite easy to implement. Even with all of the benefits, WF is one that I'm going to feel is acceptable with my limited knowledge at the moment. I'll pick it back up after a bit.

Communication Foundation (WCF):
As I was researching and playing around with WF, I noticed that WCF can be integrated into it quite nicely. This, combined with recent performance statistics posed on MSDN, makes it a very nice option to learn and apply in just about any environment. Again though, I haven't truly dove into WCF and will probably do it second on my list.

Presentation Foundation (WPF):
When the first WinFX book came out, I thumbed through it and the first thing I saw was Xaml. I saw it and shrugged it off (since I was still semi-green in the ways of .Net at the time). Xaml was a strange language and I felt more comfortable honing my Perl skills before touching it. However, now looking over 3.0 and also reading more into Xaml, I must say that I wish I did discard it earlier. WPF uses Xaml (or can be generated through code) and the deeper you go into the 3.0 technologies, so does everything else. The power of Xaml is amazing and seeing how it works along with Silverlight, it truly is a remarkable language.

While probably not the most professionally practical in many current settings, I can see many companies begin to adopt WPF should their development staff become educated in such. The sheer power is amazing and becoming well versed in it has 0 negatives from what I can tell.

The Daunting Task of Continuous Education

Looking over at the technology landscape that exists today, it's easy for someone to be barraged by all the information. What do you do if you are fresh out of college or even high school and want to get into development? Where do you start? Or, in many cases, where you do pick back up if you were left behind?

I've been pondering these questions. With technologies of today and tomorrow being out there, having the skills to learn the information and also to continuously educate yourself is one of the best "skills" a person can have. In addition to be able to absorb information, I've seen it being extremely beneficial to be able to apply and present what you've learned. In the situation of presenting the topic, it assists in validating your knowledge and also easily identify holes.

Most college graduates in college are not focused on a single programming language. Colleges for the most part prefer to provide a variety to languages, which is good for a neophyte who doesn't have a preference; however, it also shows the difficulties of using college as a baseline for a developer. I switched colleges a lot when I was in school. Not all of my credits would transfer and in a few of those cases, I got to experience lvl 2 classes of many programming languages. After a couple 2nd level Java and VB classes as well as the interviews and research I've done, college really only teaches some basic File IO and possibly some DB connectivity. Some colleges DO take development courses further than this; however, many programs only get this far.

So you're a recently graduated college student with knowledge of the basics and a desire to learn more. What do you do? There's plenty of resources out there now for the Internet generation. Google, MSDN, forums, user groups, Safari, Books24x7, ElementK, and more are out there for easy learning. Their effectiveness really comes down to that of the individual. If the person learns best from reading and applying, that person won't have any troubles but what about the others who prefer examples or mentorships?

While everyone prefers a specific learning style, that doesn't mean the paths they choose doesn't have to different: same content but different means. So how does a person who knows the basics through College level 2 VB or Java get to being a skilled .Net 3.0, SOA, or basic OOP developer? How does one learn topics that are somewhat scarce due to "common knowledge"?

There are some steps that make a sense sequentially like the following:

• Basics > OOP > SOA
• .Net 2.0 > .Net 3.0
• OOP > Unit Testing

Even with these maps, it still can be a daunting task to get exposure to everything and even more of one to attempt to master any of them. The only thing you can do is take it one step at a time. No one will ever be an expert at everything since there's just too much out there; however, there are definitely those that are more skilled in a particular field. Luckily, most of those individuals in our field tend to share.

With this goal in my mind, I shall hopefully minimize my ramblings like these first couple posts have been and start putting more technical content in. If even one person find it useful then it'll be worth it in my opinion.