HTML5 and the Future of the Universe

Web site people are always catching up. You get involved in an extended project and by the time you're done, they've changed the rules again and it's time to learn a new technology. I used to think this was a problem. Now I see it as a responsibility to manage the information of an ever expanding set of hardware devices that are becoming digital.

As these digital devices become of age, they mature into a web access point because of the value it adds to the device. Some devices like tablets are born with the ability to talk to the web at birth. Others, like DVD players, had to wait until they grew up.

HTML5 and CSS3 are expanding to fill the needs of the digital appetites of these new devices. As we innovate to market test a device at every screen size possible from phone to tablet to TV, the older development technologies will continually be updated until they break. So far, HTML and CSS are holding their own. CSS not so much. Even the old dog, JavaScript, is doing well but has some sturdy jQuery and CoffeeScript crutches.

The raft of programming languages not originally focused on the web that try to manage that environment push the simple text retrieval process to be more app like. In their desire to improve the unique asynchronous request-response communication model, they, in my mind, will eventually destroy it. Face it, it's slow. You can do faster communication with AJAX which is why you see Google using so much of it on their web apps. It's why jQuery Mobile designed their GUI library for speed with AJAX so much that it's the primary communication model that tolerates the web request model.

Now a newer model of finer grained I/O control in JavaScript is starting to appear called the WebSocket API. Did you not see this coming? It's not the end until each language has a way to use a simple library of functions/methods to talk to any device of your choice.

Languages are shifting little in popularity. A recent TIOBE trend announcement showing that the iOS platform language of choice, Objective-C, has been the faster gainer over the last two years to take the #3 spot on the chart, is the only major change. With Java trending downward and losing the lead to C, a venerable stalwart, I'm not seeing where anybody is picking up the slack. C# is on a slow trend upwards but not that much. Even php is losing ground.

My guess is that JavaScript is picking up the slack from reading language popularity articles. You can run a survey of projects on StackExchange and Github and find out that JavaScript has the top ranking there. Hacker News put JavaScript in the top three as well with Python and Ruby taking the top spots. Even job rankings on Dice.com show JavaScript in the top three to get a better sense of real world usage. Book sales from O'Reilly put JavaScript at #2 showing a mix of business and hobby use.

The next step for JavaScript would be to revive the server side version of the language and make it as available as php is for Apache. Then the major languages would write APIs to talk to JavaScript and we would have a programming interface for the web. Oh, yeah, and somebody do something in JavaScript to make CSS easier to work with. LESS is a good start.

So, if you are a web person, the future of the web looks like it centers on web application development and JavaScript is taking center stage. APIs will be promulgating and JavaScript/jQuery/minor language support plug-ins will be promoted. One of the APIs that is next on my bucket list is YQL. I think with the first book out on YQL in a few months from O'Reilly, we'll see an interest in mining the data of the web from JavaScript languages.

Excuse me now, I have to get back to the future and read about what's coming so when I start working again I won't be too far behind.



By: Doug Hoff

An Analysis of Normalization Through the Eyes of the Developer - Part III

View Part II

Paraphrasing E.F. Codd’s First Normal Form, it states that there should be, “No repeating groups”.  The language column is the group in this example, below you will find the proposed design implements this rule, while the original design does not.

Original design

(Products table)

ProductID	Name	English	Spanish	French	Italian
1	Ceramic tile	1	0	0	0

Proposed design

(Products table)

ProductID	Name	LanguageID
1	Ceramic tile	1

(Language table)

LanguageID	Name
1	English
2	Spanish
3	French
4	Italian

Consider the original design and the proposed design above.  The proposed design removes all of the hindrances that the original design put into place.  Normalization frees the developer from handling issues, because those issues are simply not present.

Problem 1 solved:  Suppose the business expands into a German speaking market, in the original design a column must be added and populated with a “0” for all current and subsequent records.  In the proposed design, simply adding a fifth record to the language table is the only task that needs to be done.

