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:
- Derive an abstract class from ProviderBase that defines your
API. Also derive a class from ProviderCollecton to hold
collections of your Provider.
- Provide an implementation of your Provider API.
- 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.
- 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).