If you don’t break your software project up in to digestible, well formed pieces, all of the other things are just window dressing.

• When requests pile in to us at various stages of specification, and none of them looks anything like a user story, it takes your BA team and developers a long time to re-distill the requests in to user stories. If you make sure that more and more requests are starting out life as user stories, there is less re-writing. This has a huge impact.
• There is a really great Kanban “cork board” plugin for FogBugz.  If you use FogBugz, I think you’ll really like it. Stefan Rusek’s Kanban Board plugin really takes FogBugz to the next level.

More links on Agile and Kanban:

• Wikipedia’s Kanban entry
• Lean Software Development

USApi.USDataObject data = new USApi.USDataObject();
avs.SetStreetNumber(streetNumber); 
avs.SetStreetName(streetName);
avs.SetPostalCode(postalCode);

Whereas if it’s a Canadian merchant account you should do this:

Api.DataObject data = new Api.DataObject();
avs.SetStreetNumber(streetNumber); 
avs.SetStreetName(streetName);
avs.SetPostalCode(postalCode);

It’s annoying; you have to write double the code. At first, you might think “dynamic objects”, as they’re perfectly suited to this kind of thing where type safety is kind of getting in the way… but that only works in .NET 4.0.  I once proposed a similar problem to Michael, and he suggested the Accessor pattern. We create a new accessor for each data object.  The accessors hide the ugly away. A typical accessor for this scenario might look like this:

public class CompletionAccessor
{
     private object Obj;
     private CompletionAccessor(object capture) 
     { }

     public static CompletionAccessor GetCompletionInstance(PreAuthAccessor preauth, ProcessorCredentials credentials)
     {
          object completion = new object();
          if ( preauth is USApi.USPreAuth )
          {
               completion = getUsCompletion( (USApi.USPreAuth)preauth, credentials);
          }
          else if ( preauth is Api.PreAuth ) 
          {
               completion = getCaCompletion( (Api.PreAuth)preauth, credentials);
          }
          return new CompletionAccessor( completion );
     }

     private static getUsCompletion(USApi.UsPreAuth preauth, credentials)
     {
          // set up the US completion request based on the US pre-auth
     }

     private static getCaCompletion(Api.PreAuth preauth, credentials)
     {
          // set up the Canadian completion request based on the Canadian pre-auth 
     }
}

Michael would say “we’re building a facade”.  Sounds good to me! The net result is that the business logic code that does things like check the AVS response, check the authorization, save the processor reference, all the little things we have to do to process a payment properly don’t have to be written twice, even if the code that deals with the partner’s API directly does.

The next step might be to make sure that its testable – you might want to access the actual object inside of the accessor,  to run methods on them without a lot of casting and if statements.  To do this, you could make a generic accessor that could be re-used with a method on it that would allow you to run any method on the internal object by name without casting.  This idea is borrowed from Jon Skeet (of multiple fames) – if you were trying to figure out how to use dynamic objects in .NET 3.5,  you could read his post on the matter.If you borrowed liberally from Mr. Skeet’s post you might end up with this:

public abstract class GenericAccessor
    {
        internal object Obj { get; set; }

        protected GenericAccessor(object obj)
        {
            Obj = obj;
        }

        private GenericAccessor()
        { }

        public T GetMethodResult(string methodName)
        {
            Type type = Obj.GetType();
            MethodInfo method;
            T retval;
            try
            {
                method = type.GetMethod(methodName);
                retval = (T)method.Invoke(Obj, null);
                return retval;
            }
            catch (Exception ex)
            {
                Logger.LogException(ex);
                return default(T);
            }
        }
    }

So now, you can run GetMethodResult to access the processor’s API methods directly even through your accessor without having to write a bunch of wrapper methods.  It’s kind of like dynamic programming! Though, I prefer the real thing!

However, if Mary Jo is right in her recent article about Microsoft’s intentions, I’m a little worried:

“Silverlight is our development platform for Windows Phone,” he said. Silverlight also has some “sweet spots” in media and line-of-business applications, he said.

But when it comes to touting Silverlight as Microsoft’s vehicle for delivering a cross-platform runtime, “our strategy has shifted,” Muglia told me.

and later:

Muglia didn’t share any kind of timetable as to when Silverlight 5 might make its debut. He did note that the delivery pace of Silverlight is slowing. “As with anything as it matures, the (delivery) cadence changes,” he said.

