The charts are awesome… but dam! The sample code must have been written by a 1st year intern!

Microsoft Chart Controls

They require 3.5 SP1.

Ever wanted to clear text from all the text fields? Here how to do it.

Every “Web Control” with a Text property implements ITextControl. Armed with this bit of information, you can now search through your control collection and find the controls that implement “ITextControl.” Once a control is identified, it’s as easy as setting myControl.Text = string.Empty;.

Below is a simple set of methods I use to dynamically clear an entire form.

   public static class ClearText
    {
        /// <summary>
        /// Clears Text from Controls...ie TextBox, Label, anything that implements ITextBox
        /// </summary>
        /// <typeparam name="T">Collection Type, ie. ContentPlaceHolder..</typeparam>
        /// <typeparam name="C">ie TextBox, Label, anything that implements ITextBox</typeparam>
        /// <param name="controls"></param>
        public static void Clear<T, C>(ControlCollection controls)
            where C : ITextControl
            where T : Control
        {
            IEnumerable<T> placeHolders = controls.OfType<T>();
            List<T> holders = placeHolders.ToList();

            foreach (T holder in holders)
            {
                IEnumerable<C> enumBoxes = holder.Controls.OfType<C>();
                List<C> boxes = enumBoxes.ToList();

                foreach (C box in boxes)
                {
                    box.Text = string.Empty;
                }
            }
        }

        /// <summary>
        /// Clears the text from control.
        /// </summary>
        /// <typeparam name="C"></typeparam>
        /// <param name="controls">The controls.</param>
        public static void ClearCollection<C>(ControlCollection controls) where C : ITextControl
        {
            IEnumerable<C> enumBoxes = controls.OfType<C>();
            List<C> boxes = enumBoxes.ToList();

            foreach (C box in boxes)
            {
                box.Text = string.Empty;
            }
        }

Simple easy to use logging class:

/// <summary>
/// Clears Text from Controls...ie TextBox, Label, anything that implements ITextBox
/// </summary>
/// <typeparam name="T">Collection Type, ie. ContentPlaceHolder..</typeparam>
/// <typeparam name="C">ie TextBox, Label, anything that implements ITextBox</typeparam>
/// <param name="controls"></param>
public static void Clear<T, C>(ControlCollection controls)
where C : ITextControl
where T : Control
{
IEnumerable<T> placeHolders = controls.OfType<T>();
List<T> holders = placeHolders.ToList();

foreach (T holder in holders)
{
IEnumerable<C> enumBoxes = holder.Controls.OfType<C>();
List<C> boxes = enumBoxes.ToList();

foreach (C box in boxes)
{
box.Text = string.Empty;
}
}
}

/// <summary>
/// Clears the text from control.
/// </summary>
/// <typeparam name="C"></typeparam>
/// <param name="controls">The controls.</param>
public static void ClearControls<C>(ControlCollection controls) where C : ITextControl
{
IEnumerable<C> enumBoxes = controls.OfType<C>();
List<C> boxes = enumBoxes.ToList();

foreach (C box in boxes)
{
box.Text = string.Empty;
}
}

Recently on a project, the design called for only horizontal lines in a table. Being a .Net guy, I busted out the Gridview. I was able to implement everything except the removal of the vertical lines. In IE I was able to remove them via CSS. However Firefox refused to remove them:

After some digging around I came across this article: Tip : Does Firefox ignore the ASP.NET GridView border property?

In short, for Firefox to remove the vertical lines, you need to set the GridView.Gridlines property to “None.”

Recently, I discussed with a coworker the correct usage of properties.

There is some debate around properties, because if used incorrectly, they can expose the implementation of a class. And we all know this violates object oriented design principles.

A bad example: using properties as the only means to supply a required piece of data. If I have a class with 10 properties, how do I know which ones are required and in what order?

Properties should not be used to inject dependencies into the class. This responsibility rests on the constructor. However a property could be used to change a default value. For example, a database connection timeout is defaulted to 30 seconds and needs to be increased to 90 seconds. Simply setting the timeout property to 90 seconds will do the trick. The key distinction here is the class will execute without property being set. The timeout property is not required for the normal execution of the class.

Setting up the correct environmental verticals is crucial in ensuring an on time high quality product. Without them, you are doomed to a collusion of concerns. Below is the general configuration for supporting a complete product lifecycle.

Development (highly iterative)

This is THE developer’s environment. Prototyping, proof of concepts, maintenance and future features are developed here. This environment is highly unstable. Many builds happen in this environment, many are failed builds.

QA (Quality Assurance) (highly iterative)

An environment isolated from Developers and only used for testing new features or maintenance releases. Developers typically do not have access to this environment, for obvious reasons. Deployment is typically automated. This environment has the second most builds.

Integration (medium iterative)

New features are exposed to our partners to use and test. This allows the earliest possible interaction with vendors who utilized our systems. Products/solutions that many outside/inside vendors depend on may have many integration environments.

UAT(User Acceptance Testing/Staging (low iterative)

This environment is for external viewing, testing and acceptance from the stakeholders. Depending on the size of the project/company staging and UAT may be separate environments.

Production

Were the released code resides.

(I am assuming web here) Add controls to the page. Then while in design mode go to: Tools>Generate Local Resource. A resource file will automagically appear in the solution with all the controls in the page mapped in the resource file.

To create resources for other languages, append the 4 character language to the end of the file name, before the extension (Account.aspx.en-US.resx, Account.aspx.es-ES.resx…etc).

To retrieve specific entries in the codebehind, simply call this method: GetLocalResourceObject([resource entry key/name]).

Many software developers call themselves “Senior Software Engineer” or “Software Architect” but are they really? Recently I’ve meet a few people who claim to be more than they were:

An upper level manager claimed to be a “Software Architect.” On a project that was responsible for distributing millions dollars. He argued, during the design phase, against a ledger. Even after discussing GAAP compliance and ledger implementations in other accounting software, he would not budge his position.

A “Senior .Net Software Engineer” claimed the best way to send an error message via services was throwing exceptions:

public bool IsValidLogin(string username, string password)
{
    if (UserLogic.IsValid(username, password))
    {
        return true;
    }

     throw new Exception("Invalid credentials were provided.");
}

Imagine consuming this method — expecting a “false” but receiving an exception.

Determining someone’s level is somewhat subjective. Here is what I look for: First, do you understand the pro and cons of your solution? Second, do you know the alternatives and can you compare and contrast the two solutions. And third, can you explain the architecture, performance, scalability and maintenance implications surrounding your solution?

4 tenets of a great software engineer

1. Knowing your limitations
2. Continuous Learning
3. Experience
4. Understand the business

Knowing your limitations

Knowing when to saying “I don’t know” is the most important asset a developer can possess. Without it you will never seek more knowledge, you will never ask for help and you will never master your profession.

Are you reaching the edge of your skill set? Can you learn the needed skills and complete the project in the expected timeframe? Are you out of your league? Knowing the correct answer is the art.

Continuous learning

New processes or methods are created daily. If you are not appraised and adding them to your skill set, your career is dying. One study suggests that in the software industry, if your skill set is two years behind the curve, it is obsolete. If this is you, you’d better consider a different career; maybe teaching would your cup of tea.

Google is your friend. Know it, love it, and use it. It is the single most used source to find answers. More than likely someone’s already solved your problem.

Find your niche and master it. There are many learning resources:, from podcasts to blogs, from user groups to getting a mentor. This is the information age; you can learn anything you want. If nothing else you can connect with the people who share your passion.

Experience

Experience is tough. Many employers and recruiting agencies key on experience. You can be disqualified solely on the years listed on your resume.

Software is a craft and its artisans are Software Engineers. We tailor each solution to its problem.

Experience will partly determine the success of the software. An under experienced engineer can craft the best solution and fail.

Failed software projects cost companies millions of dollars and can doom a company.

The best software engineers are the ones who have an insatiable thirst for crafting software. They augment their experience by continuous learning.

Understanding the business

As one manager told me “Marketing’s job is to spend money.” Clearly this manager doesn’t grasp the concept or purpose of marketing.

Understand the value of a solution to the business. Know the problem domain and how the software fills the gap.

Software must ship. Sometimes it’s to fulfill maintenance contracts, other times it’s to meet shareholder’s expectations. This means sometimes corners are going to be cut. Accept it, live with it and develop other day.

Sometimes the process of Source Control, Branching and Versioning is taken for granted. It’s not until you get into concurrent development where the weaknesses of your process become apparent. Below is a process I’ve used in the past and continue to use at my current company. It’s saved my bacon on many occasions.

Trunk

Trunk is always the most current development. By the most current development it means Trunk is the next code branch/ feature set to be released. Once the code as been released, it is versioned and branched to the branches folder and new development is continues in Trunk.

Branches

Branches are made in two cases.

The first scenario is a previous release. Code is branched from Trunk into the Branches folder after a release. New development continues on the next version in Trunk. Keeping the current production code base in a branch allows changes to be made to production in the event of a bug.
If a bug is found in production, the branch with the production code is modified and re-released to production. The change is then merged back to trunk, assuming the same issue is in trunk.

Example:

A product’s first version is released. The source is immediately branched from Trunk to Branches as a subfolder named 1.0.0. A month into a two month development cycle a bug is discovered in production. Since we have the source code of production in Branches\1.0.0 we load that source, make the necessary changes and redeploy the code to Production. We then create a new branch from the 1.0.0 folder and name it 1.0.1 and save it to the Branches folder. If the production fix needs to be merged to Trunk we either do it manually or with Visual Studio’s merge tool.

The second scenario for branching is multiple release dates. Trunk is always the nearest release date. The ONLY reason you would branch from trunk for multiple release dates is because of concurrent development. Most product roadmaps have features for multiple versions into the future. If the work can be done in serial, then there is NO reason to branch. Sometimes making deadlines forces development to begin in the previous development cycle and if these changes cannot go out in the next release (because of completeness, security, performance, testing…etc) then you must branch the code. The key to successful parallel development is to keep the branches together as long as possible, before creating a branch. The shorter the time a branch run parallel with another the less they diverge and the easier the merge process.

Versioning

Versioning is very important. It disambiguates features between release dates. Since release dates inheritably change numbers are used to indicate a feature sets.

The purpose for the “Trunk” label is with some products the versioning label is controlled by marketing.  Once the product is released and the version number is cemented then we can label it. This happens when we branch the release.

Typically version numbers look like this: 1.4.3.1434. The first position is the major version of the product. The second position is the minor version. The third number is the build number. And last is the changeset number or sometimes referred to as a revision number.

The last number is the most important of the version number. It lets retrieve the code exactly as it was when it was built.

Example:

We have a product that was released a 1 year ago. In that time we have released 3 more versions. We no longer maintain the code and have since removed it from the branches folder.  A customer calls in with a serious problem. It turns out that they have discovered a serious security issue. We have to release a fix immediately. We look in source control. We deleted that branch 6 months ago. How do we know where to find the code and make the fix? This is where the changeset number comes in. The client sends us a copy of his product; we look at the version on the assemblies and see the last position has 928 as the changeset.  From TFS we are able to retrieve the source at changeset 928. We make the change and release a fix to the client.

Could not load type ‘System.Security.SecuritySafeCriticalAttribute’ from assembly ‘mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′.

A cause for the above error is invalid XAML. I nested an unsupported element in a ListBox and got the above compile error.