Problem 2 solved:  Keeping data clean is much simpler in the proposed design.  If a product needs a different language, simply change the LanguageID field in the Product table.  In the original design, this would, as best, involve altering data in two different columns.

Problem 3 solved:  In the proposed design, there is no need to store data that is essentially keeps track of the language that the product is not.  In the proposed design, if a product is not associated with a language, a record simply does not exist.

I hope this blog has shown the benefits of simple normalization.  Making the decision to architect even your simplest of applications with normalization can guard against unforeseen complications, while keeping the focus on the business need.

- Ed Dressler, SQL Server Expert; CTT+, MCDBA, and MCITP LinkIn with Ed

Cloud Intelligenece Conference: Keynote Speaker Announced!

Centriq Training is pleased to announce Paul Mattes, Microsoft U.S. Director of the Windows Azure Platform and Technical Computing, as the 2012 Cloud Intelligence Conference Keynote Speaker!

This one day conference will be held on April 12, 2012 at the Overland Park Convention Center. 

Mr. Mattes' Microsoft teams are responsible for working with customers and partners to identify and deliver solutions based on Microsoft’s cloud computing assets and High Performance Computing software. He has over 25 years experience in a diverse set of disciplines including software architecture and engineering, data center operations, enterprise sales management and strategic business consulting. Learn more about him here.

This event is ideal for IT professionals, business decision makers and executives from all types of technology backgrounds. Some topics will include Public Cloud, Private Cloud, Hybrid Strategies, Cloud Security, Virtualization, Migration and Information Architecture. Seating is limited. To learn more or register for this event, please visit www.centriq.com/CloudIntelligence.

For questions or more information on the event contact your Account Executive at 913-322-7000.

- Jessica Oliver, Director of Operations LinkIn with Jessica

An Analysis of Normalization Through the Eyes of the Developer - Part II

View Part I
 
This design is also inefficient because it puts a task in the middle tier developer’s hand that a normalized table would already be designed to handle, more to the point, a normalized table would have avoided the problem all together.  I am speaking here of adherence to the first normal form.  The current design would require the developer to manage all data going into all four language columns, per product.  This may include building a subroutine to ensure that only one of the columns in the language family of columns is a “1” and the rest are all “0”s; or manually auditing the data to ensure this; or even worse doing nothing to audit this data and running the risk of having dirty data spread across multiple columns.  A normalized solution allows SQL to naturally avoid this expensive, unnecessary development work, and all future data cleansing work.  Having multiple columns for each language also brings forth the issue of query performance to get the data out.  If the previous inefficiencies are acceptable, the development effort and speed of all queries built against this non-normalized table is guaranteed to become an issue in this design.  There is no quick way to return all records for one specific language in the current non-normalized design.  More importantly, any query that is designed to return the needed data with always be a distance second, performance wise, to a query for the same data built against a properly normalized table.  You are doomed to always have inferior query performance.


One last major issue with this design is the excess space this non-normalized design leads to using.  With one column per language, and four languages, you are essentially saving 3 pieces of data that each say, “I am irrelevant.”.  What a waste!  I am reminded of a former manager who told me once during the architecture of a notification system, “I don’t want to get an email that tells me there is not a problem.”.  The more columns that get added, the more you are guaranteeing wasted space.  As for the argument that states, “Well it’s not that much wasted space, it’s only a bit column.”, how do you think it might be perceived if the accounting department made this argument, “We know we are wasting money, but we’re only wasting a little money.”?  If that is not compelling enough look at it for the ratio of wasted space, in this case we are increasing the necessary data space requirements for this piece of data by 300%!

In Parts I and II, I have pointed out a common development scenario, and have highlighted three shortcomings or on implemented, non-normalized, solution.  In part III, I will propose a normalized solution that eliminates these shortcomings, and saves the developer time, increases application performance and reduces data storage requirements.

View Part III

- Ed Dressler, SQL Server Expert; CTT+, MCDBA, and MCITP LinkIn with Ed

Centriq Announces Cloud Intelligence Conference

We at Centriq are pleased to announce, along with Microsoft,  it will host the 2012 Cloud Intelligence Conference to be held at the Overland Park Convention Center on April 12, 2012. 

This one day conference will cover a variety of powerful network computing information management strategies for businesses of all levels. Some topics will include Public Cloud, Private Cloud, Hybrid Strategies, Cloud Security, Virtualization, Migration and Information Architecture.

Attendees will have the choice of four tracks, with 4 sessions each, in the 2012 Cloud Intelligence Conference including:

• Cloud Roadmaps and Overviews for Executives
• Infrastructure as a Service (IAAS)
• Software as a Service (SAAS)
• Platform as a Service (PAAS)

This event is ideal for IT professionals, business decision makers and executives from all types of technology backgrounds. Seating is limited. To learn more or register for this event, please visit www.centriq.com/CloudIntelligence.

For questions or more information on the event contact your Account Executive at 913-322-7000.

- Jessica Oliver, Director of Operations LinkIn with Jessica

An Analysis of Normalization Through the Eyes of the Developer - Part I

I was reminded a few days ago of how important it is to have a solid understanding of normalization and why it is so important to implement.  I would like to take some time to share that with everyone, especially developers. 
 
Twice now, recently, I have been pinged by frustrated people asking me to help solve their SQL problems.  I asked both what the exact problem was and how it was that they thought I could help.  The root of both problems was bad normalization.  That is, functional normalization had not been done.  What follows is a case study of one of the situations including analysis of what went wrong as well as implementing basic normalization to address the current issue and avoid future issues.
 
One of the frustrated developers was put in a position to bolt on functionality that had never been planned for in the original application.  This is certainly not a new phenomenon, but is evidence why developers need to understand functional normalization (maybe even more so than DBAs). 
 
So what was the issue and how could it be avoided?  The application needed to add language support for each one of its products.  So now products would have a language associated with them, presumably this need arose from the company spreading into global markets.  The developer decided to add a separate column for each supported language, in this case four. If the product was a "Spanish" product, the Spanish column would be set to 1 and the other language columns would be set to 0.  Some of us see the problem inherent in this design already, but for those who don't, read on.
 
Before I continue, let us be clear, this proposed design change to support the new function will work!  Function can be achieved on a broad spectrum of efficiency.  The purpose of this blog is not to discuss the viability of inefficient design; it is to highlight what can be gained by efficient design.
 
First, let’s see how this design is in fact inefficient.  Anytime a design choice guarantees a need for redesign in the future, it is by definition inefficient.  Having a column for each language almost ensures that redesign will occur.  What happens when support for a new language is adopted?  Redesign, albeit simple, never-the-less, redesign.  “Oh, no, we are only going to support four languages.”, I don’t buy it.   I’m willing to bet something like this was said during the initial design, “Oh no, we will not need to support other languages.”.  Function will change, plan for it.
 
There are two other main inefficiencies as well as their resolutions that I want to discuss.  I will add those points in future additions to this blog post.  Check back for the follow-ups and conclusion to this, basic but highly impactful discussion.  Until then, stay thoughtful.

View Part II

- Ed Dressler, SQL Server Expert; CTT+, MCDBA, and MCITP LinkIn with Ed

The Web’s 4 Hats & an HTML5 Overview - Part II

Designer

The designer in me wants to have my great user interface so well integrated into the data and processes that you don't notice. And I want it to be beautiful. That hat wasn't the one the standards committees were wearing when they proposed the gradients and transforms. Misguided blink spans and easy marquees have been put to death as many times as Freddie and Jason but keep coming back for more. Now we have them again, only this time a little more well dressed. I really don't even like the drop shadows but some of these will look much better to the high-res tablet crowd.

I am happy with SVG support and the graphics we can do, but where is my visual SVG graphics designer integrated with HTML and CSS? Android was the last to jump on the SVG graphics bus and most of the rest of the cheesy effects have partial support so I know I will be trying out Inkscape and SVG Edit when I need.  Or I'll just sit back and let the widgets take over for me like the SVG based Chart control in Visual Studio and jQuery plugins.

I find the most pleasure with web fonts, especially Google's public accessible fonts and having Web Squirrel give me everything I need to do it on my server. I can talk to the device to get info I need to deliver a pleasing layout with the @media queries. And when I need that old-timey newspaper look, there's multi-columns, but I fear it's a retro feature that will be better left alone due to the complexity it creates for the layout.

Surprisingly, I think the designer ended up with some of the best improvements. Colors are better defined both with more names and flexible opacity. The video and audio elements will have to wait for the patents to become less profitable while we find a common standard to work with. The dominance of the iPad will force me to encode a different way but I don't like it.

Businessman

If you want to know who is going to win the HTML5 battle, you just have to follow the money. And the hat in charge of the money is the businessman. This hat is the hardest to wear since it requires you to not think technically and focus on the customer. Does the customer really want what we think is geeky cool warez? Probably not.

I liked the idea of doing a survey of the currently used names for divs and classes in the wild in order to understand how people used HTML. But what were we supposed to do with that? Did I really want a better element because I was really happy with just calling my div a wrapper in the id and not a section. You want me to recode it? When?

What helps me make money? Coding faster. Reusing other people's code. If all you do is rename things, then it's going to get in my way. Now if you make it easier to find elements in CSS by adding better selectors, I'm not going to complain but it is looking more and more like a grep or regex language these days.

I can reuse other people's code if they've marked up what I want to use and now we're back to microformats because what I want is not generic text groupings that are or aren't related. What I want are finer granulation on the most common business entities which is exactly what the microformats do.

Other types of useful abstraction that will be faster or give me critical information are the new communcations APIs like Web Workers or Web Sockets and the ability to let me work offline with session or local storage when paired with the page caching. Geolocation is just a one-trick pony but had to happen when you start moving yourself around instead of sitting at the same IP day after day. And the database storage on the client will improve the user experience for offline as well.

Conclusion

People want a desktop application experience on the web and want it whenever they want it there. People have to have it easy and that means the developers as well as the users. So will I use the semantic markup? Probably. It will help me as a programmer. Will I use the <canvas> and other graphic elements? Probably not. I like SVG and JavaScript generated graphics as long as I don't have to write it. I can use Adobe Edge or other visual programs for that. Will I use the features that aren't well supported like drag & drop and datepickers where I can use jQuery and jQuery mobile to get standardization now? Obviously not.

The 2-D and 3-D graphics are incredible and not in my realm as a web developer but if you are a game developer that wants to leverage the e-commerce platforms of the future like the Apple App Store, Android Marketplace or possibly the Amazon juggernaut commerce system, then you must develop using <canvas> because it's the fastest and standardized.


As to why standards groups like the W3C and WHATWG don't move too fast, it's because you have four different groups of people all lobbying for their view. The DBA had the upper hand in the last version and now the designer and the engineer seem to be dominating. But like a real business, it's the dialog that is important to crafting a best solution for the whole. Let one company or one hat take over and it would be an impending fail.

The businessman is going to take you to that application experience that you so want. And he will charge you for it and pay you to develop great apps for it. The standards committees don't think like businessmen so you'll need to see what people are really using, really need, and get paid for. My best bet is to watch Google for how they use search data and to watch Amazon for how they will use their e-commerce platform. Of course, you'll also be watching Apple and Facebook as app delivery leaders. Then code for it and enjoy.

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

The Web’s 4 Hats & an HTML5 Overview - Part I

I recently returned from speaking at a conference in Kentucky where I ended up putting on four hats and seeing HTML5 and the future of mobile computing differently each time. I was struggling with trying to figure out why standards committees take so long to come to an agreement. After all, the vision of the web is clear, right?

