With the recent release of the WCF REST Starter Kit, Microsoft made implementing REST services via WCF much more approachable.  The Visual Studio templates provided are great and the accompanying videos on channel9 via endpoint.tv are well put together (Ron Jacobs has a good overview of these items).

One of the questions I had when I first started implementing REST services with WCF was how to add support for using the Content-Type and Accept HTTP headers to determine how objects are serialized.  Dino Chiesa had some great suggestions on how to do this and even wrote some sample code to demonstrate one approach.

Then, this past week I saw that Damian Mehers blogged another approach with sample code.  I really liked how the approach Damian used required nothing more than a method Attribute to support dynamic content type detection.

So I started to re-write my REST service to use a combination of the new base classes in the WCF REST Starter Kit and Damian’s DynamicResponse sample.  And I soon realized that it was missing support for dynamic deserialization of requests via the Content-Type header.

To make a long story short, I ended up merging Damian’s project into the Microsoft.ServiceModel.Web project that comes with the WCF REST Starter Kit and adding another method attribute to support incoming requests.  The result was two new method attributes: DynamicResponseType and DynamicRequestType.

Here is a diagram of the different scenarios that are now supported (essentially full bi-directional content-type detection via HTTP headers at a single URI):

Hopefully this capability will make it into the next WCF REST starter kit.  But for now you can download the code to see the few changes that are required to support this behavior.

Visual Studio solution with full source.  [NOTE: This code is not supported and is provided as an example only.  Use at your own risk.]

Note that the web project is exactly what you get with the WCF REST Collections service template but modified to not require multiple methods for both JSON and XML support.

It’s pretty amazing that creating a full-featured REST service with WCF now only requires the implementation of five (5) methods.  Great job on the starter kit WCF team and look forward to the next release!

[An open letter to the Windows Live Hotmail team about my experience with the latest redesign.]

Hi Windows Live Hotmail Team,

Just want to share some feedback on the new redesign.

For me the redesign has been refreshing and frustrating all at once.  I think the design of the main mail area is much better and I really like the rework of the typography.  Overall I think it has made the application more usable.

However, there are several things that are very frustrating. 

Multi-Select

First, multi-select is gone.  This, in my opinion, is a show stopper and a feature I really liked in Hotmail that is missing from Gmail.  During my first experience with the new design, I selected a mail item, pressed SHIFT, and then clicked on another mail item.  Well, as you know, instead of selecting all of the mail items as I expected, a new window opened with the mail item.  Argh.  This was very frustrating as it a key feature that I use regularly to organize and clean-up my inbox.

The Giant Banner Ad

When I first learned of the new design, one of my biggest hopes was that your team would get rid of or at least fix the placement of the giant horizontal banner ad at the top.  This has bugged me for a long time. 

It is horrible roadblock to improving the user experience and just destroys valuable screen space.  As a user of a free service, I understand that you may need to generate some revenue with ads.  However, I am also not foolish enough to think that this is the only or best approach.  You guys are smart and very aware of other ways to creatively place ads.  Please make it happen.  This isn’t 1990.

Feedback Experience

The little help icon on the top right is nice, and the Feedback link that shows up in the menu is useful but what happens after I click it is not. 

Having a static feedback form that will disappear into a black hole (as far as I the user am concerned) is more or less useless.  As a user of modern web applications I have come to expect a feedback experience that involves real human interaction.  A way to both see that my feedback is being heard and to interact with other users of the application.  It doesn’t have to be fancy or even a full blown community – but when I take the time to submit feedback I would at least like to see an acknowledgment from a human and it would also be nice to see the feedback from other users.

That’s it for now.

Regards,

Kyle

I recently read The Creative Habit:  Learn It and Use It for Life by Twyla Tharp.  It was an easy read and entertaining.  I was intrigued by many of the ideas and questions that Tharp presents throughout the book.

"What is your pencil?  What is the one tool that feeds your creativity and is so essential that without it you feel naked and unprepared?"

