Pragmatism

My background

I'm a .NET, mainly C# programmer. Nowadays I focus on web applications. I usually work on enterprise-grade applications.

I came across Python a year ago on a training session. I was shocked by the syntax but I felt the power of the language and the toolset.

Pragmatism

I think I need to define what is pragmatism for me in the context of software engineering: when a customer has a business problem, your responsibility as an engineer is to choose the proper tools to fulfil the real needs of this customer.

Pragmatic tools

A tool can be a language, a framework, a design or architectural pattern.

Business domain

The real need means a customer usually can't express the whole problem to the team (or even mislead the the team with half or missing information) so the developer (or analyst) needs to dig deep into the business problem and understand the domain before the actual coding gets started.

Pragmatic programming

The first thing is to understand the business domain. A developer has to constantly check the requirements against the customer's ideas and the business domain to make sure there is no misunderstanding. It also applies to the QA (tester) personnel as well. Only the joint work of the analysts, developers and QAs (regarding only the development team) can ensure the success of the implementation considering the business domain and real needs.

The pragmatic programmer does not stick to the favorite language (e.g. C#) she knows:

• C# is a good choice for GUI, especially with WPF and Windows in mind. On the other hand Python can be a better choice for log analysis, mathematical modeling and statistical processing (considering NumPy, SciPy and Pandas). 
• WCF (as an XML web service) is powerful for enterprise-grade service implementations but REST can be a better choice for thin APIs with mobile clients.
• WCF is a powerful end-point provider but node.js can be a better choice if you have an AJAX-heavy web application with some kind of model-based JS framework. In case of node.js you don't need to transform your data from a static-typed language to a dynamic language. Less layers, less transformation, less technology and tooling. 
• ASP.NET MVC is an easy-to-learn and thin layer for web application development. I like it, but I know Ruby on Rails or even Django (Python) can be as powerful or even more powerful for your particular task.
• Entity Framework is powerful with its own limitations, but sometimes it worths going back to the basics with direct ADO.NET calls. Or does it? Consider Dapper, OrmLite and such.
• Object-oriented programming is well-understood but functional elements can make the code more robust and easier to manage.
• Defensive programming with guards is useful but what about code contracts (even the Microsoft implementation or in general)?
• Scrum is good and has proved, but how can I adapt it to the current customer? Or shouldn't I choose Kanban? Or Scrumban? Do I need to integrate with an existing project management 'system'? Anyway, do I need to choose an agile methodology at all (yes, it should be prefered :) )?

There are always alternatives and the engineer's job should be choosing the right mix of these alternatives.

Unit testing a Powershell Commandlet

I chose to write Powershell commandlets in C#. I created a class library (DLL) project and inherited a class from Cmdlet base class. I created a snapin class derived from PSSnapIn to be able to install my commandlets from powershell.

Unit testing

Writing a unit test

[TestClass]
    public class UnitTest1
    {
        private static RunspaceConfiguration config;
        private static Runspace runspace;
        private static Pipeline pipe;
        private static Command command;

        [ClassInitialize]
        public static void TestFixtureSetup(TestContext context)
        {
            config = RunspaceConfiguration.Create();

            PSSnapInException warning;
            config.AddPSSnapIn("SnapinName", out warning);

            runspace = RunspaceFactory.CreateRunspace(config);
            runspace.Open();
        }

        [ClassCleanup]
        public static void TestFixtureTeardown()
        {
            runspace.Close();
        }

        [TestInitialize]
        public void Setup()
        {
            pipe = runspace.CreatePipeline();
            command = new Command("CommandName");
            pipe.Commands.Add(command);
        }

        [TestMethod]
        public void TestMethod1()
        {
            command.Parameters.Add(new CommandParameter("ParameterName", "Value"));

            var psObject = pipe.Invoke();
        }
    }

Snapin couldn't be found

I wrote a unit test against one of my commands but it couldn't find my snapin, I got the following exception:

System.Management.Automation.PSArgumentException: System.Management.Automation.PSArgumentException: The Windows PowerShell snap-in '...' is not installed on this computer..

I could use my snapin from Powershell command line.

Solution

Add the following lines as post-build events:

c:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe $(TargetPath)
c:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe  $(TargetPath)

Both 32-bit and 64-bit installation will happen this way.

Cause

Visual Studio 2012 is a 32-bit process. I registered with 64-bit install util only. Now I register both versions.

XAML Resource Loading

Visual Studio 2012 kept locking my .DLLs. It happened mostly after starting a debugger session. I could trace back the problem to a GetManifestResourceStream() call.

Solution

This is my solution that seems to be working:

public Stream GetResourceStreamByType(Type type, string resourceName)
{
  var location = Assembly.GetAssembly(type).Location;
  var assemblyBytes = File.ReadAllBytes(location);

  var appDomain = AppDomain.CreateDomain("Resource domain");
  var assembly = appDomain.Load(assemblyBytes);

  return assembly.GetManifestResourceStream(resourceName);
}

public BitmapImage GetBitmapByType(Type type, string resourceName)
{
  var bmp = new BitmapImage();
  using (var source = GetResourceStreamByType(type, resourceName))
  {
    bmp.BeginInit();
    bmp.StreamSource = source;
    bmp.EndInit();
  }

  return bmp;
}

Reasons

Loading the resource by calling the GetManifestResourceStream() on the current assembly loads the assembly into the debugger's app domain which is Visual Studio in this case. Reading the bytes and loading them manually prevents this behavior.

I couldn't reload the form again after loading the resources this way so I had to create a separate app domain as well. Without separate app domain the assembly was already loaded and the reloading didn't happen with an error message like 'does not have a resource identified by the URI'.