Why did we get off the XHTML superhighway and jump on the scenic route where we ignore the bumps and potholes of bad syntax and limited metadata? What kind of folks are driving the bus right now and are they really going the right direction? Should we stay on the bus while we head into Mobileville? I've decided that the questions you pose are at least if not more important than the answers you think are right. Because that tells you what your vision is and if you've followed a little of this blog, you know that strategic vision is important.

The four hats are:

• The Engineer - who likes all of the functionality logically thought out
• The DBA - who likes the the data well defined and stored
• The Designer - who likes to deliver an emotional message to the customer
• The Businessman - who makes sure the customer is happy and they make a profit

Those four hats have led me to not watch the standards groups as much as watch Google and Amazon for what to use in the future that people want. The real vision of the web is to make money by giving computer users what they want. Waiting for standards groups won't get you there. After all, the current prediction is that CSS3 will be completely standardized by 2022.  Here's a rundown of the first two hats:

Engineer

As a software engineer and instructor of many students who become programmers, I know that the web has become populated with these folks that want to turn it into an application environment. That way they can program for it and make it do their will. The back end servers are full of Java, C#, and php and that same force is heading to the browser with JavaScript.

I see the HTML world being altered so that these variable manipulators can have better code and read each other's functions easier. The push in HTML5 towards meaningful naming of the loosely typed datatypes that were divs and spans is going to give programmers a better handle on what it is they are talking to. The code will become less dependent on ids and more dependent on setting up the HTML with the proper element names like <mark>, <time>, <progress>, <meter>, <details> and some of the more argued over names like <style scoped>.

I can see where the types of activities previously handled by JavaScript are being pushed into HTML. This reduces the language down to one, slightly more complex, language. Do we want a merger here of interests? Is the MVC principle being corrupted and should we really mix our text markup with programatic data validation in the same code module? The data and its validation are View Model pieces that are tightly coupled and should be handled together in my mind.

So the future lies with the ultimate merger of HTML and JavaScript and we'll have a Razor style view engine in all browsers eventually. My opinion is not to follow the same syntax and find a better way to merge the two. But the merger will eventually come. Simplified syntax for CSS3 and JavaScript have started to reinvent these stuffy languages and if jQuery can simplify CSS with a replacement like EZ-CSS, sass, or less, then we're on our way. I'm hoping it's not like node.js and stylus, but I need to try those more.

DBA

I also love to understand data and its meaningful use. Having the right field name and the right multiplicity gives me a warm glow. But I also know that too much data analysis can torture those poor programming souls who have to recombine the data for the page they work on.

Here we're not talking about the fields where programmers hand over their data after the output is available but where the data can be semantically meaningful as text. These are the domain entities and at a high level they are represented by <header>, <nav>, <footer>, <section>, <aside> and <article>.

My biggest hurdle here is knowing that the data already comes from a semantically proper framework called the database. If all the work has been done there, then who benefits by rethinking the meaningful structure one more time for the web? The only answer is that the DBA traditionally send the data to the programmers who use that "data markup" for their benefit. The field names become bundled together and as I put back on my Engineer hat, I am happy to create complex View Model types for my View, the web page.

But it's reinventing the wheel when there's a database and it's better for team coding experiences to have more readable code. But wait, is there a web service that might be looking for my article elements? Not yet in the HTML5 way. If you are looking for a current semantic framework of entities, you have to look no further than Google's recommendations. The microformats they recommend carry much more weight for reasons to mark up with them than just a standards board. People are using the schemas for reviews, events, organizations, places, restaurants, recipes, etc. without even knowing about it but you are losing out on having Google process your data and provide search results with it if you don't.

The XHTML push that we unceremoniously dumped was a DBA's dream for a perfect interface language between data source and data consumer. The problem was that it's not a homogenous set of data. Our web DBA's don't work under the same domain and the complexity made it uncomfortable to work with so many needs and choices that we found had already been solved with another data model. Or two (relational and objects). We didn't need a third (XML).

To be continued...

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug

Managed Code Inside of SQL Server

What roles do you perform as the DBA for your organization?  Many times we find ourselves doing data related tasks that are thrust upon us because of software acquisitions, executive level business requirements, or a myriad of other reason.  Whichever the case, we end up working on some common repetitive tasks and some very specific unique ones.  One of those specific tasks that you may find yourself needing to implement is using managed code in your SQL environment. 
 

This article is not for everyone, that is to say managed code integration is not a common task like backup or index management, rather it is for administrators who find themselves in one of the following two situations; a) you have applications in your environment that were developed and supported in house, and/or b) you work closely with those who develop code to enhance or modify 3rd party applications.
 

In a typical n-tier application, we have front end code, business logic, and the data repository.  In fact we could have a data repository that supports many different front/middle tiers.  In such a case, we could develop stored procedures, triggers, or functions, on the data layer for shared use at the application layer.  We have heard the benefits of centralized administration of networks from Microsoft for years, we can think of the aforementioned approach as centralized development.
 

One problem that could arise from this approach is that an application may (and likely will) already have code written in it for its own use.  Therefore developing it again at the data layer, is time consuming, costly, and may have scaled down functionality due to the limitations of T-SQL.  SQL Server 2008 has the ability to create, what I will term as function “proxies” that are created inside of the SQL Server environment, but are defined in managed code.  Now, if your development team has developed some function that their application needs and placed it into a DLL, you as a SQL professional can centralize that function by simply calling a SQL Server function that calls out to that DLL for its implementation. 
 

Whether the reason for using this feature, is applying centralized coding, or combating the limitation of the data developer not knowing the same business logic specifics that the application developer knows, or that managed code is more capable of handling the business logic tasks than T-SQL, or leveraging the skills of each area of your business to minimize the development cycle – accessing managed code is a great option to explore.
 

Assume your business line is the building of bridges and you frequently need to calculate the density of steel at various elevations.  You may have this function defined in one of your applications on the middle tier, and you may find that you now need to access that function from different applications and possibly inside SQL Server.  Without managed code integration, you would have to recreate the body of the function inside of SQL server or inside of the other application.  You now have the ability to create the function inside of the SQL environment, point the body of the SQL Server function to the DLL function, and simply consume the SQL function, as you normally would.  Of course, there is a little bit of “wire-up” code that you need to provide, as well as some re-architecting from the application standpoint.  You may find the benefit of the code existing in one place makes implementing managed code worth it.  However, a cost analysis to determine if this change would be of benefit would have to be conducted.  However, designing code in the first place to be able to benefit from this capability is a great way to move forward without the cost of retooling any current code.
 

The specifics of how you chose to implement this feature are as varied as the infrastructure of your company, but the benefits of now being able to reuse .NET developed code inside of SQL server is a great way to reduce total cost of ownership in a measurable way.

- Ed Dressler, SQL Server Expert; CTT+, MCDBA, and MCITP LinkIn with Ed

Awesome HTML5 Tutorial & More!

Due to a Linked In reference, I discovered this wonderful tutorial on HTML5 by Mark Pilgrim. - http://diveintohtml5.org There are several reasons to like this, but most of all, I like the font selections. For old eyes like mine, this makes reading an absolute pleasure. 

Another thing I found is the Video chapter (Chapter 5 – Video in a Flash http://diveintohtml5.org/video.html ) This has a fantastic explanation of how all video on the web works, or should I say, the different “container” formats. 

Finally, and this was the reason for the reference from a friend, if you are an “old” hand in the business, and remember the days of Apple II, you will enjoy the video at the bottom of the video.html file.

- Leslie Koorhan, .NET Expert; MCT, MCSD (.NET), MCTS, MCDBA, MCPD LinkIn with Leslie

Managed Code Inside of SQL Server

What roles do you perform as the DBA for your organization?  Many times we find ourselves doing data related tasks that are thrust upon us because of software acquisitions, executive level business requirements, or a myriad of other reason.  Whichever the case, we end up working on some common repetitive tasks and some very specific unique ones.  One of those specific tasks that you may find yourself needing to implement is using managed code in your SQL environment. 
 

This article is not for everyone, that is to say managed code integration is not a common task like backup or index management, rather it is for administrators who find themselves in one of the following two situations; a) you have applications in your environment that were developed and supported in house, and/or b) you work closely with those who develop code to enhance or modify 3rd party applications.
 

In a typical n-tier application, we have front end code, business logic, and the data repository.  In fact we could have a data repository that supports many different front/middle tiers.  In such a case, we could develop stored procedures, triggers, or functions, on the data layer for shared use at the application layer.  We have heard the benefits of centralized administration of networks from Microsoft for years, we can think of the aforementioned approach as centralized development.
 

One problem that could arise from this approach is that an application may (and likely will) already have code written in it for its own use.  Therefore developing it again at the data layer, is time consuming, costly, and may have scaled down functionality due to the limitations of T-SQL.  SQL Server 2008 has the ability to create, what I will term as function “proxies” that are created inside of the SQL Server environment, but are defined in managed code.  Now, if your development team has developed some function that their application needs and placed it into a DLL, you as a SQL professional can centralize that function by simply calling a SQL Server function that calls out to that DLL for its implementation. 
 

Whether the reason for using this feature, is applying centralized coding, or combating the limitation of the data developer not knowing the same business logic specifics that the application developer knows, or that managed code is more capable of handling the business logic tasks than T-SQL, or leveraging the skills of each area of your business to minimize the development cycle – accessing managed code is a great option to explore.
 

Assume your business line is the building of bridges and you frequently need to calculate the density of steel at various elevations.  You may have this function defined in one of your applications on the middle tier, and you may find that you now need to access that function from different applications and possibly inside SQL Server.  Without managed code integration, you would have to recreate the body of the function inside of SQL server or inside of the other application.  You now have the ability to create the function inside of the SQL environment, point the body of the SQL Server function to the DLL function, and simply consume the SQL function, as you normally would.  Of course, there is a little bit of “wire-up” code that you need to provide, as well as some re-architecting from the application standpoint.  You may find the benefit of the code existing in one place makes implementing managed code worth it.  However, a cost analysis to determine if this change would be of benefit would have to be conducted.  However, designing code in the first place to be able to benefit from this capability is a great way to move forward without the cost of retooling any current code.
 

The specifics of how you chose to implement this feature are as varied as the infrastructure of your company, but the benefits of now being able to reuse .NET developed code inside of SQL server is a great way to reduce total cost of ownership in a measurable way.

- Ed Dressler, SQL Server Expert; CTT+, MCDBA, and MCITP LinkIn with Ed

Recommendation: CODE Magazine

I recently got a renewal to CODE Magazine.  This great magazine has really good articles for developers, and the source code in the magazine is color-coded, just like it is in the Visual Studio editors.  They also have sample code available on their website that you can copy for projects as well.

In the most recent issue, Jan/Feb 2011, they have an interesting article by the publisher of the magazine, Markus Egger. The story covers the Windows Presentation Foundation (WPF) and Silverlight ListBox. In the article, Markus shows that by using styles and templates you can turn that ListBox into almost any representation of multiple items that you can imagine. It is really fascinating and something I think that every WPF/Silverlight developer should know. In fact, if you are still doing Windows Forms, and really needed convincing that it was time to switch to WPF, this should do it. 

Another recommended article for reference is Getting Started with Windows Phone 7 Development. 

- Leslie Koorhan, .NET Expert; MCT, MCSD (.NET), MCTS, MCDBA, MCPD LinkIn with Leslie

Google Chrome and Auto Postbacks: What You WON'T See When Testing ASP.Net Apps

One common way developers transform a static web page into a dynamic web page (one that could contain different content based on varying circumstances) is by writing logic on the web server that essentially "generates" the HTML code that is needed.

Perhaps the ASP.Net code for my homepage is set to include a certain banner image if it's Friday, but a different banner for all other days of the week. When you visit my website, your browser is making a request to my web server. The web server checks the day, and only then sends the appropriate HTML code back to your browser. If today is Friday, you'll see my Friday banner at the top; otherwise you'll see another.


This is because the web server will send different HTML code based upon the circumstances. You can literally see the difference in this HTML code if you use the View Source feature in your browser on a Friday and then again on another day. It's different code being "translated" by your browser into content on the page.

Now, one of the most common ways in ASP.Net applications to dynamically update a page that’s already been requested (barring the use of AJAX) is to let the user make some choice that causes an auto postback. This means that you are already viewing a page in a browser, but something causes a new request to be made to the web server and it "re-generates" the HTML code for this same page, essentially updating it with new content.


For example, I might create a DropDownList that contains options for different headings to display on a page, then set the DropDownList's AutoPostBack property to true, and set its default event handler (SelectedIndexChanged) to display the heading chosen from the DropDownList. This configuration will cause an auto postback when you choose a different option from the drop down box on the page - meaning another request back to the web server to update this page. The web server will generate the appropriate new HTML code and send it back to your browser, where it will be reinterpreted and you'll see the new heading displayed.


Sample Code for an auto postback
Click on either image below for sample auto postback code. The first is the aspx page. The second is its aspx.cs C# code-behind file.

ASPX page code - auto postback example

ASPX.CS code-behind page - auto postback example



This is a very common technique. And for ASP.Net developers testing their application, it would be common not only to verify the browser screen has updated as expected after an auto postback, but also to use the View Source feature of the browser to see how the new code was generated.


Common Browser Handling of auto postback and ViewSource
Below is an example of the browser screen and View Source HTML code in Internet Explorer 8, before and after choosing an option from the dropdown list and causing an auto postback. Most browsers will display this behavior.

Common browser handling - Screen and ViewSource at initial page load:



Common browser handling - Screen and ViewSource after auto postback:



Notice how in the second image, after the user chose "Wacky Heading" from the dropdown list, two things happened? The heading changed in the browser screen, and the View Source window reflected the updated code that had been sent back from the server.


Google Chrome Handling of auto postback and ViewSource
But if you're using Google Chrome, the View Source won't show the updated code. Unlike all the other major browsers out there, Google Chrome does not actually update the HTML code that its View Source displays when you "post back" to the same page with updated code. It will still show the code generated from the first request to the web server (as in the "is-it-Friday-or-not" example above), but if there is an auto postback that results in different HTML code for the page, Google Chrome's View Source will only show the original HTML code, which is very misleading. The page you see in Chrome will update (say with the new "Wacky Heading" chosen from the drop down list) but if you view the source, Chrome will still be showing the originally requested HTML code file.


Google Chrome handling - Screen and ViewSource at initial page load:



Google Chrome handling - Screen and ViewSource after auto postback:



I'm personally still a big fan of the Chrome browser for many types of browsing, but ASP.Net programmers should beware of this bug when testing.

***2011/09/30 Update:

Note, since this post was created, Chrome appears to have "gone legit" in regard to its implementation of the View Source feature, and handles the process in the traditional way now, updating the source after postbacks. (Thanks to the screenshots from the original post, though, you can still see the behavior for a browser that handles postbacks in this way. Incidentally, you'll still see this type of behavior in any browser where an asynchronous JavaScript postback manipulates the DOM behind the scenes, and the View Source fails to be updated.)

- Eric Reid, Design Expert; CTT+, ACI (Adobe Certified Instructor), ACE (Adobe Certified Expert), i-Net+, IC3 LinkIn with Eric