Questions like these are presented early in the book and could seem overwhelming if not balanced with the personal stories that Tharp shares along side each one.

"What are your five big fears?  Identify them and break them down.  Don't run away from them or ignore them; write them down and save the page.  There's nothing wrong with fear; the only mistake is to let it stop you in your tracks."

This can be tough to think about -- but by sharing some of her own biggest fears, Tharp gives readers a head start:

1. I'm not sure how to do it
2. People will think less of me
3. It may take too much time
4. It will cost money
5. It's self-indulgent

There are also some direct challenges on ways to exercise your creativity and begin to create a habit.

"Go one week without ... mirrors, clocks, newspapers, speaking ... "

A week without mirrors.  Hmm.  Newspapers may not be so bad, but speaking?  Definitely "thinking outside the box."

"Go outside and observe a street scene.  Pick out a man and a woman together and write down everything they do until you get to twenty items."

There are obviously many variations of this challenge.  I think the primary idea is just to pay more attention to the world around you.  And in the end it will foster creativity.

Tharp also spends a good deal of time talking about the power of mentors and learning from their ideas and creative habits.  Near the end of that discussion she makes an excellent point:

"You can also scratch in the footsteps of your mentors and heroes, using their paradigms as a starting point for ideas.  But be careful.  When I was beginning, I would sometimes find myself solving problems in exactly the same way that teachers such as Martha Graham and Merce Cunningham solved them.  Scratching among the paradigms is a dangerous habit if it turns you into an imitator rather than a creator."

I think it's interesting the fine line she is drawing between imitation and creativity.  We all want to believe we can come up with original ideas and yet (hopefully) are not foolish enough to believe this to be fact.  For some reason I have always had a vendetta out against imitation.  I tend to grit my teeth when I hear or (heaven forbid) begin to think to myself "let's see how they did it".  My natural inclination is to believe that thinking through the ideas for yourself will always yield better and more innovative results.

"The great composers are usually dazzling musicians ."

"A great chef can chop and dice better than anyone in his kitchen."

"The best writers are well-read people.  They have the richest appreciation of words, the biggest vocabularies."

All of these are great correlations.

"A poem is never finished, only abandoned." - Paul Valery

I think the same can be said of software.

"Knowing when to stop is almost as critical as knowing how to start." 

Haven't we all experienced the truth in that statement?  And yet it's so hard to remember -- to make a habit.

"Exorcise the rut.  Exercise the groove."

Read it again.  It's easy to miss.

"Every creative person has to learn to deal with failure, because failure, like death and taxes, is inescapable."

Many years ago someone told me that the fastest way to learn is to fail more quickly.  I have never forgotten that and still think about what it means.  A while back I was interviewing someone and asked: "Have you ever been on a project that failed?"  With a glowing smile they confidently answered: "No."  And continued on to explain how their dedication ensured that no project they were on would ever fail.  This was obviously unexpected and the first person I have ever heard say such a thing  and with such confidence.  Failure is not something to fear but rather something to recognize and learn from. 

"No matter who you are, at some point you will present your work to the world and the world will find it wanting.  Patrons shrug. Critics hiss.  Audiences stay away in droves. Even loyal friends avert their eyes."

Depressing I know ... but there's hope.

"In its purest form, inexperience erases fear.  You do not know what is and is not possible and therefore everything is possible."

The power of inexperience is perhaps the creativity it enables.

"The thing is to become a master and in your old age to acquire the courage to do what children did when they knew nothing." - Hemingway

An excellent read.

A few months back I had some dialogue with Nick Parker from uship.com.  He was wrestling with getting version control setup in a way that would meet the needs of his team and wanted to brainstorm a bit.  Here is a portion of our discussion that speaks directly to a couple of the problems Nick was trying to solve:

“I’m trying to figure out the best way to set up our subversion repository to do a couple things:

1. Facilitate peer code review.
2. Always have an "uploadable" version of our website (i.e. - be able to decide exactly which parts of the code go up when). “

These questions and the context of Nick’s situation really interested me.  I think that most if not all software development teams have to answer hard questions about version control at one point or another.  And if not at the start of a project then after learning a hard lesson from not using version control appropriately.

In addition, you will notice from these questions that Nick isn’t letting the tool (subversion in this case) shape the goals for his team or the desired process.  Instead, he has a clear direction in mind, he has some specific pieces of the development process that are proven and valuable, and he wants to use the tool in a way that would enable his chosen approach.

Like I told Nick, although I don’t have the perfect solution to these issues, I can share an approach I like to use on projects that has worked well and should provide a good foundation.

(Note that this approach was born out of a need to simplify and increase consistency of deployments to the asp.net suite of sites.  Our team was switching from Vault to Subversion at the time and really needed a better approach for managing environments independently and deploying more automatically.)

Directory Structure

This is probably one of the most overlooked pieces of setting up a Subversion repository for new users.  It’s easy to just start a project and begin checking in files as needed.  And with some version control systems this isn’t a big deal but with Subversion I think it’s really important to start with a structure that sets the flow of your development process.

Here's a snapshot of they way I typically setup the directory structure for a Subversion (SVN) repository and is loosely based on the ‘Branch-When-Needed’ system described in SVN Best Practices:

‘Trunk’ is where all the day-to-day development happens. It includes everything you want to version control on a project. And it should at least include a single directory for the web application. The web directory should contain the application as it is to be deployed compiled binaries and all.

As the name implies, ‘Branches’ is used to keep track of the branches for your web application.  In order to have independent version control of your web application per environment you should have a branch of the ‘trunk/web’ folder per environment.  And they should be branched in the order of deployment. For example, the alpha branch should be branched from trunk, while the beta branch should be branched from the alpha branch.

‘Tags’ is used to keep track of specific versions of a branch or deployment milestone.  Because each environment specific branch has its own change log, you probably don't need to tag each time you do a deployment to each, but it is a good idea to tag major versions and deployments to production.

Day-to-day Development

So, how does this apply specifically to Nick’s questions and the day-to-day development process?

1. Facilitate peer code review.

You can use ‘Trunk’ to do peer code review. It is where developers always check in their code.  If you are using continuous integration (Nick mentioned that his team is using CruiseControl) your build tool can pick up the check-in to auto-build and keep everyone honest.  Every check-in can be compared to previous versions to see what changes were made and revert if necessary.  This is a natural aid in the code review process.

Deployment

2. Always have an "uploadable" version of our website (i.e. - be able to decide exactly which parts of the code go up when).

The branches provide exactly this. You only merge into alpha what you want deployed to alpha (or staging) and you only merge into beta from alpha what you want deployed to beta.  This kills two birds with one stone.  First, you have complete control over what changes are deployed to which environment.  Second, you always know the code that is running in each environment.

To simplify deployment and remove human error, you can set up command line SVN and create a simple batch file to do an ‘svn update’ on the server.  Then deployment becomes as easy as merge changes, update server.  Or, if you use CruseControl you can automate the build and deployment on checkin for a specific environment.

Feedback

Now, there are obviously a lot of sophisticated ways to change this approach and make it work better for different development processes.  Understand, that the above is meant to be a simple example of an approach that solves many of the basic problems that teams encounter with using version control to fit their process and workflow.

I am quite interested in how you use version control to solve these problems on your development team.  Whether you use Subversion or another tool please share your approach and any feedback you have on the approach described above.

And Nick, if you’ve had a chance to experiment more please share what approach you ended up using.

In no particular order, here are the top ten things I've learned to pay attention to when dealing with production ASP.NET applications.  Hopefully they will help you save you some time and headaches.  As always, your thoughts and additions are welcome.

1.  Generate new encryption keys

When moving an application to production for the first time it is a good idea to generate new encryption keys.  This includes the machine validation key and decryption key as well as any other custom keys your application may be using.  There is an article on CodeProject that talks about generating machineKeys specifically that should be helpful with this.

2.  Encrypt sensitive sections of your web.config

This includes both the connection string and machine key sections.  See Scott Guthrie's post for some good references.  Note that if your application runs in a clustered environment you will need to share a custom key using the RSA provider as described in an MSDN article.

3.  Use trusted SQL connections

Both Barry Dorrans and Alex Chang have articles which discuss this in detail.

4.  Set retail="true" in your machine.config

<configuration> <system.web> <deployment retail="true"/> </system.web> </configuration>

This will kill three birds with one stone.  It will force the 'debug' flag in the web.config to be false,  it will disable page output tracing, and  it will force the custom error page to be shown to remote users rather than the actual exception or error message.  For more information you can read Scott Guthrie's post or the MSDN reference.

5.  Create a new application pool for your site

When setting up your new site for the first time do not share an existing application pool.  Create a new application pool which will be used by only by the new web application.

6.  Set the memory limit for your application pool

When creating the application pool, specifically set the memory limit rather than the time limit which is set by default.  Asp.net has a good whitepaper which explains the value of this:

By default IIS 6.0 does not set a limit on the amount of memory that IIS is allowed to use. ASP.NET’s Cache feature relies on a limitation of memory so the Cache can proactively remove unused items from memory.

It is recommended that you configure the memory recycling feature of IIS 6.0.

7.  Create and appropriately use an app_Offline.htm file

There are many benefits to using this file.  It provides an easy way to take your application offline in a somewhat user friendly way (you can at least have a pretty explanation) while fixing critical issues or pushing a major update.  It also forces an application restart in case you forget to do this for a deployment.  Once again, ScottGu is the best source for more information on this.

8.  Develop a repeatable deployment process and automate it

It is way too easy to make mistakes when deploying any type of software.  This is especially the case with software that uses configuration files that may be different between the development, staging, or production environments.  I would argue that the process you come up with is not nearly as important as it being easily repeatable and automated.  You can fine tune the process as needed, but you don't want a simple typo to bring a site down.

9.  Build and reference release versions of all assemblies

In addition to making sure ASP.NET is not configured in debug mode, also make sure that your assemblies are not debug assemblies.  There are of course exceptions if you are trying to solve a unique issue in your production environment ... but in most cases you should always deploy with release builds for all assemblies.

10.  Load test

This goes without saying.  Inevitably, good load testing will uncover threading and memory issues not otherwise considered.

While flipping through some old notes, I was reminded of another idea that was discussed: Emotional Intelligence. 

Over the course of the semester, we investigated the value of Emotional Intelligence through several exercises and were challenged to try them at work and discuss the results.  I do remember one "experiment" in particular.

A Little Background

At the time, I was working on a software application which included a moving map component.  The importance of this component, led our team to invest a lot of time and effort in finding the right solution.  This included an inventory of similar software applications within our company and partner companies.  We ended up choosing to partner with a company and integrate their map software into our application.

It worked very well.  Their mapping software met most of our needs and they were willing to make changes based on our constraints, etc.  In fact, we successfully performed several demonstrations of the application and developed a strong partnership with the mapping software provider.

Around the time our project started rolling along, another team within the division requested a meeting to discuss how they could leverage our new application.  This sounded like a great opportunity.  We could share the work we had done and allow another project to benefit. 

The Cold Hard Truth

As I soon learned, they really didn't want to use our application at all.  Sure, they were interested in the work we had done and what tools we had used, but they were most interested in showing off their ingenious software solution.  They were most interested in trying to convince us to use their home brewed moving map application.

It was obvious that learning of similar projects and collaborating with other teams was not a priority.  The effort to connect began after they had already started pouring the foundation of the project rather than before.

I was livid.  This was the exact cultural behavior that our team had been trying to overturn ever since I started working there: the tendency for engineers to always start from scratch.  The idea that the only way an engineer could prove themselves worthy was to re-engineer something that had already been proven successful.  The mentality that if our company didn't build it, then it must be crap.

