Newsletters - Winter 2006

IT employment is at its highest level since 2001...

The Employment Market
by John W. Stout

It’s becoming a job seeker’s market again in IT.

I know that is probably a surprise to many readers—but it’s true. The U.S. IT job demand is outstripping the availability of qualified candidates, and that’s particularly true of software developers.

Just over a year ago, we were seeing some pretty dire predictions about the U.S. IT job market. However, according to figures from the online recruiting service Dice, since last summer programmers have been the most sought after profession in IT.

A number of industry analysts anticipate increased IT spending in 2006 and that is driving the employment push.

According to the National Association of Computer Consultant Businesses (NACCB), which represents consulting groups and IT staffing companies, January 2006 was the fourth consecutive growth month for IT employment. Per NACCB, businesses are growing in the overall healthier economy and are looking to technology as a means to improve their productivity. IT employment is at its highest levels since 2001.

This creates an interesting situation with regard to the supply of programmers and other IT professionals. In our last newsletter I mentioned the decline in U.S. college grads entering the IT profession. The numbers are down 39% in five years.

Many of you have already witnessed one way in which the demand for programmers will be filled: foreign groups are establishing U.S. offices and leasing their employees out all over the U.S. Many of these employees are on H-1B visas and are made available to work almost anywhere in the country. We get numerous phone calls from these companies and their employees offering to fill openings; if you are an employer or manager it is likely you do, too.

Stout Systems gives technical screenings to all of its placement candidates; in screening contract employment candidates from these companies, we find that the ratio of marginal to exceptional candidates is about the same as we find from other sources.

One note: although the market has greatly improved for those seeking W2 employment, that isn’t necessarily true for independent contractors. Our contractor colleagues in various parts of the country tell us that contract offers tend to be for shorter periods, that rates are often tighter, and that there is a stronger push from their clients to have them work as W2 employees—either via an agency or directly for the company. Additionally, most large companies are requiring their subcontractors—both agencies and independents—to carry high levels of expensive insurance: liability with a multimillion dollar umbrella, additional workers compensation, even errors and omissions insurance. The costs of these insurances are prohibitive to independents and even small companies, and they can be difficult to obtain.

The threat of the loss of U.S. IT jobs offshore is somewhat abated then by the current industry demand. And if it’s any comfort to our U.S. worker colleagues, in the past four months Stout Systems has been approached by clients with projects that had been offshored and were being brought back to the U.S. Each project had failed in some way, seriously enough that the offshoring strategy was being re-thought. It is becoming clear that the same problems that have plagued many U.S. development projects also rear up offshore; combine that with communication and management problems caused by trying to control work half a world away, and you have a recipe for serious headaches.

This isn’t to say that offshoring is going away—it isn’t. But offshoring is actually creating other jobs in the U.S. since there is an increasing need for project managers who can successfully manage offshore teams.

All in all, it appears we have a brighter picture for IT for the near future.

John W. Stout is the founder and president of Stout Systems. He has twenty-five year's experience in the software industry. He is also sought after as a technology speaker, presenting sessions at developer conferences and user groups. E-mail .


ASP.NET 2.0 Provider Model
by Greg Brewer

One of the promises of the .NET 2.0 framework is that developers will be able to write 70% less code to accomplish the same tasks. One of the ways that Microsoft fulfills this promise in ASP.NET 2.0 is by using the Provider pattern.

The Provider pattern itself is not new to .NET 2.0. The Provider pattern uses time-honored object-oriented principals such as abstract class, interfaces and polymorphism. It has been used in several of the ASP.NET starter kits and expanded upon in DotNetNuke and Community server projects. It is also heavily used in the Microsoft Enterprise Library.

What is new is the way in which the .NET 2.0 framework formalizes the Provider pattern with a set of classes and implementations.

The Provider pattern provides a clean separation between the API and implementations of the API. It allows other developers to provide their own implementations for an existing API using whatever technologies are appropriate for their environment. One benefit of this is that it makes it easier to integrate applications with existing systems—since a custom implementation of a Provider can be produced to tie systems together. For instance a company could use an Oracle database with an application that was designed for SQL Server by writing an Oracle Provider.

ASP.NET 2.0 ships with the Provider types and implementations shown in the table below:

Provider Implementation Shipped with .NET 2.0 Framework
Membership Active Directory, SQL Server
Role Management Authorization Store, SQL Server, Windows Token
Site map XML
Profile SQL Server
Session State InProc, OutOfProc, SQL Server
Web Events EventLog, SimpleMail, TemplatedMail, SQL Sever, Trace, WMI
Web Parts Personalization SQL Server
Protected Configuration DPAPI, RSA

In addition Microsoft has released sample implementation of the Membership, Role Management, Profile and Web Parts Personalization that use Microsoft Access for database storage.

By using the Provider model in the .NET framework, Microsoft has opened up the platform to third party Providers. For instance there are already membership and role Providers implemented for MySQL and SQLite database engines.

The implementation of a Provider does not need to be limited to just a database engine; the data could be retrieved and stored just as easily with a Web service. This mechanism makes it easy to integrate with legacy systems by wrapping the legacy system with a Web service. The ability to provide your own implementation of a Provider allows the .NET framework to compete with Java and other languages in areas where heavy investments have been made in non-Microsoft infrastructures.

Membership Provider

Since many Web applications require users to sign in to take full advantage of the application, one of the most talked-about Providers for ASP.NET 2.0 is the Membership Provider. The Membership Provider model provides an API and a set of Web controls that provide the functionality for common account-related tasks. The Provider pattern is used to abstract the implementation of the membership data storage from the membership Web controls. ASP.NET 2.0 provides the login Web server controls to allow you to implement a login, registration, password recovery, and to display user information without writing any code.

To configure the Membership Provider, like most Providers, you use a Provider-specific element in the web.config. For the Membership Provider you can either edit the web.config by hand or you can use the "Web Site Administration Tool" wizard, which walks you through the configuration. The configuration specifies the Provider implementation to use and password options such as password recovery and encryption settings.

More detailed information on the Membership Provider and the other Providers can be found in the ASP.NET Provider Toolkit.

Custom Providers

In addition to the Providers that ship with ASP.NET 2.0, Microsoft also provides architecture guidance and a set of infrastructure classes to facilitate the development of your own Provider-based services. By using Provider-based services your applications can offer the same flexibility and choices as the .NET framework.

The ProviderBase class is a simple class that all Providers derive. This class has one method (Initialize) and two properties (Name and Description). It is used to mark a class as a Provider. The Initialize method takes the friendly name of the Provider and a name value collection of Provider-specific configuration parameters. The ProviderCollection class provides the base class for collections of ProviderBase derived classes. The ProviderException class provides an exception class to identify Provider exceptions.

The steps required to implement your own Provider-based service are:

  1. Derive an abstract class from ProviderBase that defines your API. Also derive a class from ProviderCollecton to hold collections of your Provider.
  2. Provide an implementation of your Provider API.
  3. Provide configuration implementation for you Provider.
    3.1) Create a custom web.config section.
    3.2) Create a custom configuration section class derived from ConfigurationSection.
    3.3) Register the custom Provider configuration section and define your custom configuration section class as the handler for it.
  4. Implement you service, implementing code to load and initialize Providers registered with your service.

The ASP.NET Provider Toolkit shows an implementation of a custom image storage and retrieval service that uses the Provider pattern.

Summary

The use of the Providers that ship with ASP.NET 2.0 allows developers to implement more functionality with less code. Developers have the flexibility to use these Providers to integrate .NET applications with non-Microsoft and/or legacy systems. By developing their own custom Provider based services, developers have an easy way to add support for new backend platforms without rewriting entire applications.

Resources

There is an excellent article on the MSDN site from March of 2004 by Rob Howard on the Provider pattern that gives a glimpse into the history of the pattern.

Providers implemented for MySQL and SQLite database engines.

Greg Brewer is the founder and Managing Member of Vowire LLC. He has been developing software for Windows for over 15 years and is co-author of the Windows 2000 Developers Guide. E-mail .


New .NET User Group

Welcome to the newly established Ann Arbor .NET Developers Group, meeting the 2nd Wednesday of each month. April topic: 21st Century Smart Cocktail Applications with the Tablet PC.


Recent News

Stout Systems welcomes new employee Guillermo Bares (Software Engineer Consultant).


 


Current Job Opportunities

View Our Candidates

Subscribe to Our Newsletter

Stout Systems, P.O. Box 2934, Ann Arbor, MI 48106 · Voice 734-663-0877 · Fax 734-663-7659 ·
Copyright © 1995-2008 Stout Systems Development Inc. All Rights Reserved. Trademark & Legal Notice. Site Map Design by Fast Forward