答:
This probably won't solve all the issues you mentioned, but there are two points to consider:

First, you need to place the converter code somewhere in your first strategy.  Do you consider that part of the view or the view model?  If it's part of the view, why not place the view-specific properties in the view instead of the view-model?

Second, it sounds like your non-converter design attempts to modify the actual objects properties that already exist.  It sounds like they already implement INotifyPropertyChanged, so why not use create a view-specific wrapper object to bind to?  Here's a simple example:

```<code>public class RealData
{
    private bool mIsInteresting;
    public bool IsInteresting
    {
        get { return mIsInteresting; }
        set
        {
            if (mIsInteresting != null)
            {
                mIsInteresting = value;
                RaisePropertyChanged("IsInteresting");
            }
        }
    }
}

public class RealDataView
{
    private RealData mRealData;

    public RealDataView(RealData data)
    {
        mRealData = data;
        mRealData.PropertyChanged += OnRealDataPropertyChanged;
    }

    public Visibility IsVisiblyInteresting
    {
       get { return mRealData.IsInteresting ? Visibility.Visible : Visibility.Hidden; }
       set { mRealData.IsInteresting = (value == Visibility.Visible); }
    }

    private void OnRealDataPropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == "IsInteresting")
        {
            RaisePropertyChanged(this, "IsVisiblyInteresting");
        }
    }
}
</code>```

Title: Are value converters more trouble than they're worth?

Body:
I'm working on a WPF application with views that require numerous value conversions. Initially, my philosophy (inspired in part by this lively debate on XAML Disciples) was that I should make the view model strictly about supporting the data requirements of the view. This meant that any value conversions required to turn data into things like visibilities, brushes, sizes, etc. would be handled with value converters and multi-value converters. Conceptually, this seemed quite elegant. The view model and view would both have a distinct purpose and be nicely decoupled. A clear line would be drawn between "data" and "look".

Well, after giving this strategy "the old college try", I'm having some doubts whether I want to continue developing this way. I'm actually strongly considering dumping the value converters and placing the responsibility for (almost) all value conversion squarely in the hands of the view model.

The reality of using value converters just doesn't seem to be measuring up to the apparent value of cleanly separated concerns. My biggest issue with value converters is that they are tedious to use. You have to create a new class, implement IValueConverter or IMultiValueConverter, cast the value or values from object to the correct type, test for DependencyProperty.Unset (at least for multi-value converters), write the conversion logic, register the converter in a resource dictionary [see update below], and finally, hook up the converter using rather verbose XAML (which requires use of magic strings for both the binding(s) and the name of the converter [see update below]). The debugging process is no picnic either, as error messages are often cryptic, especially in Visual Studio's design mode/Expression Blend.

This isn't to say that the alternative--making the view model responsible for all value conversion--is an improvement. This could very well be a matter of the grass being greener on the other side. Besides losing the elegant separation of concerns, you have to write a bunch of derived properties and make sure you conscientiously call RaisePropertyChanged(() => DerivedProperty) when setting base properties, which could prove to be an unpleasant maintenance issue.

The following is an initial list I put together of the pros and cons of allowing view models to handle conversion logic and doing away with value converters:

Pros:

Fewer total bindings since multi-converters are eliminated

Fewer magic strings (binding paths + converter resource names)

No more registering each converter (plus maintaining this list)

Less work to write each converter (no implementing interfaces or casting required)

Can easily inject dependencies to help with conversions (e.g., color tables)

XAML markup is less verbose and easier to read

Converter reuse still possible (although some planning is required)

No mysterious issues with DependencyProperty.Unset (a problem I noticed with multi-value converters)

*Strikethroughs indicate benefits that disappear if you use markup extensions (see update below)

Cons:

Stronger coupling between view model and view (e.g., properties must deal with concepts like visibility and brushes)

More total properties to allow direct mapping for every binding in view

RaisePropertyChanged must be called for each derived property (see Update 2 below)

Must still rely on converters if the conversion is based on a property of a UI element

So, as you can probably tell, I have some heartburn about this issue. I'm very hesitant to go down the road of refactoring only to realize that the coding process is just as inefficient and tedious whether I use value converters or expose numerous value conversion properties in my view model.

Am I missing any pros/cons? For those who have tried both means of value conversion, which did you find worked better for you and why? Are there any other alternatives? (The disciples mentioned something about type descriptor providers, but I couldn't get a handle on what they were talking about. Any insight on this would be appreciated.)

Update

I found out today that it's possible to use something called a "markup extension" to eliminate the need to register value converters. In fact, it not only eliminates the need to register them, but it actually provides intellisense for selecting a converter when you type Converter=. Here is the article that got me started: http://www.wpftutorial.net/ValueConverters.html.

The ability to use a markup extension changes the balance somewhat in my pros and cons listing and discussion above (see strikethroughs).

As a result of this revelation, I'm experimenting with a hybrid system where I use converters for BoolToVisibility and what I call MatchToVisibility and the view model for all other conversions. MatchToVisibility is basically a converter that lets me check if the bound value (usually an enum) matches one or more values specified in XAML.

Example:

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}"
</code>```

Basically what this does is check if the status is either Finished or Canceled. If it is, then the visibility gets sets to "Visible". Otherwise, it gets sets to "Hidden". This turned out to be a very common scenario, and having this converter saved me about 15 properties on my view model (plus associated RaisePropertyChanged statements). Note that when you type Converter={vc:, "MatchToVisibility" shows up in an intellisense menu. This noticeably reduces the chance of errors and makes using value converters less tedious (you don't have to remember or look up the name of the value converter you want).

In case you're curious, I'll paste the code below. One important feature of this implementation of MatchToVisibility is that it checks to see if the bound value is an enum, and if it is, it checks to make sure Value1, Value2, etc. are also enums of the same type. This provides a design-time and run-time check of whether any of the enum values are mistyped. To improve this to a compile-time check, you can use the following instead (I typed this by hand so please forgive me if I made any mistakes):

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue={x:Type {win:Visibility.Visible}},
            IfFalse={x:Type {win:Visibility.Hidden}},
            Value1={x:Type {enum:Status.Finished}},
            Value2={x:Type {enum:Status.Canceled}}"
</code>```

While this is safer, it's just too verbose to be worth it for me. I might as well just use a property on the view model if I'm going to do this. Anyway, I'm finding that the design-time check is perfectly adequate for the scenarios I've tried so far.

Here's the code for MatchToVisibility

```<code>[ValueConversion(typeof(object), typeof(Visibility))]
public class MatchToVisibility : BaseValueConverter
{
    [ConstructorArgument("ifTrue")]
    public object IfTrue { get; set; }

    [ConstructorArgument("ifFalse")]
    public object IfFalse { get; set; }

    [ConstructorArgument("value1")]
    public object Value1 { get; set; }

    [ConstructorArgument("value2")]
    public object Value2 { get; set; }

    [ConstructorArgument("value3")]
    public object Value3 { get; set; }

    [ConstructorArgument("value4")]
    public object Value4 { get; set; }

    [ConstructorArgument("value5")]
    public object Value5 { get; set; }

    public MatchToVisibility() { }

    public MatchToVisibility(
        object ifTrue, object ifFalse,
        object value1, object value2 = null, object value3 = null,
        object value4 = null, object value5 = null)
    {
        IfTrue = ifTrue;
        IfFalse = ifFalse;
        Value1 = value1;
        Value2 = value2;
        Value3 = value3;
        Value4 = value4;
        Value5 = value5;
    }

    public override object Convert(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        var ifTrue = IfTrue.ToString().ToEnum<Visibility>();
        var ifFalse = IfFalse.ToString().ToEnum<Visibility>();
        var values = new[] { Value1, Value2, Value3, Value4, Value5 };
        var valueStrings = values.Cast<string>();
        bool isMatch;
        if (Enum.IsDefined(value.GetType(), value))
        {
            var valueEnums = valueStrings.Select(vs => vs == null ? null : Enum.Parse(value.GetType(), vs));
            isMatch = valueEnums.ToList().Contains(value);
        }
        else
            isMatch = valueStrings.Contains(value.ToString());
        return isMatch ? ifTrue : ifFalse;
    }
}
</code>```

Here's the code for BaseValueConverter

```<code>// this is how the markup extension capability gets wired up
public abstract class BaseValueConverter : MarkupExtension, IValueConverter
{
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return this;
    }

    public abstract object Convert(
        object value, Type targetType, object parameter, CultureInfo culture);

    public virtual object ConvertBack(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}
</code>```

Here's the ToEnum extension method

```<code>public static TEnum ToEnum<TEnum>(this string text)
{
    return (TEnum)Enum.Parse(typeof(TEnum), text);
}
</code>```

Update 2

Since I posted this question, I've come across an open-source project that uses "IL weaving" to inject NotifyPropertyChanged code for properties and dependent properties. This makes implementing Josh Smith's vision of the view model as a "value converter on steroids" an absolute breeze. You can just use "Auto-Implemented Properties", and the weaver will do the rest.

Example:

If I enter this code:

```<code>public string GivenName { get; set; }
public string FamilyName { get; set; }

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

...this is what gets compiled:

```<code>string givenNames;
public string GivenNames
{
    get { return givenName; }
    set
    {
        if (value != givenName)
        {
            givenNames = value;
            OnPropertyChanged("GivenName");
            OnPropertyChanged("FullName");
        }
    }
}