But what did I know?  I was the new kid on the block.

The Experiment

As insulting as it was, and rather than draw quick conclusions, I simply soaked in all the information I could about their project and its "attractive" features.  I asked lots of questions and tried to understand their perspective and their understanding of the problem.  The bottom line is that instead of allowing my emotional reaction to close my reasoning I attempted to create space to respond.

This was the essence of the exercise the professor challenged us with: when you find yourself in a frustrating situation and you feel your emotions taking over reason, give yourself space.  The idea wasn't that your emotional reaction is always wrong, but rather that giving yourself space enables clearer thinking.

So, I was experimenting with this Emotional Intelligence thing.  I wanted to see if it had any value.

The Results

That evening, I couldn't stop thinking about the meeting.  I just kept running over and over in my head how there must be an approach that would be a win win.  An approach that would enable a common moving map component to be shared by both applications.  An approach that, however counter-cultural, would be embraced by both teams.

The next day I had a fresh perspective and realized that I had been thinking about the problem from the wrong angle.  Instead of getting so caught up in the moving map component, which my team had put so much energy into perfecting, the real focus should have been on the *integration* of the moving map into our software applications.  

The reality was that our applications would be using the moving map in different ways.  One was for a virtual simulation, and one was for real-time usage.  This in turn, made us value features differently.  For example, performance was very important for our application while map data configuration was more important for their application.

This change in perspective revealed an obvious way for our teams to work together and create synergy.  Instead of allowing frustration to push us into creating yet another project island, we ended up developing a strong working relationship and continued our progress towards a more open and collaborative culture.

The Take-away

There are two simple lessons I hold onto from that experience.

1. Tear down those hidden information silos.
2. Give yourself the space to breathe.

I was cleaning out some files a while ago and came across notes from a leadership class I took several years back.  The notes read:

* do the following once a day to reflect on the current status of a project *

1. DO - What have you done/observed so far?
2. STUDY/REFLECT - What did you learn from that event/observation?
3. CONNECT/SYNTHESIZE - How does this connect with what you already know?
4. PLAN - What will you do differently now?

Common sense really.  And probably the natural way most of us approach continuous learning.  Yet I find myself often following these steps:

1. DO
2. DO
3. DO
4. DO

Huh.

A few days ago, the Daily Dilbert really resonated with me.  They usually are pretty funny; and even funnier when you've directly experienced what Scott Adams is poking fun at.

When I read this, I was reminded of an experience I had while working at Lockheed.  Lockheed had (and probably still has) a tradition of giving employees gifts on employment anniversaries.  The one year gift was a nice pen with a fancy logo on it accompanied by a congratulatory letter.

Now, the thing that surprised me most about this gift was not the fact that we already had free pens available in our supply cabinet, but rather the contents of the letter.  The letter was addressed directly to me from the Vice President of Engineering.  And in it there was a personal invitation (quoted directly from the letter):

As your anniversary is recognized, I would like to take this opportunity to ask you for your honest and open feedback.  Please take a moment to drop me a line with your comments and suggestions on ways we can improve our business and make our time spent at work more meaningful.  These will help us in our pursuit of continuous improvement.

Quite honestly, she could have saved the $0.50 spent on the pen, and just sent the letter.  The fact that she was directly asking for "honest and open feedback" was quite refreshing.  Perhaps I was the only first year employee naive enough to think she was serious, but whether she expected it or not I was going to take her up on this offer.

You see, this was perfect timing.  As long as I had worked for Lockheed, and likely much longer, shipping and receiving was a major bottleneck for quick and agile projects.  If you placed an order through the proper channels you may get it in the next couple weeks, but more likely it would be more than a month!

We'd often call to check on the status of items and receive the same answer.  Something along the lines of: "It is showing up as having been received, but we're really backed up and I don't know how long it will be until we find it and get it over to you."

Inevitably, this led to many workarounds from the formal system.  Sometimes, we would find out when the item was going to arrive and then go pick it up ourselves.  Or, we would simply order directly to our homes!  But both of these options also presented problems due to security and other issues with procuring and moving property onto and around the facility.  Smuggling is not a good solution.

Even though I understood that the VP of Engineering was probably already aware of this issue, I was still encouraged by the opportunity to get her first hand feedback on why it was not being addressed.  It gave me hope that maybe she would have the power to press some buttons and get to the bottom of the problem -- the power that my boss lacked.

There was one small problem.  Evidently she forgot to actually check if she had time to listen to the requested "honest and open feedback" before her secretary sent the letter.

It turns out I finally got an appointment to chat with her associate.  Okay, that's fine, he was still at least four levels above me in the spaghetti of a corporate hierarchy and he could make things happen.  He would have the power to push some buttons.

In the two weeks leading up to the meeting, I wasn't sitting on my hands.  I was still actively involved in trying to figure out why it took so long to get things and how it might be fixed.  Rather than trying to be a maverick, I was working together with my peers and my boss who was also well aware of the issue.  His approach however was quite lax.  Although he was open to discussion about it and said that he would try to resolve the issue, the actions he took sent a different message:  that he'd dealt with this his entire career so why couldn't we; that it was just the way things were at a big defense company.

So I show up for the meeting and his secretary says he'll be there in a few minutes.  That's fine, it gives me more time to check out his cool pictures of airplanes and the nice uni-directional screen cover on his monitor. 

My first impression was that he was a really nice guy; that he actually really wanted to take the time to talk.  After the niceties, we got down to business.  I quickly talked through some of my first year impressions and then moved onto the issue that had been frustrating our team. 

Everything was going well until I was done explaining the issue.  You'll never guess how he responded.  In a nutshell he said, "do you realize who you are talking to?  Do you understand that I don't have time to deal with this and that you should have talked to your manager first?"  He may as well have said from the start: "WHOA WHOA, you don't talk to me directly [about real issues]."

This after agreeing to meet and talk with me.  This after explaining clearly to him the impact of the problem.  That it was costing the company valuable time and money.  That it was dulling the bleeding edge of his company.  That we were ADP and it significantly impacted the agility of our projects.

In that moment I realized the curtain had been pulled back.  I realized that he had just expressed what both he and his superior actually felt about first year employees.

But the story's not quite over.  I have to reveal that a few weeks later the oddest thing happened.  I received a call from the head of shipping and receiving.  He was calling to check how they were doing.  He wanted to see if things were going better and if there was anything he could do to speed things up.

If you don't subscribe to the Daily Dilbert, you should.

If you haven't heard, the deadline for the Community Server Theme Contest has passed.  The good news is that now you can vote on your favorite themes and download them for your site(s).

As part of the Theme Extravaganza, I submitted a single Blog Theme, Fluid, similar to the one currently used on daptivate.com (note that this is about to change, as I am currently working with a designer on a new theme).  It is named Fluid for several reasons ... that is the name of the Arcsin template I used as a starting point, it won't cause problems with anti-virus software, and it simply makes a lot of sense for the name of a stretchy three column layout. 

Details

Here are some more details about the Community Server Blog Theme called Fluid.

1. It is a very simple three column blog theme.  Each column adjust to the width of the browser.
2. There are different pre-configured theme variations included: Pink, Blue, Red, and Green.
   
3. The title/description header can be easily shown or removed based on user preference.
4. The logo, text, and colors can be easily changed.  
5. It is valid XHTML 1.0 Transitional.

Screen Shots

In order to give you a feel for what it will look like on your blog, here are two screen shots.

The pink theme variation (with header shown):

The blue theme variation (with header hidden):

As you can see, this theme puts a premium on actual content.  Blog posts can be prominently displayed and easily accessible for users.  It also enables easy customization to match your logo and preferences through the Community Server dynamic theming feature. 

Get It

You can easily download the theme for your blog.  Once you unzip the contents, follow the instructions in the readme.txt file to install.

Enjoy...