The other day I had the chance to peruse the work of another developer, a Microsoft MVP. The code was less than impressive. To be frank, it stunk, but it stunk in a strange way. It had a weird combination of advanced technique and rank naiveté. There was separation of concerns, but it was much more convoluted than it needed to be. The work that the code performed was relatively trivial, but it was hidden behind a bag of patterns and the structure of the classes made finding the code that did the real work an exercise in spelunking.
I mentioned it to a friend of mine, and he shared his story about a hiring interview with an MVP carrying job candidate. The story was eerily similar. The candidate was well versed with the latest and greatest development methodologies, but seemed to lack a grasp of writing a simple “fizz-buzz”. To make matters worse, part-way through the interview the candidate starting listing their “requirements”, which conferences they’d be attending, which technologies they would use, etc.
I was flabbergasted. Granted, my friend was glad the candidate was so forthcoming with his lack of professionalism. It helped make his decision not to hire the guy much easier. After I thought about it a little bit more, I realized that the fault wasn’t totally with the MVPs in question. All of us share a little of the blame.
We’ve been working on implementing some sort of enterprise wide single sign-on (SSO) at work. As part of that we really needed some way to authenticate with web services without depending on Windows or Basic Authentication, which is a phenomenal pain in the butt.
OAuth is “An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.” In other words, you can authenticate with it from lots of different places. More...
I apologize it has taken so long for me to post this, but as promised, here is the .cs file for the wsdl flattener.
FlatWSDL.cs (10.75 kb)
To use it, you need to modify your web config and add a reference to the library in the behavior extensions section: More...
Recently I had the need to let a user upload a zip file and then have the Ruby app extract it and store it in a DB. I turned to google, but beyond some posts recommending using rubyzip to do the zip file handling I couldn't find anything showing a good way to do this recursively without first actually extracting the zip file to disk and then using the dir object.
After much adding and deleting code I have something that works reasonably well. More...
I've recently begun learning Ruby by working my way through the Ruby Koans. I finally made it to the section on error handling, which answered a few questions for me.
Once again, Ruby has not surprised me (this is a good thing). There's just some minor syntactical differences. Specifically in place of "try, catch, finally" Ruby uses "begin, rescue, ensure".
rescue StandardError => ex
#Do something with the error
result = :code_that_always_runs
Since I haven't made it all the way through the koans yet I'm, probably missing something that seems obvious to long time Ruby users, but so far it's pretty damned simple.
I’ve got a few more WCF posts in the cooker, but I thought it might be nice to start the new year off with something a little bit different. This past Thursday, my wife and I were fortunate enough to receive an invite to the Knoxville Symphony Orchestra’s “Blogger’s Night”. More...
Sometimes when creating a WCF behavior it'd be nice to be able to pass in some sort of instance specific configuration information. Fortunately, you can.
In the previous post we added a class that implemented BehaviorExtensionElement so that we could apply our IServiceBehavior via the config file. There are a few other methods that you can implement so that the BehaviorExtensionElement will pull settings from the config file. This way when you add the behavior you can tell it something special, like what the friendly name of the service is. More...
Behaviors in WCF are so stinking useful, and once you get past the basics of WCF they're arguably a necessity. Microsoft has saved itself from hundreds of hours of cursing by including the ability to define custom behaviors.
My favorite use of behaviors is addressing some cross cutting concerns that we consistently have in our WCF services. Specifically logging, service registration, wsdl tweaking, and error handling. Which brings us around to the IErrorHandler interface.