string familyName;
public string FamilyName
{
    get { return familyName; }
    set
    {
        if (value != familyName)
        {
            familyName = value;
            OnPropertyChanged("FamilyName");
            OnPropertyChanged("FullName");
        }
    }
}

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

That's a huge savings in the amount of code you have to type, read, scroll past, etc. More importantly, though, it saves you from having to figure out what your dependencies are. You can add new "property gets" like FullName without having to painstakingly go up the chain of dependencies to add in RaisePropertyChanged() calls.

What is this open-source project called? The original version is called "NotifyPropertyWeaver", but the owner (Simon Potter) has since created a platform called "Fody" for hosting a whole series of IL weavers. The equivalent of NotifyPropertyWeaver under this new platform is called PropertyChanged.Fody.

Fody setup instructions: http://code.google.com/p/fody/wiki/SampleUsage (replace "Virtuosity" with "PropertyChanged")

PropertyChanged.Fody project site: http://code.google.com/p/propertychanged/

If you'd prefer to go with NotifyPropertyWeaver (which a little simpler to install, but won't necessarily be updated in the future beyond bug fixes), here is the project site:
http://code.google.com/p/notifypropertyweaver/

Either way, these IL weaver solutions completely change the calculus in the debate between view model on steroids vs. value converters.

Body:
This probably won't solve all the issues you mentioned, but there are two points to consider:

First, you need to place the converter code somewhere in your first strategy.  Do you consider that part of the view or the view model?  If it's part of the view, why not place the view-specific properties in the view instead of the view-model?

Second, it sounds like your non-converter design attempts to modify the actual objects properties that already exist.  It sounds like they already implement INotifyPropertyChanged, so why not use create a view-specific wrapper object to bind to?  Here's a simple example:

public class RealData
{
    private bool mIsInteresting;
    public bool IsInteresting
    {
        get { return mIsInteresting; }
        set
        {
            if (mIsInteresting != null)
            {
                mIsInteresting = value;
                RaisePropertyChanged("IsInteresting");
            }
        }
    }
}

public class RealDataView
{
    private RealData mRealData;

    public RealDataView(RealData data)
    {
        mRealData = data;
        mRealData.PropertyChanged += OnRealDataPropertyChanged;
    }

    public Visibility IsVisiblyInteresting
    {
       get { return mRealData.IsInteresting ? Visibility.Visible : Visibility.Hidden; }
       set { mRealData.IsInteresting = (value == Visibility.Visible); }
    }

    private void OnRealDataPropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == "IsInteresting")
        {
            RaisePropertyChanged(this, "IsVisiblyInteresting");
        }
    }
}


问:
How can I automate production deployments without experiencing extreme anxiety?
At our shop we use SVN for source control and CruiseControl for CI on handling automatic builds and deployments to our development, test, and integration environments.

This all works smoothly however due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment.  While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Theoretically the difference is a slightly different configuration of our app servers and the deploy script merely would have to drop the build artifacts into two servers instead of just the one, but why am I so nervous to automate our production deployments?!

I am generally not a control freak but I always feel the insatiable need to deploy production to production manually.  I have heard from colleagues that this is generally a Really BAD Thing™ but they failed to make a case against it.

I know that when I do it manually I can SEE that I am physically copying the correct files, I am physically shutting down the app servers and ensuring they closed successfully, I am physically starting the servers back up and then physically inspecting the logs to make sure it started up okay and the deployment was successful.  It gives me a peace of mind.

What are arguments against this OR arguments for automatic scripted production deployment?

答:
What I like is you can test the deployment on staging or QA and know that when you run it on prod the exact same steps will happen.

When you do it manually it is easier to forget a step or do them out of order.

ContentLicense: CC BY-SA 3.0


问:
Tools for managing a complicated project setup with many frameworks and no documentation
We have to extend a huge java project that makes use of frameworks like maven, spring, struts, freemarker and closure templates.

We do have access to source code but barely any documentation, and we have to extend this system. Our only solution is to find the place in the existing code, where something similar is already done. To find this place, we try to start from the action that is called and then with the help of the debugger try to find out which classes and Spring beans are involved.

The stack traces from the debugger are quite hard to understand, since a lot of reflection is being used.

Does anybody had a similiar setup and could provide a few tipps how to manage such a complicated setup?

答:
You need to try to understand the software from an architectural perspective.  That's going to be hard to do studying stack traces.

I would start by laying out the classes in a UML diagram.  Struts is an MVC framework, so the project is probably an MVC one.  Find out what all of the frameworks are, and analyze your class layout to determine the role each piece fulfills.

Once you do that for awhile, you'll be in a much better position to extend the project skillfully and sensibly.


问:
Unit testing of "workflow" methods
We are currently developing a public API for our app. The methods on this public API are mostly putting together functionality in different corners of the system.
An example would be: (names have been changed to protect the innocent)

```<code>public String createAppUser(String app, String name, String email, byte[] pwd) {
     Application appl = applicationModule.retrieve(app);
     User user = userModule.createUser(name,email);
     Digest digest = cryptoModule.createDigest(pwd);
     authenticationModule.authorize(user,appl,digest);
     accountingModule.createAccount(user,appl);
     return user.getId();
}
</code>```

When unit testing such a thing, the unit test is just a copy of the same workflow, with some additional noise to setup mocks, objects and validate interactions. Although I find unit-test of algorithmic parts of the application essential, in this 'workflow' part, I find unit-test a repetition of the workflow in question form. Following the DRY principle, it feels like a waste of time. What are the best practices in these cases?

Given that these methods are part of a public API, I would find more valuable to test them through a client and   validate that the system effects have taken place. This is more 'system test' or 'integration test' and beyond the scope of unit test.

What would be the best test approach in this context?

答:
You're right: this falls under the 'integration test' category. And with integration tests, I tend to not mock anything other than very external resources (like a web page or network file), since you're supposed to be testing how the real components interact with one another.

In those cases, just assert that the proper application states have been changed and that the output looks fine. In this case running the method and simply confirming that the users table has been modified, that they're authorized, and that you get an ID back.

Title: Unit testing of "workflow" methods


问:
Are value converters more trouble than they're worth?
I'm working on a WPF application with views that require numerous value conversions. Initially, my philosophy (inspired in part by this lively debate on XAML Disciples) was that I should make the view model strictly about supporting the data requirements of the view. This meant that any value conversions required to turn data into things like visibilities, brushes, sizes, etc. would be handled with value converters and multi-value converters. Conceptually, this seemed quite elegant. The view model and view would both have a distinct purpose and be nicely decoupled. A clear line would be drawn between "data" and "look".

Well, after giving this strategy "the old college try", I'm having some doubts whether I want to continue developing this way. I'm actually strongly considering dumping the value converters and placing the responsibility for (almost) all value conversion squarely in the hands of the view model.

The reality of using value converters just doesn't seem to be measuring up to the apparent value of cleanly separated concerns. My biggest issue with value converters is that they are tedious to use. You have to create a new class, implement IValueConverter or IMultiValueConverter, cast the value or values from object to the correct type, test for DependencyProperty.Unset (at least for multi-value converters), write the conversion logic, register the converter in a resource dictionary [see update below], and finally, hook up the converter using rather verbose XAML (which requires use of magic strings for both the binding(s) and the name of the converter [see update below]). The debugging process is no picnic either, as error messages are often cryptic, especially in Visual Studio's design mode/Expression Blend.

This isn't to say that the alternative--making the view model responsible for all value conversion--is an improvement. This could very well be a matter of the grass being greener on the other side. Besides losing the elegant separation of concerns, you have to write a bunch of derived properties and make sure you conscientiously call RaisePropertyChanged(() => DerivedProperty) when setting base properties, which could prove to be an unpleasant maintenance issue.

The following is an initial list I put together of the pros and cons of allowing view models to handle conversion logic and doing away with value converters:

Pros:

Fewer total bindings since multi-converters are eliminated

Fewer magic strings (binding paths + converter resource names)

No more registering each converter (plus maintaining this list)

Less work to write each converter (no implementing interfaces or casting required)

Can easily inject dependencies to help with conversions (e.g., color tables)

XAML markup is less verbose and easier to read

Converter reuse still possible (although some planning is required)

No mysterious issues with DependencyProperty.Unset (a problem I noticed with multi-value converters)

*Strikethroughs indicate benefits that disappear if you use markup extensions (see update below)

Cons:

Stronger coupling between view model and view (e.g., properties must deal with concepts like visibility and brushes)

More total properties to allow direct mapping for every binding in view

RaisePropertyChanged must be called for each derived property (see Update 2 below)

Must still rely on converters if the conversion is based on a property of a UI element

So, as you can probably tell, I have some heartburn about this issue. I'm very hesitant to go down the road of refactoring only to realize that the coding process is just as inefficient and tedious whether I use value converters or expose numerous value conversion properties in my view model.

Am I missing any pros/cons? For those who have tried both means of value conversion, which did you find worked better for you and why? Are there any other alternatives? (The disciples mentioned something about type descriptor providers, but I couldn't get a handle on what they were talking about. Any insight on this would be appreciated.)

Update

I found out today that it's possible to use something called a "markup extension" to eliminate the need to register value converters. In fact, it not only eliminates the need to register them, but it actually provides intellisense for selecting a converter when you type Converter=. Here is the article that got me started: http://www.wpftutorial.net/ValueConverters.html.

The ability to use a markup extension changes the balance somewhat in my pros and cons listing and discussion above (see strikethroughs).

As a result of this revelation, I'm experimenting with a hybrid system where I use converters for BoolToVisibility and what I call MatchToVisibility and the view model for all other conversions. MatchToVisibility is basically a converter that lets me check if the bound value (usually an enum) matches one or more values specified in XAML.

Example:

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}"
</code>```

Basically what this does is check if the status is either Finished or Canceled. If it is, then the visibility gets sets to "Visible". Otherwise, it gets sets to "Hidden". This turned out to be a very common scenario, and having this converter saved me about 15 properties on my view model (plus associated RaisePropertyChanged statements). Note that when you type Converter={vc:, "MatchToVisibility" shows up in an intellisense menu. This noticeably reduces the chance of errors and makes using value converters less tedious (you don't have to remember or look up the name of the value converter you want).

In case you're curious, I'll paste the code below. One important feature of this implementation of MatchToVisibility is that it checks to see if the bound value is an enum, and if it is, it checks to make sure Value1, Value2, etc. are also enums of the same type. This provides a design-time and run-time check of whether any of the enum values are mistyped. To improve this to a compile-time check, you can use the following instead (I typed this by hand so please forgive me if I made any mistakes):

```<code>Visibility="{Binding Status, Converter={vc:MatchToVisibility
            IfTrue={x:Type {win:Visibility.Visible}},
            IfFalse={x:Type {win:Visibility.Hidden}},
            Value1={x:Type {enum:Status.Finished}},
            Value2={x:Type {enum:Status.Canceled}}"
</code>```

While this is safer, it's just too verbose to be worth it for me. I might as well just use a property on the view model if I'm going to do this. Anyway, I'm finding that the design-time check is perfectly adequate for the scenarios I've tried so far.

Here's the code for MatchToVisibility

```<code>[ValueConversion(typeof(object), typeof(Visibility))]
public class MatchToVisibility : BaseValueConverter
{
    [ConstructorArgument("ifTrue")]
    public object IfTrue { get; set; }

    [ConstructorArgument("ifFalse")]
    public object IfFalse { get; set; }

    [ConstructorArgument("value1")]
    public object Value1 { get; set; }

    [ConstructorArgument("value2")]
    public object Value2 { get; set; }

    [ConstructorArgument("value3")]
    public object Value3 { get; set; }

    [ConstructorArgument("value4")]
    public object Value4 { get; set; }

    [ConstructorArgument("value5")]
    public object Value5 { get; set; }

    public MatchToVisibility() { }

    public MatchToVisibility(
        object ifTrue, object ifFalse,
        object value1, object value2 = null, object value3 = null,
        object value4 = null, object value5 = null)
    {
        IfTrue = ifTrue;
        IfFalse = ifFalse;
        Value1 = value1;
        Value2 = value2;
        Value3 = value3;
        Value4 = value4;
        Value5 = value5;
    }

    public override object Convert(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        var ifTrue = IfTrue.ToString().ToEnum<Visibility>();
        var ifFalse = IfFalse.ToString().ToEnum<Visibility>();
        var values = new[] { Value1, Value2, Value3, Value4, Value5 };
        var valueStrings = values.Cast<string>();
        bool isMatch;
        if (Enum.IsDefined(value.GetType(), value))
        {
            var valueEnums = valueStrings.Select(vs => vs == null ? null : Enum.Parse(value.GetType(), vs));
            isMatch = valueEnums.ToList().Contains(value);
        }
        else
            isMatch = valueStrings.Contains(value.ToString());
        return isMatch ? ifTrue : ifFalse;
    }
}
</code>```

Here's the code for BaseValueConverter

```<code>// this is how the markup extension capability gets wired up
public abstract class BaseValueConverter : MarkupExtension, IValueConverter
{
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return this;
    }

    public abstract object Convert(
        object value, Type targetType, object parameter, CultureInfo culture);

    public virtual object ConvertBack(
        object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}
</code>```

Here's the ToEnum extension method

```<code>public static TEnum ToEnum<TEnum>(this string text)
{
    return (TEnum)Enum.Parse(typeof(TEnum), text);
}
</code>```

Update 2

Since I posted this question, I've come across an open-source project that uses "IL weaving" to inject NotifyPropertyChanged code for properties and dependent properties. This makes implementing Josh Smith's vision of the view model as a "value converter on steroids" an absolute breeze. You can just use "Auto-Implemented Properties", and the weaver will do the rest.

Example:

If I enter this code:

```<code>public string GivenName { get; set; }
public string FamilyName { get; set; }

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

...this is what gets compiled:

```<code>string givenNames;
public string GivenNames
{
    get { return givenName; }
    set
    {
        if (value != givenName)
        {
            givenNames = value;
            OnPropertyChanged("GivenName");
            OnPropertyChanged("FullName");
        }
    }
}

string familyName;
public string FamilyName
{
    get { return familyName; }
    set
    {
        if (value != familyName)
        {
            familyName = value;
            OnPropertyChanged("FamilyName");
            OnPropertyChanged("FullName");
        }
    }
}

public string FullName
{
    get
    {
        return string.Format("{0} {1}", GivenName, FamilyName);
    }
}
</code>```

That's a huge savings in the amount of code you have to type, read, scroll past, etc. More importantly, though, it saves you from having to figure out what your dependencies are. You can add new "property gets" like FullName without having to painstakingly go up the chain of dependencies to add in RaisePropertyChanged() calls.

What is this open-source project called? The original version is called "NotifyPropertyWeaver", but the owner (Simon Potter) has since created a platform called "Fody" for hosting a whole series of IL weavers. The equivalent of NotifyPropertyWeaver under this new platform is called PropertyChanged.Fody.

Fody setup instructions: http://code.google.com/p/fody/wiki/SampleUsage (replace "Virtuosity" with "PropertyChanged")

PropertyChanged.Fody project site: http://code.google.com/p/propertychanged/

If you'd prefer to go with NotifyPropertyWeaver (which a little simpler to install, but won't necessarily be updated in the future beyond bug fixes), here is the project site:
http://code.google.com/p/notifypropertyweaver/

Either way, these IL weaver solutions completely change the calculus in the debate between view model on steroids vs. value converters.

答:
It depends on what you're testing, if anything.

No tests: intermix View code w/ ViewModel at will (you can always refactor later).

Tests on ViewModel and/or lower: use converters.

Tests on Model layers and/or lower: intermix View code w/ ViewModel at will

ViewModel abstracts the Model for the View. Personally, I'd use ViewModel for Brushes, etc and skip the converters.  Test on the layer(s) where data is in its "purest" form (ie. Model layers).


问:
How do you handle ever-growing piles of issues to be resolved "somewhen"?
We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?

答:
We use JIRA, and have an additional resolution state called Suspended -- if a feature/bug is something that we just have to give up on for a while, it gets resolved as Suspended. That way it doesn't get mixed up with either the list of currently active issues that we have to keep our attention on, or the list of resolved issues that we know have been handled satistfactory, and it's still in the database.

The list of Suspended issues is something that I review periodically (but not very often) to reopen as necessary.


问:
Ways of integrating legacy applications
My company is one which has grown up rapidly over recent years in multiple territories. We are not a software company per se, but a technical one who have developed various bespoke applications inhouse. Some of these are now sold as SAAS.

I am personally responsible for 3 of these applications: all internal web applications, one written in MySQL/Python/Django, one written in SQL Server/Python/Django and one in MySQL/PHP/Symfony. My developer resource includes expertise in all of these, as well as some Java and Adobe Flex. None of us have any significant experience in Microsoft technologies beyond SQL Server.

However, all the other departments in my company that have developers all work using the Microsoft stack - all our other webapps are C#/asp.NET etc etc etc.

I have been asked to evaluate integration of our depts products with others in the company at a data-sharing and presentational level.

I see 3 possible routes:

We bite the bullet and move to the Microsoft development stack, and this becomes a company-wide policy. Pros: standardisation, ability to pool resource, integration can be done at any level. Cons: massive licensing costs we can't really afford right now, complete retraining of all developers required, having to use IIS instead of nice Ubuntu/Apache servers, and general philosophical opposition (we're mostly open-source evangelists in my dept).

Middleware. We've been looking at Adobe Flex in order to handle data subscriptions between services. Pros: relatively cheap solution, existing in-house experience, can use whatever underlying tech we choose. Cons: it took ages to get a quote for Adobe data services, it isn't clear to me how futureproof this route is - are we potentially buying into a tech that's going extinct?

DIY. We stick with open-source all the way, and custom-write web service APIs between all the apps. Pros: cheap on licensing, open-source. Cons: additional time required, more testing, core issue of techology proliferation not tackled

I'd be interested to know what other approaches there might be here. Are there other Middleware ways of going about this? Am I hopelessly out of date with my views? What's a safe bet for the future?

Thanks

