This past weekend my wife lost the crown on her tooth, and by Monday afternoon I had a better understanding of software design. How? Monday morning she called our dentist. We have new insurance, so she's never been to this dentist, but we had to pick a dentist when we signed up (so I found the one closest to the house.)

The conversation with the receptionist went something like this:

Receptionist: How can I help you?

Wife: I think I lost one of my crowns this weekend. I haven't been to your office yet, but I really need to see a dentist.

Receptionist: Ok, do you have insurance?

Wife: Yes

Receptionist: Who is it with?

Wife: Cigna

Receptionist: Is it a dental HMO?

Wife: I don't know.

Receptionist: You don't know?

Wife: No, would it be on the card? I can give you the number.

Receptionist: Well, give me your name.

<Wife tells her name, date of birth etc>

Receptionist: Oh, you're already in the system. We can see you at 2 today.

As my wife told me this, she told me that the receptionist couldn't believe she wouldn't know whether she had a dental HMO or something else. During this conversation, I immediately went to software (it's this illness I have, I always think about coding.) In particular I went to the number of applications I've written where I've asked the user information that they no doubt didn't care about.

Asking for Too Much Data

For example, on one quoting application, we asked them which of the 5 different types of conductor bar they wanted to use. This was information WE as a company cared about, but a lot of our customers might not have cared about. Instead, we could have asked information that the user cared about and still got our information. 

What was my wife after? Dental care ASAP. But the receptionist was too caught up on what she needed, and most likely the receptionist was filling out some form written by one us that has about 30 different fields a few radio buttons, maybe a couple of dropdowns.

The Game

So the dentist office has challenged me as a developer. There is data my application cares about (e.g. user's DOB) and there is data my customer cares about (e.g. the cost of some widget.) The game becomes, what's the fewest number of questions I can ask to satisfy both my application and my customer?

In the case of the dentist above, I think I could satisfy both the receptionist and the customer with 2 simple questions.  

1. What insurance provider do you have?
2. What is the insurance number?

After that, the receptionists software could see it is a Cigna policy, go out to their database, with our policy number. Look up our policy and return the data to the receptionist. Not just if it's an HMO or PPO or (or any other O) but customer information as well. For example, some of the information that Cigna knows and the dentist office wants is:

• My home address
• My wife's date of birth
• Policy expiration date
• Whether our deductible is met yet or not

So instead of the receptionist asking all of this information, she could pull it from Cigna, and when my wife goes in, all the receptionist would have to ask is "Are you still living at this address?"

What Really Matters?

What's the goal of the receptionist's questions? She wants to ensure that she has the right patient information so the office can collect the funds that are due in a timely manner. That's pretty important. If they get it wrong it will be a costly error. But it's precisely that it is important data that should inspire us as developers to help simplify the process. What is more likely to introduce an error? Dealing with 100 different people providing information? Or dealing with 20 different insurance companies' databases?

Does Anyone Get it Right?

The best example, to me, of an application that gets it right is Mint.com. When I signed up, it asked for some information, for example my bank's login information. As soon as I provided that, it started pulling in my information. I can go to Mint right now and see not only what my expenses have been, but what group they are, because Mint knows that when I use my debit card at Qdoba that it's "Eating Out" or "Fast Food."  

The first developer I ever worked with was named Fred.  I was only about 17 years old at the time, and had gotten a job working at an engineering firm after school. I did a lot of grunt work type things: assembled documentation binders, removed all old parts books out of the library, organized & filed software for the developers. (There used to be hanging folders that had sleeves for 5.25" and 3.5" floppies, so you could keep all your software in a filing cabinet.)  But sometimes I'd get a break from doing the grunt work and would get to work with Fred. Granted, I don't think I ever wrote code with Fred, but I'd work in his office, or I'd have some small Access database that I'd be working on and Fred would be kind enough to answer questions.

If you asked Fred about some piece of software that he wrote, he'd tell you he looked it up in some book, or saw some code in a magazine article and he basically just copied it and it worked. The last thing Fred would do is tell you how great his code was. In fact, I can honestly say I never once remember him saying anything like that.  After I'd worked with him for a whlie, I found out not only was Fred writing software for the company I was at, but before that, he was writing code for the Cray super computers, he obviously knew his stuff.

The best way to find out if someone has written bad code is to ask them.  A lot of people will tell you "Oh yeah, my first couple projects were bad. I used to use GOTO statements back when I first started."  And that's good, that they would be embarrased by the first code they wrote. (The first commercial app I wrote had one reviewer saying that the Help file looked like it had been done by a Kindergartner.)  But for most of us, that first app was many years ago, probably more than a decade.  Was that the last bad code that was written?

Good developers will look at the code that they wrote last year, and tell you how worthless it is.  There's some area that's hard to maintain, or there was something they didn't factor in, and if they had it all over, they'd write it differently.

In contrast, the bad developers that I've worked with might say things like "Yeah, I couldn't think of any other way to write it." Or "I knew it wasn't the best approach, but ..."  

The difference there is subtle but important.  Most bad developers don't reflect.  If you were to bring up code that they wrote 6 months ago, they'd offer you excuses, they'd admit it wasn't perfect, but it wouldn't annoy them looking at their old code.  Conversely, most good developers not only know that the code is bad, but they've been thinking about that code for some time.  Probably not constantly, but anytime they do some sort of work (for example, a repository class) they think back to the lessons learned from the last 3 times they've gone down this road, and they write it better.

Good developers cranked out a bunch of bad code las year, last month, last week, yesterday. And I hope that I crank out as much bad code as they do.

Let me start by disclosing something: I don't write tests as often as I should. I've done a ton more unit testing, specifically TDD, in the past 6 months than I probably have the rest of my life. However, sometimes I still fall back in to my "old ways" of just trying to cram code in and "get it done." I do enjoy writing tests. I enjoy what writing tests lets me do, for example, refactoring code because I know it's well tested.

I recognize the importance of testing, and I also recognize that it's a bit of a rarity today. As I have resumes come across my desk, and sit across the table in interviews, I see it's even more rare than I thought. Out of the coutnelss resumes and interviews I've done in the past year, I think only 1 or 2 mentioned TDD, and maybe a half-dozen even mentioned unit testing. (In fact, I think I've seen more people list VB4 on their resume than TDD -- and that was released 17 years ago.)

Then I read Uncle Bob's After the Disaster, It can be summed up with this quote:

When the disaster happens, what will the congressional and world court investigations find? Will they find a software industry that has defined a set of professional disciplines that it requires of it’s members? Will they find that the software industry has done the due diligence to ensure that it’s members are educated, trained, and skilled? Will they find that the software industry is composed of serious professionals who reliably follow their disciplines and practices?

Or will they find the chaos that exists today? Will they find developers who don’t write tests? (Can you hear the strutting politicians making hay with that? “Mr. President, it is my sad duty to inform this august body that these developers have no record that they test their code…”) 

On the one hand, I thought "Well, I guess if I wrote my resume today, I should list TDD so that others know I have that skill."  On the other hand I thought "What a sad state of affairs that we don't just assume our developers are writing testable and tested code."  

A few years ago, I sat in the engineering department for a manufacturer. My job had next to nothing to do with engineering, but it was an open desk, so I sat there. What I noticed is that the engineers there were doing structural testing of their models in SolidWorks. After that, they would often print off a prototype on our 3D printer, and finally they sent a functional prototype out to the test building.

These guys tested and tested and tested before they shipped anything. Recently I looked up one of those guys on LinkedIn, you know what I DIDN'T see listed anywhere on his profile? His proficiency at testing his designs. In the mechanical engineering world, it's just expected. 

So for right now, I think if/when I write my next resume, I'll probably list testing on there, but I really am hopeful for the day where putting Unit Testing and/or TDD on a resume for a developer would make as much since as writing "Created a Hello World app."

A month or two back I was checking out various validators for .NET.  I wasn't doing MVC and didn't want to try the workarounds to use Dat Model Validations, but at the same time, I didn't really want to write a lot of validation code.

As I looked through NuGet to see what was out there, I saw one called FubuValidation. I was drawn to this, because I admire the guys doing the FubuMVC project (and Jeremy Miller is a Chiefs fan so you know it must be good code.)

I downloaded the code and realized one of the attributes I wanted (MinimumLength) was not there.  Thankfully it's an OSS project on GitHub.  So I created a fork and set to work to add my new attribute.  I was excited because this was going to be my first ever Pull Request on an OSS and it was going to give me the attribute I needed.

I was instantly greeted with the fact that simply loading the solution into Visual Studio didn't work.  There were missing files and assemblies.  I figured I just missed a couple files but couldn't find them on GitHub.  As  I read and re-read the Readme, I noticed there was a rakefile, so I set out to get the necessary files to make the rakefile build.  Still no look.  I spent a couple hours trying to get the code to build, but couldn't.

The next day, I reaced out to Jeremy and Josh Arnold on Twitter and asked them where I could ask some questions.  They directed me to their Google group, where I asked my question about building Fubu Validation.

Thankfully, those guys were able to get me up and running in now time. Turns out I needed a newer version of Ruby than what I had. 

I took a couple things out of this experience. First, it helps to be nice to the OSS guys. I didn't go in "Guns blazing" complaining about needing Ruby, or telling them their code was broken. I asked a question, explained my situation and took their advice.

Secondly, I gave them the benefit of the doubt. That is, I assumed the project did normally build and run. I don't always do this, sometimes I assume the worst, but in the end, it usually shows people that I'm a fool.  After all, what's more likely, that an active project on GitHub (which is written by developers who are working on several projects) doesn't actually build and run? Or that there's a piece of information that I'm missing, either because of miscommunication, or because I ignored something?

I hope in the future that when I come to more new code bases, I'll give those code bases the same benefit of the doubt that I did FubuValidation.

Mostly this is just for me as a reminder.  Daniel Irvine has a good post on how to test RESTful services.

What it means for me is I now have a code block like this:

Brief History

A couple months back, Microsoft came out with a big announcement. As they continue to work on the ASP.NET platform, and release MVC version 4, they also released a new product called ASP.NET Web API.  The day it was released to beta there were already several blog posts talking about how great it was and how to implement it etc.

As I read the blog post I thought "This is amazing." It really is a great concept.  In fact, the concept was so nice, it had already been around for years. Personally, I've been using OpenRasta for a little over a year now.  

I loved OpenRasta from the get-go.  A simple, intuitive approach that let's you name your methods things like GET or POST and have the framework figure out which method to call. Very much like WebAPI.

So What's the Problem

For years there have been lots of open source approaches to doing .NET web type stuff. In addition to OpenRasta, there's an entire OSS MVC stack built on .NET, it's called FubuMvc, and it's pretty awesome. Yet most .NET developers don't even understand that this kind of stuff is possible.

In my day job I've been interviewing people for software engineering positions.  One question I like to ask is basically "What .NET tools or frameworks have you considered that were not written by Microsoft?"  There are a bunch of possible answers here. For example a few items you could use are:

• nHibernate
• Simple.Data
• Massive
• PetaPoco
• FubuMvc
• OpenRasta
• NUnit
• xUnit
• Ninject
• Autofac
• Moq
• FakeItEasy
• RhinoMocks

(And that list only covers part of 4 spaces - Data, Web, Testing & Dependency Injection).

However, the number one answer I've heard over and over again is "I'm pretty much just a Microsoft guy."

It's to the point where when I hear that, I'm all but done with the interview.

Don't get me wrong, I don't hate Microsoft. I don't think they're evil. I enjoy working on .NET.  That said, Microsoft's purpose is not to keep me employed, nor is it to make me effective at my job.  Those are my responsibilities, and if you're a developer, they're your responsibilities as well.

How does WebAPI fit in?

Since February's beta release of ASP.NET WebAPI I've heard several developers tell me something akin to "This WebAPI stuff is pretty cool.  I've got a project I'm going to use it in, it fits perfectly."

The problem here is that if WebAPI fits perfectly then a few other solutions would have as well, but the developer didn't use them. I don't know for sure why the developer didn't use them, but from the ones I've talked to it comes down to: they didn't know those options existed, because they weren't featured in MSDN magazine.

In 2012 we don't need to wait for the next edition of Dr. Dobbs or MSDN magazine to come out, because by the time it gets here, the data is already 4-6 weeks old.  Notice that Microsoft didn't announce ASP.NET Web API in MSDN, they announcned it at a conference and through a series of blog posts.

There's nothing wrong with WebAPI. I fully plan to play around with it to see how it stacks up against other technologies. But right now, it's a litmus test. Developers that are only now looking at RESTful services because of WebAPI, probably have a pretty narrow view of development.  And that makes the rest of the .NET community look bad.

There's been a bit of a dustup over Zynga acquiring another social gaming company.  If you hadn't heard, check out the details, including a response from the CEO.

A couple things that struck me about this story.

Keep It To Yourself

Before Sunday, I had never heard of Shay Pierce. That name meant absolutely nothing. But I found out about this developer via Twitter, and the reason why I heard is because other developers were reacting to the story.  Not to whether Shay accepted the Zynga offer or not, but rather to how his former employer was blasting him. If Dan Porter doesn't have a Twitter outburst, I not only don't know who OMGPOP is, but I also don't know who Say Pierce is or why it's a big deal he didn't accept some job offer.

Say Your Sorry*

Instead of coming out and saying "Let me reset what was going through my head" or "Let me explain what I was thinking" just come out and say "I'm sorry, that was wrong."  Anything else makes me feel like I'm in the middle of an argument between my kids "Dad, she made a face at me."  

In all honesty, this fauxology (faux-apology) made me think even less of OMGPOP than I did 10 minutes before when I first read some of the tweets.  Why?  Because we were told that the focus should have been on the team that put blood, sweat and tears into the app, and not into this developer. Yet that's not what happened, even in the apology we're focusing on a single developer.  I'd prefer to work with someone who, even when offended, deals with the matter in house, instead of making it public.  

I've worked on projects where we've all put blood, sweat and tears in. In fact, one such project might have cost a coworker his job. I say "might" because I don't know, our boss didn't come out and tell us.  All he told us was that developer was no longer with the company. He kept it between him and the developer. He didn't make it public among all the developers, or the company and especially didn't broadcast it out on the internet."

* The one caveat here is that if you're not actually sorry, you meant what you said, and would have liked to have actually said more, then just shut up. Don't insult my inteligence with a fauxology. Just don't say anything.

Repository: https://bitbucket.org/taylonr/openrastasample

Prezi: http://prezi.com/3ajm2of19lem/restful-services-using-openrasta/

o init-wrap <Name Of Project>

You have now created the project in OpenWrap.  That is, you've set up a folder to contain the "wraps" or packages that will be used in your project.

Create the Site

[EDIT: Before you can run this command you need to do o add-wrap openrasta-templates to add the wrap to your project]

OpenWrap has a nice template built in for OpenRasta.  You can issue the command:

o new-openrastasite -Name <SolutionName> -Namespace <BaseNamespace>

I chose to use PaymentService as my solution Name, and PaymentService.Api as my base Namespace in the example above.

Launch Studio

At this point, you're really done.  The following screen shot shows that it created PaymentService.sln as well as my first project PaymentService.Api.  I simply executed

..\src>PaymentService.sln & to launch my solution in to Studio (but you could actually load it any way you want.)

[EDIT: Or as Sebastian points out in the comments, add a -starteditor to the o new-openrastasite command and it will launch the editor for you -- Thanks Sebastian]

Once this loads, you can hit F5 to run it, and you should be greeted with the default "Hello World" in XML.  From here on out, it's just writing you're service.

 

For the past several months I've been using PetaPoco for almost all of my data access needs in .Net, and I've absolutely loved it. Until today.

I had a stored procedure from a legacy database that returns a code (e.g. -1, invalid user id, 0 success etc.)  I sat down to execute this stored procedure and ran the following command:

However, PetaPoco kept throwing an exception.  As I  stepped into the code, I found out why, the cmd.ExecuteScalar was always returning null.  I tried a bunch of different solutions, and none of them worked.  Then, I opened up SSMS (which should have been my first step) and started looking at how it executes stored procedures.  That's when it hit me.  PetaPoco is passing a command with a type 'text' so I needed to specify more data to make it work.  The query below did the trick.

Pay particular notice to the @@result.  If you simply put '@result' PetaPoco will expect a parameter named result.  Putting the dual '@' tells PetaPoco that this is a SQL parameter.