That last bit sends chills down my spine.  The trouble is, I’ve been observing Silverlight’s growth trajectory, and watching it mature as an excellent potential platform for line of business apps. As a SaaS ISV delivering, among other things, accounting applications for large organizations, Silverlight’s mix of easy deployment, rapid application development, and inherent cross platform nature make my life easy. We recently undertook a project to replace an aging ASP.NET WebForms app containing some 1,500 lines of pre-JQuery JavaScript with a Silverlight app, and we’re thrilled. Better developer productivity, a very clean UI… I realize that Silverlight might not be considered “the web”; but it is in my mind an Internet platform for rapid application development that delivers apps on all major operating systems elegantly.

I don’t want the world to ignore HTML5, and I’m really excited about the “new JavaScript” world – node.js, CouchDB and others are all doing things in JavaScript that are really interesting.  Projects that we deliver to end consumers in their homes, of course we want HTML5 there. I don’t want to be beholden to a plugin when I’m targeting end consumers. But when we’re delivering line of business software to a large organization that can help us make sure that Silverlight is on all of the machines we are licensing, Silverlight is a real winner.

So, if Microsoft is “embracing HTML5″ why am I worried?

A decade of Microsoft’s ASP.NET WebForms world leaves me a little dubious of Microsoft’s commitment to well formed, cross browser HTML. When I watch a Silverlight developer add a button control in XAML or even drag it on to a Silverlight form, I’m not worried about the mess being made. I can’t say the same thing about WebForms. Micosoft’s historical tooling support for HTML CSS and JavaScript is just not all that good; and what’s to say they won’t try to use HTML5 in an embrace and extend campaign to win IE9 marketshare back?

Of course, there’s ASP.NET/MVC, and of course we love it for consumer facing web apps – but it makes assumptions that the developer can deliver good markup, which will need to be tested on IE7, IE8, IE9, FF2, FF3, FF3.5, Chrome, Safari… need I go on? Of course JQuery makes that easier than it was, no doubt – but I think what I liked about Silverlight is that I could put a good developer who knows XAML and C# well, sit him down in a chair with a good set of tools, and out would come easily managed well formed code. To do a good job in ASP.NET/MVC the developer needs to be expert in a much longer list of technologies.

If I had my way, Microsoft’s IE9 would do a good job supporting HTML5 – but Microsoft would continue to invest in developing Silverlight, and not just for the phone. I guess I’m just afraid of how far they’re going to turn the ship…

UPDATE:

A recent Microsoft publication addresses some of the concerns above and makes for good reading on the future of Silverlight.

A typical “mag stripe” card relies purely on data that has been embedded in the magnetic stripe. Anyone can buy an inexpensive card reader and record the data in the mag stripe, and with an easily obtainable machine they can then create a duplicate of the card. There are ways to make this more secure; but most of the rely on adding even more data to the mag stripe that’s just as easy to clone, unless you go so far as to require a PIN – and it’s not hard to simply video tape people entering the PIN to get around that.

There are questions from smart people about the EMV standard – it may not, in its current incarnation, be smart enough yet, even though it changes the game significantly. Many believe that it is enough to reduce the scope of the problem – but is it good enough?

So what are your thoughts? Wal-Mart says that EMV is the future – and that we should just get going with it already. I can relate – its frustrating watching the glacial change of pace with EMV.  Is it time?

Check it out, and put your own vote in.

I’m toying around with whipping up a little app, and I imagine us putting it in the Microsoft App Store thing. Pretty cool!  Go, check it out.

I did a Channel 9 video on Silverlight 4 the other day, which was good preparation for working in the WP7 Silverlight environment. If you’re a Silverlight Whiz already, you can probably skip it.

Here’s some great starter links:

• http://channel9.msdn.com/learn/courses/WP7TrainingKit
• http://www.wpftutorial.net/StackPanel.html
• http://www.microsoft.com/express/phone

What is this exactly?

It’s a credit card number, and all of the requisite security features to perform a transaction, but no plastic card. We’ve also seen this approach in programs like TPG Rewards’ “e-Movie Cash™” product. These products are very effective, and effecient – convenient for either online only situations (where you don’t need to swipe a card) or for consumer incentive programs that drive the winner to a specific retailer of group of retailers.

Pretty cool stuff – cost effective, easy to manage, and proving highly desirable to consumers –  I’m sure as managing plastic card programs increases in cost and complexity we will be seeing more of these.

Could not find endpoint element with name "PaymentGateway" and contract "PaymentGateway.ContractName" in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.

I couldn’t wrap my head around it; I had let Visual Studio set up the reference with Add Service Reference. Why wasn’t it working?

I had forgotten that when you are unit testing a class that uses a service reference, VisualStudio’s built in test harness doesn’t read the app.config from the project your target class is in. You have to copy the serviceModel entries to the app.config in your test project as well.