答:
I think one question is how much resource/budget your department gets.  You alluded to budget issues.  Where I work now (until Friday) the department gets no resource, and they use Microsoft technologies.  This leads to really poor tooling because no one wants to pay licensing costs.  It leads to all sorts of frustrating things like remote desktopping to a slow overloaded computer in order to use SQL Server Management Studio (because they only wanted to pay for one copy), etc...  Or not having a Dev/Test environment at all due to not wanting to spend any money on licensing.  Whereas with PHP/Python/Java just install the server and go.  Another issue is libraries.  Python/Ruby/PHP have way more web frameworks available and free.  Microsoft has only just released their MVC library.  Even things like Java had MVC frameworks for a much longer time, and things like Hibernate too were ahead.  Additionally many of the greatest .NET libraries are not free at first.  I know one prior employer was paying a fortune for infragistics web controls.  And whenever I wanted to write excel without Office Installed, the most useable libraries were not free (although now you can just use NPOI).  But even beyond money many Microsoft departments are not willing to accept third party libraries which also limits you.  Whereas most PHP/Java/Python/Ruby/Perl shops I have seen are using third party libraries up the wazoo...

But that being said Visual Studio 2010 looks like it has a lot of features and Microsoft has been catching up on some libraries (Entity Framework and LINQ from an ORM perspective and more, MS MVC for web framework, F# for functional programming, etc..).  Unfortunately there are still many places using .NET 2003 or .NET 2005 which do not have most of these features....  Then there are other shops who upgrade to the latest/greatest ASAP (usually with a lot of PRO MS corporate support).  So it's hard to say.  But definitely LINQ and Entity Framework (and even nHibernate) came out way after most other languages had ORMS.  MS MVC came out way after DJango, Struts, Catalyst, etc....  So they will be behind in many of the latest/greatest discoveries.

The problem is not so much developer training.  Most developers can pick up C# in a blink if they have been exposed to another C like object oriented language.  I knocked out my first .NET application in less than a week at my first Job (it was VB.NET but the time was spent not in learning VB.NET but rather the .NET framework, page lifecycle of asp.net web forms, etc..).  The problem is the "fun" factor.  Many developers enjoy Python/PHP/Ruby a lot more than C# or Java (well more Python/Ruby than PHP).  Some of them may just leave.  Also the additional frameworks/libraries of the other language make you more productive than straight C# beyond just the extra productivity of a scripting language.

Title: Ways of integrating legacy applications


问:
Type-clarifying comments and type checking in dynamic languages
I often feel that there's something wrong when I code blocks such as:

```<code>function foo (arg){ // arg: a SomeClass object
    ...
}
</code>```

or

```<code>function foo (arg){
    if (Object.prototype.toString.apply(arg) !== '[object Array]')
        throw new Error("Parameter must be an array");
    ...
}
</code>```

. With a statically typed language I wouldn't have to either clarify the expected argument type or check compliance to this expectation. In addition, the possibility of specifying a return type makes the code even more descriptive.

OTOH some cases lend themselves to self-documenting code:

```<code>function parse (json){
    ...
}
</code>```

. In the example above, it's reasonable enough to suppose that your API consumers will know both what the function is supposed to do, and what argument values will be acceptable.

However other times clarifying the code intent by choosing "clarifying" names would yield long, awkward names that mix the expected type of a variable and its role.

Am I using dynamic languages with the wrong mindset?

What conventions, techniques, patterns can save one from having to write ugly type-checking code and/or excessively depending on comments?

答:
If the argument is 'aDuck', and it '.quack();'s like a Duck and it '.walk()'s like a Duck, then saying that it's of type 'Duck'...  might be redundant and misleading, as there may also be other classes completely unrelated to Duck that also '.quack();' like a Duck and '.walk()' like a Duck.

Meaningful names and automated regression tests can be quite useful.

If someone calls your method with something very un-Duck-like and it doesn't work the way they expect, then certainly their tests will fail.  And they may learn to do something more appropriate to their needs.

So:  Write good code.  And don't worry about it too much.    ;->


答:
Am I using dynamic languages with the wrong mindset?

I think so, yes. Worry less about what type it is and more about what functionality it provides.

You can usually check this explicitly at runtime. For example, In Ruby, you can call respond_to on any object and find out if it is capable of responding to the methods you intend to call. Or you can just call the method and it will fail if it can't handle it.

This is known as duck-typing, if you want to search for more info.

Title: Type-clarifying comments and type checking in dynamic languages

Body:
I often feel that there's something wrong when I code blocks such as:

```<code>function foo (arg){ // arg: a SomeClass object
    ...
}
</code>```

or

```<code>function foo (arg){
    if (Object.prototype.toString.apply(arg) !== '[object Array]')
        throw new Error("Parameter must be an array");
    ...
}
</code>```

. With a statically typed language I wouldn't have to either clarify the expected argument type or check compliance to this expectation. In addition, the possibility of specifying a return type makes the code even more descriptive.

OTOH some cases lend themselves to self-documenting code:

```<code>function parse (json){
    ...
}
</code>```

. In the example above, it's reasonable enough to suppose that your API consumers will know both what the function is supposed to do, and what argument values will be acceptable.

However other times clarifying the code intent by choosing "clarifying" names would yield long, awkward names that mix the expected type of a variable and its role.

Am I using dynamic languages with the wrong mindset?

What conventions, techniques, patterns can save one from having to write ugly type-checking code and/or excessively depending on comments?


答:
Here's the thing.

Statically-typed languages normally have a compiler, and the compiler does type checking to prevent a certain class of bugs at compile time - that is, if you have one of those bugs in your code, you won't even get a chance to run into it in production, because you won't have anything to execute until you fix the bug. This is probably the biggest benefit of static typing.

Dynamic languages (often) do not have a compiler, and consequently, any type checking you might want to do happens at run-time, and if your types don't work out the way you expected, you can only find out through testing. But guess what, if you don't type-check at all, you can also find bugs through testing. The added value of type checking, thus, is zero.

The usual way to go about these things is captured in the Python mantra "easier to ask forgiveness than permission" - instead of checking the types of your arguments, you assume that they are correct, and when this causes problems, you catch the exception and recover.

The idea of duck typing is closely related: I don't care about your type, as long as you implement the methods I need.

There are two downsides to the dynamic approach that you need to be aware of: side effects (when asking forgiveness, you also need to clean up all the side effects you've caused so far), and accidental naming clashes (data.save("example.txt") is conceptually different from rescueBoat.save(swimmer))


答:
Have you read anything about Enterprise Integration Patterns?  There is an entire book on this subject and a variety of frameworks out there to help.

http://www.eaipatterns.com/

Title: Ways of integrating legacy applications

Body:
My company is one which has grown up rapidly over recent years in multiple territories. We are not a software company per se, but a technical one who have developed various bespoke applications inhouse. Some of these are now sold as SAAS.

I am personally responsible for 3 of these applications: all internal web applications, one written in MySQL/Python/Django, one written in SQL Server/Python/Django and one in MySQL/PHP/Symfony. My developer resource includes expertise in all of these, as well as some Java and Adobe Flex. None of us have any significant experience in Microsoft technologies beyond SQL Server.

However, all the other departments in my company that have developers all work using the Microsoft stack - all our other webapps are C#/asp.NET etc etc etc.

I have been asked to evaluate integration of our depts products with others in the company at a data-sharing and presentational level.

I see 3 possible routes:

We bite the bullet and move to the Microsoft development stack, and this becomes a company-wide policy. Pros: standardisation, ability to pool resource, integration can be done at any level. Cons: massive licensing costs we can't really afford right now, complete retraining of all developers required, having to use IIS instead of nice Ubuntu/Apache servers, and general philosophical opposition (we're mostly open-source evangelists in my dept).

Middleware. We've been looking at Adobe Flex in order to handle data subscriptions between services. Pros: relatively cheap solution, existing in-house experience, can use whatever underlying tech we choose. Cons: it took ages to get a quote for Adobe data services, it isn't clear to me how futureproof this route is - are we potentially buying into a tech that's going extinct?

DIY. We stick with open-source all the way, and custom-write web service APIs between all the apps. Pros: cheap on licensing, open-source. Cons: additional time required, more testing, core issue of techology proliferation not tackled

I'd be interested to know what other approaches there might be here. Are there other Middleware ways of going about this? Am I hopelessly out of date with my views? What's a safe bet for the future?

Thanks


答:
Do you also run your production machines with remote debugging, and you manually stepping through them? Building a proper script is identical to writing a program. All of the issues you have indicate things that it will need to watch for and check against.

If something goes wrong, it should go through proper rollback procedures, and send you a message. Everything that happens can get logged for later. You can version control the scripts, and set up test cases.

But if you are manually running commands, you don't have any of these advantages. You instead have a list of disadvantages.

You don't have a good log, shell history doesn't count

No one else knows how to do it

Steps get missed

Checks are only sometimes done

Some items to deploy may get missed, I've done that before

It takes a lot longer

You can get interrupted during the process

A proper script should be almost identical to if you typed everything out on the shell. This is one of the reasons that we have bash scripts. If you trust the things you do, why can't you record everything and tighten it up? Better checking, faster checking, more checking can happen because the computer does it.

Title: How can I automate production deployments without experiencing extreme anxiety?

Body:
At our shop we use SVN for source control and CruiseControl for CI on handling automatic builds and deployments to our development, test, and integration environments.

This all works smoothly however due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment.  While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Theoretically the difference is a slightly different configuration of our app servers and the deploy script merely would have to drop the build artifacts into two servers instead of just the one, but why am I so nervous to automate our production deployments?!

I am generally not a control freak but I always feel the insatiable need to deploy production to production manually.  I have heard from colleagues that this is generally a Really BAD Thing™ but they failed to make a case against it.

I know that when I do it manually I can SEE that I am physically copying the correct files, I am physically shutting down the app servers and ensuring they closed successfully, I am physically starting the servers back up and then physically inspecting the logs to make sure it started up okay and the deployment was successful.  It gives me a peace of mind.

What are arguments against this OR arguments for automatic scripted production deployment?


问:
Why are there no PUT and DELETE methods on HTML forms?
HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction.

What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?

答:
My understanding is that browsers don't know what to do once they send a PUT or a DELETE. A POST will redirect to an appropriate page usually, but PUT and DELETE typically don't. This makes them appropriate for calling via ajax or a native program, but not from a web browser form.

I can't hind it right now, but I remember reading one of the html5 mailing lists when they were discussing this.

ContentLicense: CC BY-SA 4.0


答:
Run the scripts on the live server. It will work, and after you've seen it work fine a few times, you will be perfectly confident in it.

Seriously though, you are more likely to make mistakes than the deployment script.


问:
Should interviews for programming positions be CS knowledge focused or behavioral focused?
It appears that many interview related questions on this site are focused on testing traditional CS knowledge, such as:

Algorithms

Data structures

Programming language/environments

Obviously the site is called "programmers", so that is to be expected.

However, I'd also argue that there are many other aspects that may be better predictors of a candidate's success (assuming that the candidate has a degree in CS from a good school and got good grades):

Do they have a general love for programming and a continual interest in improving their skills?

Are they willing to learn new skills?

Are they willing to take the time to share their knowledge with and help others?

Do they have a track record of success?

Will the interviewee enjoy the type of work the company is doing and be dedicated to it?

Did they work on similar projects or for similar companies before and enjoy them?

Will they like the company's culture?

Are they committed to seeing projects succeed?

Is there more benefit in testing CS knowledge or behavioral aspects, or a combination?

答:
When you are asking about behaviour in a technical interview, it ceases to be a technical interview.

For interviewing in general, both are extremely important I think. In my experience many companies hold a purely technical test (as they can be easier to do in a short time for many applicants) which you must pass in order to get to the real interview, where they ask behavioural questions.


答:
A combination.

The problem is that it is relatively easy to test a candidate on algorithms and programming language knowledge but it is very difficult to find out his behaviour after only one or few interviews. In most of the questions you raised the candidate may lie just because he wants to get the job.

Title: Should interviews for programming positions be CS knowledge focused or behavioral focused?

Body:
It appears that many interview related questions on this site are focused on testing traditional CS knowledge, such as:

Algorithms

Data structures

Programming language/environments

Obviously the site is called "programmers", so that is to be expected.

However, I'd also argue that there are many other aspects that may be better predictors of a candidate's success (assuming that the candidate has a degree in CS from a good school and got good grades):

Do they have a general love for programming and a continual interest in improving their skills?

Are they willing to learn new skills?

Are they willing to take the time to share their knowledge with and help others?

Do they have a track record of success?

Will the interviewee enjoy the type of work the company is doing and be dedicated to it?

Did they work on similar projects or for similar companies before and enjoy them?

Will they like the company's culture?

Are they committed to seeing projects succeed?

Is there more benefit in testing CS knowledge or behavioral aspects, or a combination?


答:
Many employers are starting to value 'mindset' over 'skillset'. See this article:

http://finance.yahoo.com/blogs/daily-ticker/3gs-mindset-over-skill-set-critical-landing-job-125910227.html

It doesn't really state whether this has extended to the IT industry (which is very skills focused) but I happen to think it is as, if not more important. But I would take it beyond being willing to learn new skills, I think they should also learn new skills off their own back, and bring that knowledge into the enterprise. And of course, a love of programming is important, as is a general love of problem solving (do they like doing puzzles, to relax for example?)


答:
Even a 100% technical interview are affected by how the candidate behave when he answers the questions.

However, it's true that too much interviews are essentially based on technical skills and should include the others skills that are essential to every great programmer.

I passed many interviews and there were a wide range of genres. Some companies never asked me a single technical question while others focused their time on ensuring that I knew the most advanced things.

My personal experience is that companies that focuses on behavioral questions tend to get less job hoppers and people with essential skills such as emotional intelligence (which is rare for a developer).

So I would say you should combine both but with more focus on behavior.


答:
A combination will be used often as how you answer can be just as important as the answer itself.  While it may not get picked up easily, I think one shouldn't forget that there can be killing two birds with one stone in the case of asking some technical questions.  If someone is given a whiteboard problem then various communication skills get tested, how well does the person ask questions to clarify what is the top priority in a solution, how well can he or she articulate why his or her solution is good.

Some cautions on these questions that I don't know if you'd catch this or not as there are different interpretations one could take here:

Do they have a general love for programming and a continual interest
in improving their skills?

This can get ugly fast as I'm not sure everyone would be all excited about programming in Assembly if their job would be doing web development using rather high level languages most of the time.  That "general" can be taken in many ways that aren't so great to my mind.

Are they willing to learn new skills?

Do you mean for this to be so open-ended?  I don't think I'd want to learn how to skydive or perform open heart surgery among many other things which probably wasn't what you'd thought of in asking the question.  Who wants to learn how to clean up all kinds of different chemical spills or survive a nuclear meltdown?  How appropriate are those skills is a valid concern here, especially if this learning is on company time or money.

Are they willing to take the time to share their knowledge with and help others?

This is where excesses can be brutal.  Some people could have a hard time saying no and thus their work doesn't get done because someone asked and to say no here would imply a no to this general question or was it meant to be a "most of the time but not the expense of making your own deadlines" which is what most people have as a great challenge?

Do they have a track record of success?

Who is defining "success" here?  Does my existence to this point in time qualify as a success?  Does the fact that I got to an interview location at the right time with appropriate clothing count as a success?  Does it take a Herculean effort to make something a success?

Will the interviewee enjoy the type of work the company is doing and be dedicated to it?

How well could a company explain what that work is and be correct in allocating various %s to how much is in each category.

Did they work on similar projects or for similar companies before and enjoy them?

How much of the current company can be disclosed to do this properly?

Will they like the company's culture?

Again, there is quite likely to be multiple cultures as the company could have one, the department has another and the team carries yet another as each level may be run differently and so this isn't really a good question if the team's culture is wildly different from the company as a whole.

Are they committed to seeing projects succeed?

How committed are you wanting here?  The kind of person that will put in 100+ hours and call in all the favors with all the friends to get meet a deadline, practically jeopardizing many people's health in the process?  Think about how far do you want this and what if this person gets a little over zealous and wants others to go just as far?

In summary, you could look at these questions that may be useful for you just as background:

Why are so many programmers arrogant? [closed]

Why are programmers so pendantic? [closed]

Why are a seemingly disproportionate amount of programmers just, well, not nice? [closed]

How Can I Know Whether I Am a Good Programmer?


问:
Stuff every programmer needs while working
I've been tasked with creating a fun and relaxing environment, one thing I know that I want is ergonomic mice and keyboards, others have suggested exercise balls and bands.

What is it that every programmer needs while working? What might not be necessary but would be nice to have anyway?

Note: this question was asked previously, but has been recommended to be posted here. See this link for the previous responses: https://stackoverflow.com/questions/3911911/stuff-every-programmer-needs-while-working-closed

答: An Expense Account

ContentLicense: CC BY-SA 2.5

Body: An Expense Account


答:
Both categories are important. I think it's also important to include technical questions that go beyond knowledge of programming languages, algorithms, data structures, and other CS concepts. Ask about:

Security (cross-site scripting, SQL injection, hashing passwords, symmetric vs. public/private key encryption, etc.)

Object-oriented design (SOLID, design patterns, etc.)

Unit testing, test-driven/behavior-driven development, experience with testing/mocking frameworks

Advantages of Continuous Integration, version control, etc., experience with such tools

Software development methodologies, i.e., what makes a process agile vs. waterfall, etc. Just the general ideas and flow. In fact, being able to explain things in their own terms is better than just regurgitating the Scrum guide.

When/what should you re-factor, what is technical debt, etc.


答:
Software engineering is VERY different from other engineering fields.

When building a bridge the laws of physics are constant and there are generally only a handful of fundamental acceptable ways to design and build a bridge.  There are thousands of ways to design and develop just web applications alone, each one of those ways requiring a different skill set.

The mindset of a software engineer however overlaps the technological and platform barriers and allows one to view a persons general experience, attitude, behavior, design decisions and opinions, and ability to learn new skillsets quickly.

Mindset is by far and away much more important to me.


问:
Should the build drive your tags or should the tags drive the build?
Our current method of creating a product release is to tag all of our component repositories with the next appropriate version and then modify a master build script with these new version numbers for each component.  The master build script will then be run and it will perform a SCM checkout of each component, then modify the AssemblyInfo.cs file so that the compiled .exe (or .dll) has the correct version number, and then compile the component.  All of these components are then coalesced into a product release which is "versioned" with a pure marketing decided number.

So our process falls under the "tags drive the build" description, but I am not certain that is the best method.  Specifically, where I see this failing us is if we were to integrate our release build into the CI process, it seems like it would be backwards.

Not just that, but where in a typical release-management process does the decision for the new component version numbers come in? Someone has to decide when component A goes from 2.1.4 to 3.0.0 and if library B should change from 6.3.2 to 6.3.3 or 6.4.0.  Where are these version numbers stored and at what stage are they decided?  Currently, we make these decisions at the "last moment" and they are stored in the master build script.  The master build script itself is versioned and is tagged with the "marketing" version number.

答: The system I use has a version number file containing the major and minor version numbers, my CI server uses a checked in change to this file to trigger a "release" build. The CI server adds on a build number to create a major.minor.build version and then tags the code used for that build.</p>


问:
Is it a good idea to always use Google as the first step to solving a problem?

Possible Duplicate:

  Importance of learning to google efficiently for a programmer?

Avoiding lengthy discussions, as a senior level student in CS, how can I get away from Googling problems I run into? I find myself using it too much; I seemingly reach for the instant answer and then blindly copy and paste code, hoping it works. Anyone can do that. I've read the related threads about being a better programmer, but mostly those recommend practicing on pet projects, which I have done, but again I feel EVERY wall encountered, from design through completion, was hurdled with Google.

Do professionals instantly "research" their problem? Or do you guys step back and try and figure it out yourselves?

I'm talking about both 'algorithm/design' problems as well as compiler issues.

答:
Let me share a quote from my computer science professor, who was anti-Google:

USE THE MAN PAGES!

The man pages are the most authoritative source on whatever function or topic you need to research.  I normally read the man page first, then if I can't find an answer, I go to Google (well, actually DuckDuckGo).


答: Not sure of the correct JIRA terminology, but consider putting an expiration date on each "ticket".  If it has not been escalated, by feature needs or bug severity, to implementation within a certain amount of time, it probably wasn't that important in the first place.  This should help automatically keep the pile trimmed.  I often get tickets based on "wouldn't it be nice" or "this doesn't work perfectly like I want".  If no-one else pushes enough for it, or that user doesn't have enough clout, it doesn't get done and I close  the ticket after a couple of months.</p>

Title: How do you handle ever-growing piles of issues to be resolved "somewhen"?

Body:
We're using JIRA to keep track of issues in our software projects. One effect we noticed is that we often create a new issue but we don't knw yet when/if the problem is going to be fixed at all. So we invented a fake 'Distant Future' milestone which such issues get assigned to.

As it happens, the pile of issues assigned to this milestone keeps growing all the time so it seems this is not a good approach. There are so many of them by now that it became quite a lot of work to review all of them for validity. Some of them became invalid since the component they are related to you was removed. Some of them were duplicated by other issues. Some of them have such a poorly phrased description that nobody really knows what they are about anymore.

How do other software development teams deal with issues which are valid, but which might not get fixed anytime. Do you bother recording them at all? Do you assign them to the next planned version and then look at them again as the next release approaches? Something else?


问:
What are the common techniques to handle user-generated HTML modified differently by different browsers?
I am developing a website updater. The front end uses HTML, CSS and JavaScript, and the backend uses Python.

The way it works is that
,  and some other HTML elements can be updated by the user. To enable this, I load the webpage and, with JQuery, convert all those elements to <textarea/> elements. Once they the content of the text area is changed, I apply the change to the original elements and send it to a Python script to store the new content.

The problem is that I'm finding that different browsers change the original HTML.

How do you get around this issue?

What Python libraries do you use?

What techniques or application designs do you use to avoid or overcome this issue?

The problems I found are:

IE removes the quotes around class and id attributes. For example,  becomes .

Firefox removes the backslash from the line breaks:
 becomes
.

Some websites have very specific display technicalities, so an insertion of a simple "\n"(which IE does) can affect the display of a website. Example: changing
 to \n
 inserts a vertical gap in IE.

The things I have unsuccessfully tried to overcome these issues:

Using either JQuery or Python to remove all >\n< occurences,
 etc. But this fails because I get different patterns in IE, sometimes a ∙\n, sometimes a \n∙∙∙.

In a Python, parse the new HTML, extract the new text/content, insert it into the old HTML so the elements and format never change, just the content. This is very difficult and seems to be overkill.

答:
One of the first rules of web development is to never trust the client.  A malicious user or buggy client could bypass anything you do in Javascript and feed your server-side Python malformed and possibly harmful HTML, so your server-side Python needs to standardize and clean up whatever it gets.

As long as you have to do some of the work server-side, why not do everything server-side, bypassing web browsers' vagaries completely?  I'd recommend just sending the textarea contents to the server and cleaning it up on the server with BeautifulSoup.

You can still do the textarea-to-HTML conversion client-side if you want to, to show the user a preview of their changes, and just submit the textareas' contents to the server.


问:
Is anyone doing "real" TDD with Visual-C++, and if yes, how do they do it?
Test Driven Development implies writing the test before the code and following a certain cycle:

Write Test

Check Test (run)

Write Production Code

Check Test (run)

Clean up Production Code

Check test (run)

As far as I'm concerned, this is only possible if your development solution allows you to very quickly switch between the production and test code, and to execute the test for a certain production code part extremely quickly.

Now, while there exist lots of Unit Testing Frameworks for C++ (I'm using Bost.Test atm.) it does seem that there doesn't really exist any decent (for native C++) Visual Studio (Plugin) solution that makes the TDD cycle bearable regardless of framework used.

"Bearable" means that it's a one-click action to run a test for a certain cpp file without having to manually set up a separate testing project etc. "Bearable" also means that a simple test starts (linking!) and runs very quickly.

So, what tools (plugins) and techniques are out there that make the TDD cycle possible for native C++ development with Visual Studio?

Note: I'm fine with free or "commercial" tools.

Please: No framework recommendations. (Unless the framework has a dedicated Visual Studio plugin and you want to recommend the plugin.)

Edit Note: The answers so far have provided links on how to integrate a Unit Testing framework into Visual Studio. The resources more or less describe how to get the UT framework to compile and get your first Tests running. This is not what this question is about. I'm of the opinion that to really work productively, having the Unit Tests in a manually maintained(!), separate vcproj from your production classes will add so much overhead that TDD "isn't possible". As far as I am aware, you do not add extra "projects" to a Java or C# thing to enable Unit Tests and TDD, and for a good reason. This should be possible with C++ given the right tools, but it seems (this question is about) that there are very little tools for TDD/C++/VS.

Googling around, I've found one tool, VisualAssert, that seems to aim in the right direction. However, afaiks, it doesn't seem to be in widespread use (compared to CppUnit, Boost.Test etc.).

Edit: I would like to add a comment to the context for this question. I think it does a good summary of outlining (part of) the problem: (comment by Billy ONeal)

Visual Studio does not use "build scripts" that are reasonably
  editable by the user. One project produces one binary. Moreover, Java
  has the property that Java never builds a complete binary -- the
  binary you build is just a ZIP of the class files. Therefore it's
  possible to compile separately then JAR together manually (using e.g.
  7z). C++ and C# both actually link their binaries, so generally
  speaking you can't write a script like that. The closest you can get
  is to compile everything separately and then do two linkings (one for
  production, one for testing).

答:
I am not using Visual-C++, but I am performing TDD with C++, using googletest and googlemock, with QtCreator as my IDE. Years ago I had a similar setup with Visual-C++ but using a different unit test framework.

What I have found useful is to separate the project into a few sub-projects.

A static or dynamic library that contains 99% of the actual project source code.

A project that consists mostly of a main() method to run the normal program.

A test project that contains a main() to run my test framework and lots of files containing tests and mock objects.

With this setup, my IDE takes care of adding files to various projects and if dependencies are being correctly determined, I can run all of my unit tests with a partial rebuild. I even have it currently setup to run all of my tests immediately after I build. Jenkins, the CI I'm currently using, also runs and provides test results and coverage data.

It may be possible to add a custom launcher in your IDE for a file to run the unit tests for file Foo.cpp if you happened to name all of the unit tests for Foo under the test fixture TestFoo. How to set this up precisely for Visual-C++ I'm not sure but I do think it's possible.


答:
...due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment. While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Given above, I would probably be as anxious as you.

I once did review and testing of automated script that deploys to SLB and my feeling is that without pre-testing at load balanced setup I'd prefer to manually do things.

Besides prod-like testing setup, another thing that had significant impact on my peace of mind is that prod deployment was done by other team that developers - by guys whose only job was to maintain production environment.

In one of the projects I was assisting them in deployment as dev team representative. Prior to deployment, they were reviewing my instructions and during deployment I was just sitting online ready to consult if things go wrong. Back then, I learned to appreciate that separation.

Not that they were faster (why would they? I did test deployments 5x-10x more frequently than them). The big difference was in focus. I mean, my head is always loaded by "main" stuff - coding, debugging, new features - there's just too much distractions to properly concentrate on deployment. As opposed to that, their main stuff was just production maintenance and they were focused on that.

It's amazing how much better brain works when focused. These guys, they were just so much more attentive, they made so much less mistakes than me. They just knew that stuff better than me. They even taught me a thing or two that made my own test deployments easier.


答:
Get and post are are formats of transmitting the the data of the request.

I suppose you are asking about making form submission into a RESTFUL service.  But it does not make sense to change the http request standard to make assumptions the purpose of the http request.  Information of about the purpose that the request fills is best handled in the input fields.

Having an address and get and post allows the server to interpret the request and it's input values correctly.  From there the input values allow you to make open ended requests to the server and do what ever you want.  For example, you can have a field whose values are "put" and "delete"

Title: Why are there no PUT and DELETE methods on HTML forms?

Body:
HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction.

What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?


答:
Should interviews for programming positions be CS knowledge focused or
  behavioral focused?

Let's replace programming  with software development. And now I'm gonna say something really crazy here: Interviews for software development positions should be focused on software development.

When looking for experienced software developers, you're look for people who understand the following:

Make it work!

I wouldn't expect a software developer to be able to implement any data structure on the spot (granted, if they can't implement a linked list, then odds are low they're any good at programming). What I do expect is, that given a problem they will be able to provide a clean solution using implementations from any library they fancy. I expect them to be able to explain their choices, to show potential bottlenecks and propose improvements for scalability as required. I want to see adequate use of complex and simple data structures.

Does "shoulders of giants" ring a bell?

Generally a software developer should be able to piece together solutions quickly through reuse of available libraries, unless an own implementation has verifiable benefits. In almost all cases there's no point in reinventing the wheel when writing production code. Instead I expect them to have a great ability to read other's code, study 3d party APIs and grasp new approaches. Knowing the ecosystem they will move within inside out is a plus.

Algorithms are eternal. Software has life cycles.

Software developers should be able to solve completely different problems than those CS poses. CS poses well defined, isolated, small problems with verifiable constraints for the solutions. For starters, software developers must in fact develop the metrics to actually measure the quality of their solution (there's a lot of developers underestimating this and the result is horrible). Only to tackle problems, that are complex, blurry, depending on a context, which -to augment the fun- is changing over time and they need to design systems that can respond to changes. However they should:

Solve the given problem. Nothing less, nothing more.

You can't have software developers write a whole new framework and develop a new branch of CS around it to solve their problems. By the time their code finally builds the first time, the requirements have changed already. A lot of code is produced in the name of reusability which isn't even usable in the first place.

I wouldn't class this under behavior. I think it's about mastery, which is at the end of path everybody has to pave with their own experience.

So figure out how far along they are on their path. How much the developer they are longing to be is the developer you need. Talk about:

What it is they seek in professional software development.

What it is they seek in personal software development.

Problems they have encountered, that they have been unable to solve for a long time or even until now

Problems they have overcome and solutions they have tailored, that they are proud of

...

Of course there's a non-technical aspect to the job. Team work, knowledge exchange, mentoring, and so forth. But they are both beyond the scope of a technical interview and this site.

Please also understand, that filtering out candidates that have a basic understanding of programming and CS can easily be done prior to interviews and therefore should be done, to save valuable time, that you can use on the candidates that pass the filter, and that those who fail can use on choosing the next step for their improvement.


答:
I think you have already discovered that the short answer is "yes, use google all the time."

Frankly, you have things backward, in a job, you don't have to prove you understand a concept, it is the results that matter.  So you can google things more not less.  You ultimately will have to understand certain concepts, but frankly you can developing conceptual understanding by just googling things.

If you come up with something and it doesn't work, you'll just google some more and find the answer.  You'll probably also understand what was wrong with answer number #1, meaning you have enhanced your understanding of the underlying concept.  This is called "learning by doing."

So as a journeyman programmer, I start learning things on quick how to guides and do more research until I build what I want.  How to research things correctly is an art in and of itself.  I think you will find you learn the right things to type into google, when you should just ask questions on stackoverflow, and when you should just read source code.

Title: Is it a good idea to always use Google as the first step to solving a problem?

Body:
Possible Duplicate:

  Importance of learning to google efficiently for a programmer?

Avoiding lengthy discussions, as a senior level student in CS, how can I get away from Googling problems I run into? I find myself using it too much; I seemingly reach for the instant answer and then blindly copy and paste code, hoping it works. Anyone can do that. I've read the related threads about being a better programmer, but mostly those recommend practicing on pet projects, which I have done, but again I feel EVERY wall encountered, from design through completion, was hurdled with Google.

Do professionals instantly "research" their problem? Or do you guys step back and try and figure it out yourselves?

I'm talking about both 'algorithm/design' problems as well as compiler issues.


问:
Good resources and tools for modern, heavy JavaScript development?
I am interested in doing some projects that involve heavy use of JavaScript. Namely HTML5 based canvas games, potentially using node.js as well. I am interested in learning modern best practices, tools and resources for JavaScript.

JavaScript is tough to research because you end up wading through a lot of really outdated material, hailing from the times that "JavaScript" was a four letter word.

If you are heavily involved in JavaScript programming...

What text editor or IDE do you use?

What unit testing framework do you use?

Do you use Selenium, or something else?

What other tools do you use?

What communities exist that discuss recent advents in JavaScript?

What books do you read/refer to?

What blogs do you read?

答:
I do a lot of JavaScript development.  A lot of these are mentioned but, here is what I use:

Notepad++

Firebug

IE debugger (F12) and Chrome debugger (F12 on Windows)

I use Stack Overflow mainly for questions.  Coming here has proven helpful as well.

The first book I used was JavaScript: The Definitive Guide way back when.  Currently I don't use books as much as I use sites like MDN or MSDN docs.

We use some jQuery in places where it makes our life easier as well.

For unit testing we build our own test harnesses.


答:
As a professional programmer, I always find myself Googling things I need to know and don't.There is simply no better resource than the Internet to provide answers to questions.

However, this brings up two important points:

Information on the Internet is not always true or correct. Believe it or not, the information on the Internet is put there by people, and those people are not infallible; they may have an honest mistake of fact, or they may somehow get a jolly out of misleading others. So, always double-check information; there are usually plenty of sources, and if they all agree you can be pretty confident in the correctness of the answer.

As a student, and even in your career, you should always understand the "whys" and "hows" of an answer. Sure, you are almost certainly not the first person to have encountered a particular problem in computing. The only people that have truly unique problems are the true "computer scientists" who are developing the next generations of computing devices; the limitations, patterns and solutions for problems to the modern electronic microcomputer are well-known and well-trodden. However, just because they're known doesn't mean you don't have to know yourself. Sooner or later, you will be called upon to know how something you have put in works, either to modify its behavior or to explain its current workings to someone else. Not knowing in these cases will hurt you professionally. So, when slapping in an implementation you got from StackOverflow or CodePlex, you should always trace it, research any unfamiliar built-in objects or calls, and generally familiarize yourself with the structure, pattern and flow of the algorithm, so that even if you didn't invent the answer, you now know why it is correct (or sometimes why it may NOT be correct in a certain situation; for instance, not all sorts are created equal).


问:
How to define the seams between the domain layer and a database full of stored procedures?
We have a legacy database full of stored procedures.

These stored procedures are somewhat CRUD-categorized but upon inspection of some procedures, they are not "simple" as they might update, delete, whatever other records in other tables.

So to my mind (correct me if I'm wrong) it would seem that using an ORM would be pretty difficult since

I can't access the tables directly: I must use a stored procedure

The stored procedures would not map to CRUD

I'm leaning toward defining repositories to isolate the domain layer from the database but I fear that I would need to define a lot of infrastructure (caching, unit of work and the like) that I get for "free" in a ORM.

Any insights?

答:
I'm in almost the same situation; our database relies entirely on stored procs and we cannot introduce an ORM as everything would have to be rewritten to make use of it.  What I did was write an abstraction layer, basically an implementation of the Table Data Gateway pattern (although I call it a Repository, it's not the true DDD definition) that abstracts away the call to SqlCommand and friends.  Then I have a Service Layer sitting over that which just taps into the repository and calls the methods on it, returning business objects (essentially DTOs), sometimes with an inner collection of another business object (the mapping handled by the sproc and mapped in code).

It's not perfect but it nicely hides the messy details of using a stored procedure.


问:
Which Resource Would Be Best for Learning C# / .Net?
I'm a PHP / Java / Objective-C programmer, looking to finally learn some MS technologies, to increase my marketability, etc.

I am looking at these two books, can anyone experienced in the field suggest one over the other, or another book that'd be good for learning C# / .Net, etc? What impressed me about "Pro C# 2010 and the .NET 4 Platform" thumbing through it at the bookstore, was that they explained a whole lot of the inner workings and paradigms of MS, not just the language. I haven't had a chance to look through the other one, and probably won't get a chance.

Here are the two I'm considering:

http://www.amazon.com/2010-NET-Platform-Andrew-Troelsen/dp/1430225491/

http://www.amazon.com/Professional-4-0-NET-Wrox-Programmer/dp/0470502258/

I know this is a very specific question, but I feel it can greatly benefit others like me, trying to get into some MS tech.

答:
CLR via C# is a great one.
C# in Depth by our local hero, is very good too.

Just be careful, some advanced books might cover mainly the new features of a language, and C# is quite an extensive one.

I also highly recommend PluralSight. It is full of video tutorials, some introductory to C#, and numerous of advanced ones. It is a paid site, though. (I am not affiliated with them, just a happy customer).


问:
As a sole developer (for now), how should I be using Git?
I have multiple projects on Git that I eventually want to bring others into. However, right now it's just me and I use Git and GitHub very simplistically: no branches and basically just using the commits as a backup to my local files. Sometimes I'll go back and look at previous versions of my files for reference, but I haven't needed to do any rollbacks to this point, though I appreciate the option should I need it in the future.

As a sole developer, what Git or GitHub features could I take advantage of that would benefit me right now? What should my workflow be like?

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

答:
Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?

Of course. There is a simple good practice that you can use even if you don't have a team right now: create a separated branch for development. The idea is that master branch will contain only released code versions or major changes. This can be adopted easily by new developers that join your project.

Besides, branching is useful even if you are working solo. For instance, you find a bug while in the process of coding a new feature. If you don't use branches, you will have to do both: add new features and fix the bug in the same branch. This is not good :P On the other hand, if you had created a new branch for creating your new feature, you can just checkout the development branch, fix the bug, and checkout back the new feature branch.

This is just a brief example of what you can do being a sole programmer. I am sure there must be more good practices.

I highly recommend you this article: A successful Git branching model


答:
http://rads.stackoverflow.com/amzn/click/1430225491

Pro C# is one of my favorite programming books of all time. Definitely get it. I have the 2008 hardcopy version that came with free PDF.

Title: Which Resource Would Be Best for Learning C# / .Net?

Body:
I'm a PHP / Java / Objective-C programmer, looking to finally learn some MS technologies, to increase my marketability, etc.

I am looking at these two books, can anyone experienced in the field suggest one over the other, or another book that'd be good for learning C# / .Net, etc? What impressed me about "Pro C# 2010 and the .NET 4 Platform" thumbing through it at the bookstore, was that they explained a whole lot of the inner workings and paradigms of MS, not just the language. I haven't had a chance to look through the other one, and probably won't get a chance.

Here are the two I'm considering:

http://www.amazon.com/2010-NET-Platform-Andrew-Troelsen/dp/1430225491/

http://www.amazon.com/Professional-4-0-NET-Wrox-Programmer/dp/0470502258/

I know this is a very specific question, but I feel it can greatly benefit others like me, trying to get into some MS tech.


答:
You need to answer the question "What I want to do with C#"?
C# alone is not very useful if you want to get a job or work in a team for a real-life project. You need to know at least one of: ASP.NET, Silverlight, WPF or Windwos Forms. If you will be using a database, you will need to use Entity Framework or a 3rd party ORM.

From your background, you must know OO to some extent, so to get the basics of C# by itself is a first step, and I suggest you get an introductory book specially if you know programming. Then move to a specialized book in one of the above areas. Avoid sinking in the details of C# as a language if you are looking to build a project or get a job, the sea is deep.


答: I'm well-versed in several sophisticated branching models, and use some at work.  However, when I work alone on projects, I do pretty much exactly what you're doing now.  I can always create a branch after the fact if I need one, but I almost never do.  Working alone, I rarely have bug fixes that can't wait until my current task is finished.  My advice is to be familiar with some branching models, but there's no sense complicating things until you need to.</p>

Title: As a sole developer (for now), how should I be using Git?

Body:
I have multiple projects on Git that I eventually want to bring others into. However, right now it's just me and I use Git and GitHub very simplistically: no branches and basically just using the commits as a backup to my local files. Sometimes I'll go back and look at previous versions of my files for reference, but I haven't needed to do any rollbacks to this point, though I appreciate the option should I need it in the future.

As a sole developer, what Git or GitHub features could I take advantage of that would benefit me right now? What should my workflow be like?

Also, are there any particular practices that I need to start doing in anticipation of adding others to my projects in the future?


问:
When do 'static functions' come into use?
OK, I've learned what a static function is, but I still don't see why they are more useful than private member functions. This might be kind of a newb-ish question here, but why not just replace all private member functions with static functions instead?</p>

答:
Kind of late here but I'd like to try to create a precise definition: static functions are functions that do not or can not reference instance properties/methods of the containing class.

In some languages, like C#, there might be static fields or properties in static classes, so it's not exactly right to say they're not used for state; a static function might make use of static (global) state.

Basically, it boils down to: static functions, like anything static, are useful when it makes sense for them to always be available with no dependency on non-static instances.

Helper functions, like math functions, are an oft-sited example, but there are others.

If the class you create requires the data be immutable, it might make sense to create static functions that take in an instance and pass a new instance since the instance can't (or shouldn't) be changed. String classes, for instance, might have static functions that take in a string (or 2 or more) and pass back a new string.

Another reason might be that there's a class that keeps a global state or data of some kind. There might be static functions that work with the static properties or fields in that static class.


问:
Continuous Professional development – the best approach
From my experience in the current working environment, one's professional development is definitely in the hands of the individual.

As I see it there are several routes to the same objective based on cost, time and availability

External Offsite training Online

Training providers (itunes U,Pluralsight etc)

Books

Specialist /user groups

Specialist web sites (Channel9, stackoverflow,dnrtv,codeplex etc)

What would you consider to be the best approach (blend) to continued learning and maintaining a professional standard of work?

答:
Within the work environment always volunteer.

Whenever someone asks for help installing new software, is looking for someone to join a new project, needs someone to look at some unmaintained software -- stick up your hand.

You will learn a lot even if the software is outmoded and unsupported! After a while people will come looking for you when a new project comes up or some new software needs evaluating.


答:
I'm exactly in this situation but I did opt for a slightly more complex though not necessarily more complicated workflow with Git.

The objective at first was learn the git way so I did some amount of exploring.  then reverted to pretty much the workflow you described.

After a while this became difficult to work with as some situations arose also it gave me bad habits that would be hard to break once I join a team.

so I settled for the following :

Local repository for working.

Master branch as a stable trunk for the application

One branch for each feature / refactor, basically one branch for each sizable changes that will be done.

Merge back to trunk when the branch is stable and all tests pass.

I also setup a git hub account where I synchronize the trunk.  This allowed me to easily start working on different computers.  It was by necessity but allowed me to find bugs that were tied to the environment I was in which was not available on the other computers.  So now I make it a habit to try a project on a different "virgin" system at least once.  Saves me a lot of headaches when comes time to deploy to the customer.

I tag every versions that makes it into github as a releasable version.

If released to the customer I will branch from this version to create a second stable trunk for bug fixes declared by the customer.

The multiple branches at first seemed like overkill but it REALLY helped a lot.  I could start an idea in a branch, work on it for a while and when I start running circles I gave up and started another branch to work on something else.  Later an idea came where I would come back to the half baked branch and explore this idea.  this overall made me MUCH more productive as I could act of flashes and ideas very quickly and see if it worked.  The cost of switching branches with GIT is extremely low making me very nimble with my code base.  That said I still have to master the rebase concept to clean up my history but since i'm all alone I doubt I really need to.  Pushed it as "nice to learn".

When all the branching became complicated then I explored the log option to draw a tree of changes and see which branch are where.

Long story short, git is not like SVN, CVS or (brrr) TFS.  Branching is very cheap and making mistakes that will wipe out work is actually pretty difficult.  Only once did I lose some work and it was because I made my commits too big (see bad habits above).  If you commit often, by small chunks git will definitively be your best ally.

To me git opened my mind to what source control really is all about.  Anything else before was just attempts to get it, git is the first, that in my mind, got it.  That said, I did not try other DVCS, quite possibly this statement could be widened to the whole family.

One last advice, the command line is your friend.  Not to say that graphical tools are not good, quite the contrary but I really groked git when I dropped down to command line and tried it out myself.  It is actually very well made, easy to follow with a very comprehensive help system.  My biggest problem was being tied to the but ugly console in windows until I found alternatives.

Now I use both, Eclipse integration with Git to see what is going on in real time and do some operations like diffs, explore history for a file, etc.  And command line for branching, merging, pushing, getting and the more complex log trees.  some basic scripting and I've never been so productive with regards to source control and I never had so much control over my source.

Good luck, hoped this helped.


问:
How can I automate production deployments without experiencing extreme anxiety?
At our shop we use SVN for source control and CruiseControl for CI on handling automatic builds and deployments to our development, test, and integration environments.

This all works smoothly however due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment.  While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Theoretically the difference is a slightly different configuration of our app servers and the deploy script merely would have to drop the build artifacts into two servers instead of just the one, but why am I so nervous to automate our production deployments?!

I am generally not a control freak but I always feel the insatiable need to deploy production to production manually.  I have heard from colleagues that this is generally a Really BAD Thing™ but they failed to make a case against it.

I know that when I do it manually I can SEE that I am physically copying the correct files, I am physically shutting down the app servers and ensuring they closed successfully, I am physically starting the servers back up and then physically inspecting the logs to make sure it started up okay and the deployment was successful.  It gives me a peace of mind.

What are arguments against this OR arguments for automatic scripted production deployment?

答: Build a deployment script which you use to move your code into any environment.  We use the exact same deployment process to move code to dev, qa, staging, and finally production.  Since we're deploying multiple times per day to dev, and daily to QA, we've gained confidence that the deployment scripts are correct.  Basically, test the hell out of it by using it often.</p>