Start Diskpart from the command prompt.

Oh man, the post, Winning is the worst thing that can happen in Vegas, names and calls out a tendency of which I’ve gradually been gaining self-awareness.

Future coding is a lot like playing the roulette. If you can guess where the requirements of tomorrow will land today, you’ve just scored the ultimate programmer’s prize: looking like a wizard. You saw the future and you were right! High five, brain!

That’s the almost irresistible draw of “flexibility”—often just a euphemism for building half or whole features before you know how they’re supposed to work or whether you need them. Just like in Vegas, the worst thing that can happen is to be right about this once in a while.

Relating to technical debt:

Running up the debt on your code is not just about the quick hacks and dirty commits you know you really should clean up (but just don’t). No, the far more insidious kind of debt is that acquired in the name of “flexibility”.

Equating this to technical debt never crossed my mind before but really resonates with me. Before hearing this talk, I had been thinking a lot about the role of code comments. Over this past year my conviction that comments bring more of a liability than benefit 99% of the time has been deepening. They take time to write (which could be spent on writing clearer code to begin with), and when they aren’t maintained (which seems to happen a lot), the code is much harder to understand than if there were no comments at all. It’s not much of a leap for me to agree that coding for unknown future requirements is a bad thing. It becomes a liability that must be understood and maintained and rarely outweighs the benefits of getting it right once in a while.

I really enjoyed this talk, Grasping Complexity with Both Hands (outline), by Glenn Vanderburg. Here are a couple of his ideas that I found really thought-provoking:

New idea doesn’t have to be perfect to be good. Don’t dismiss them as soon as you find a single flaw.

How to make decisions in the face of truly complex problems:

• Don’t think in terms of right and wrong solutions. Think in terms of costs, benefits, and risks.
• Don’t expect a perfect and complete answer. Try to find 80/20 solutions.
• Don’t expect to find a perfect, simple solution that covers all edge cases and all possible things that can go wrong. Ways to tackle this:
  • Solve the common case optimally, and accept sub-optimal solutions for the edge cases.
  • Don’t try to predict everything that will go wrong and prevent it. Instead create good feedback loops so that you can respond when something actually does go wrong.

This is the process I used to pull campaign tracking code click throughs programatically through the Omniture Reporting API. While you can start with code, I found it to be much more productive to use Omniture’s API Explorer to figure out exactly what I wanted first. The API Explorer is nice because it shows you the available methods  with their parameters and gives you immediate feedback as to whether it worked or not. The first section below goes through the API Explorer. The second half contains the code I wrote and is specific to C# and Visual Studio 2010.

Access to the API

First, you need web service access to Omniture. This creates a Share Secret key which is used instead of your password when making API calls. The username passed to the API is a combination of your company and your Omniture username: <username>:<company>.  Your username and shared key should look something like this:

• Username: jdoe:Company
• Shared Secret: 728275238473afe875ae398fea323ad3

API Explorer

You’ll want to verify that your username and shared secret actually work. The best way to do that is with the API Explorer. Enter your username and shared secret in the first section.

In the next section, choose “Company” for the API and “GetTokenCount” for the Method. This is a great Method to start with because it doesn’t require any parameters. Click “Get Response”.

The response shows up in a box below. If there are any problems, the error will appear here. If all is well, you’ll see the data you requested. In this case, we asked for the Token Count and got back 9978. Omniture gives you an allotment of API tokens. Each call you make (regardless of the response size) consumes 1 token.

Now that we know that we can successfully access the API, the next step is figuring out the API calls you want to use and the parameters that they take. In my case, I wanted to get a Ranked Report containing the number of Click-throughs for each Campaign Tracking Code. The Report API documentation explains most of the parameter fields and options. I selected “Report” for the API, and “GetRankedReport” for the Method. This populates the parameter section with a template for all possible options (it can be a bit overwhelming, but fortunately, you don’t need most of it most of the time).

After quite a bit of trial and error, I ended up with this:

Which results in this response:

Once you figure out how to pull the data you need through the API explorer, it’s time to move on to the code.

The Code (Visual Studio 2010 specific)

Omniture has created guides for a number of different platforms. You can search for them on the Omniture Developer Connection. In my case, I’m building the project in Visual Studio 2010, which has a guide and some libraries that Omniture created. I followed steps 1-4 of the guide to get started as they are. Their API client class follows the request structure you used in the API Explorer pretty closely. You need to create a reportDescription object within which you will put the parameters you need.

I decided to create an Extension method to populate the reportDescription object for me. Here it is:

Note that the reportDescription object is created outside of this method and is passed in. I’ve both hardcoded some of the values and passed in others as arguments. I ended up adding in a few extra parameters that I didn’t have in the API Explorer example above: I added a search and split the results into pages (top & startWith). Note how the values and structure here are pretty close to what we had in the API Explorer.

Here is the client I created to pull down the report and convert it to my own reporting format. I’ll break each section down below.

 
Let’s break this down. The constructor takes the API url (https://api.omniture.com/admin/1.3/), username (the combined username from above), and password (shared secret). I also set top to the number of records I want to fetch each time.

The only method that this class has at this time is to pull the Compaign Tracking code click-throughs. It takes the reportSuite, filter (filters on the actual tracking code to narrow the results down), and startDate and endDate. It returns a ClickthroughReport object which is my own object I use elsewhere in my project.

Next I instantiate the client that Omniture provided in the library we downloaded earlier, then I overrode the MaxReceivedMessageSize to the largest possible value. This sets how large the messages can be coming back from Omniture. The messages for my reports were quite large, so I just set this limit as high as it could go.

We go into a do while loop. Our result set is paged, so each time through the loop pulls the next range of data. I have it limited to 10 loops though because I don’t want this report to run for too long.

I create the reportDescription object (this was provided in the Omniture library) and populate it with my extension method, PopulateWith, that I showed above.

The reportResponse object contains a property called report which contains a property called data. Data is an array with the values we want. I loop through each item and place it in to my own report record object: