Note: I'm sure a ton of people do this, and I'm sure it's been documented before..but a quick search for "generational effects like button" yielded nothing interesting on the top half of the first page of the search results so imma write this.

Sometimes when your shit goes viral it would be nice to measure HOW viral..how is the fanout. Someone "likes" your page. Then it posts a Like story to Facebook. Their friends see it and click the link. Then they hit "like" too. And so on and so on. Your site starts getting a ton of hits, life is awesome. But how awesome was it really? Did a ton of poeple find it organically on thier own and then liked it? Or was it more of a viral thing where people saw the Like story and clicked. And how many "generations" did it go through before it started dying out?

Turns out there's a sweet way to Make This Happen. Check out this code snippet for a Like button:

I removed all the javascript part of it, but you get the gist (HAR!). When a user clicks this like button, it will create a story on their newsfeed. If their friends see it and click on it, they'll be taken to http://themostawesomewebsiteevar.com and life is good. But now check out this version:

Looks identical, right? But there is a ref="1" tacked on there. What does it mean? Well this time, when a friend clicks the story, they are taken to http://themostawesomewebsiteeavar.com?fb_ref=1&fb_source=home. BOOM. Now you can track if the visitor came in organically, or if they came in because someone clicked on a post in their newsfeed. fb_source can also tell you if they clicked on it from a person's profile, or other places, but that's not important now. What if fb_ref could increment on every generation? Then you would be able to tell if someone visited the page because someone clicked "Like," then their friend saw it and clicked "Like," then THEIR friend saw it and clicked "Like" etc etc etc.

You now have a way of measuring your Like viral fanout. You could compile stats saying "x thousand pageviews came from a 1st generation like story, y thousand pageviews came from a 2nd generation like story, z bazillion pageviews came from a 3rd generation like story." Neato.

So how do you do this autoincrementing magic? Check out this snippet written using Javascript using nodejs, the expressjs framework, and the mustache templating language:

The server reads the querystring param if it exists, and increments the generation count. Then my like button code in my mustache template file would like this:

Neat huh? That ref parameter can be expanded to do more than just track a generation. It could hold a hash value to some table in your database which tracks much more. The sky is the limit. The possibilities are endless. The world is your oyster. Take a look, it's in a book, reading rainbow.

Docs for the Like Button are here.

So today marked the beginniing of qualifying for the first round of the ALMS and ILMC at Sebring International Raceway. It's only available streaming live on ESPN3.com so I duly headed over to that website and found the link to watch. Now, ESPN3 is setup so that you need to have ESPN at home in order to watch it. What happens when you try to watch a video is that it forces you to select your cable provider and then sends you to your cable company's website. From there you can login to your cable company, and it will send you back to ESPN3 in order to watch the videos.

Sounds nice, but I'm in the middle of a move, so I have my cable cancelled. I duly clicked on the link to watch the video, selected my former cable tv company and entered in my old login information praying it would work. It redirected back to ESPN3 but with a message saying "Sorry, you do not have the appropriate package" or something like that. :( My first thought was to ask a friend with cable for their login and password, but before I did that I clicked on the video again.

And what do you know, the show started playing just fine! MUAHAHAHAHHAA. I hope they never fix this

I wrote this for a friend to give him some tips and tricks for avoiding the crappy 10 East traffic during evening rush hour. I decided to repost this here so everyone can read it. Feel free to add more tips to avoid slow spots! It doesn't have to be on the 10 East, but on any highway!

I have a problem with Adding a Service Reference (and thus using svcutil). It generates proxy interfaces and proxy datatypes. If my WCF service used custom datatypes, the service reference would create a proxy datatype for it. This gives me headaches because I think I have a type Foo when in fact I have a proxied version. Now I have to cast between them. Also, if I have added two service references and they used the same datatype, guess what? It will generate two different proxied datatypes. And if I change anything about the service or the datatypes, I need to regenerate the service reference. What a pain.

Instead, I do something like this:

 [ServiceContract]
 public interface IContract
 {
   [OperationContract]
   int Add(int a, int b);
 }
 
 public class MyClient : ClientBase<IContract>, IContract
 {
   public int Add(int a, int b) { return base.Channel.Add(a, b); }
 }
 

Nice and clean huh? The WCF client uses the same interface and same datatypes as the service so no need to regenerate service references. It's tightly coupled and I also get compile time errors if I change the service interface. The only problem is that doing it this way does not generate asynchronous client methods.

The Visual Studio Async CTP gives a sneak preview into the future of the language. It adds two new keywords async and await which make it dead simple to convert regular code into asychronous code. I won't go into detail on how it works, but in addition to the language/compiler changes it also includes a bunch of extension methods that add this new style of asynchronous access to a bunch of preexisting classes that have asynchronous methods. For example, TextWriter contains a synchronous Write() as well as the asynchronous BeginWrite() and EndWrite(). This CTP adds WriteAsync() which wraps the BeginWrite() and EndWrite() into this new async/await syntax. What I envision, and what I hope happens is that they also do some work on WCF client generation (hopefully not using svcutil, but extending ClientBase). I want there to be something like this:

 [ServiceContract]
public interface IContract
{
   [OperationContract]
   int Add(int a, int b);
}

public class MyAsyncClient : AsyncClientBase<IContract>, IAsyncContract<IContract>
{
   public async Task<int> AddAsync(int a, int b) { return await base.AsyncChannel.AddAsync(a, b); }
}

That's my pipe dream. I want to not have to generate proxy interfaces and datatypes, retain compile time errors when the interface changes, and not use svcutil. The IAsyncContract<T> would be enforced to take an interface that is marked as a ServiceContract. It would then take all the methods in the interface marked as an OperationContract and create a new interface with them, but changing their return types from what they were originally (e.g. int, string, List<double>, etc) to async Tasks (e.g. Task<int>, Task<string>, Task<List<double>>).

Right now I think it's impossible for an interface like IAsyncContract to exist and do what I would like, but maybe some kind of autogenerated code could take place on compile could net similar results. Thoughts?

At work we use Amazon SimpleDB for our distributed, redundant database; and Amazon supplies an SDK to use in which to access the service. Unfortunately for some, this SDK exposes all of the calls synchronously, with no asynchronous versions of any web service calls. As such, my initial implementation of data access was something like:

 IEnumerable<MyData> data1;
 IEnumerable<MyData> data2;
 IEnumerable<MyData> data3;
 IEnumerable<MyData> data4;
 
 data1 = GetData1FromSDB();
 data2 = GetData2FromSDB();
 data3 = GetData3FromSDB();
 data4 = GetData4FromSDB();
 
 return DoSomethingCool(data1, data2, data3, data4); 

Now that looks readable and straightforward, but it does not scale. Eventually we got to the point where each of the calls to SDB were retrieving significant amounts of data. Enough to cause site slowness when looking at large datasets. Reading about the handy dandy Task Parallel Library, I modified the implementation to this:

 Parallel.Invoke(
    () => { data1 = GetData1FromSDB(); },
    () => { data2 = GetData2FromSDB(); },
    () => { data3 = GetData3FromSDB(); },
    () => { data4 = GetData4FromSDB(); }
 );
 

Great! Immediate speedup and all was good..for the moment. The data access was parallelized, but the interesting thing about Parallel.Invoke is that it limits itself to the number of processor cores your system contains. It was designed for compute bound tasks, not IO bound ones. Well great, I needed a way to go beyond the number of processor cores in the system, and I played with passing in some ParallelOptions with different parameters to try and mix it up, but settled on this:

 var tasks = new Task[] {
    Task.Factory.StartNew(() => { data1 = GetData1FromSDB(); }),
    Task.Factory.StartNew(() => { data2 = GetData2FromSDB(); }),
    Task.Factory.StartNew(() => { data3 = GetData3FromSDB(); }),
    Task.Factory.StartNew(() => { data4 = GetData4FromSDB(); })
 };
 Task.WaitAll(tasks);
 

This implementation queues up all the tasks in the ThreadPool and goes to town. It's not limited by the number of processor cores, but by the size of the ThreadPool. Nice. But this implementation and the one above share another problem: Even while the tasks are blocked and waiting for data from SDB, it is still holding onto a Thread in the Threadpool. What I really needed was an asynchronous version of the SDB SDK but I don't want to rewrite their entire SDK to do it. After some more research into the Task Parallel Library and its compatibility with the Asynchronous Programming Model, I came up with this implementation:

 var tasks = new Action[] {
    () => { data1 = GetData1FromSDB(); },
    () => { data2 = GetData2FromSDB(); },
    () => { data3 = GetData3FromSDB(); },
    () => { data4 = GetData4FromSDB(); }
 }.Select(a => Task.Factory.FromAsync(a.BeginInvoke, a.EndInvoke, null)).ToArray();
 Task.WaitAll(tasks);
 

See what I did there? I took each data accessor and wrapped it into an Action via a lambda expression. Action's (and Func's) contain built in BeginInvoke and EndInvoke asynchronous versions of their execution. Nice. Now I just needed to batch them up and wait for them all to execute before continuing. I wrapped them into Tasks using Task.Factory.FromAsync and then issued a Task.WaitAll to wait till they finished. I then abstracted the functionality into an extension method:

 public static void InvokeAsyncAndWaitAll(this IEnumerable<Action> actions) {
    Task.WaitAll(actions.Select(a => Task.Factory.FromAsync(a.BeginInvoke, a.EndInvoke, null)).ToArray());
 }
 

I can create multiple extension methods for each type of Action and Func as well (the Func version would need to return some type of collection). The nice thing about this is that all the data access happens asynchronously (though I have no control over when the thread sleeps during the data access), and data access is parallelized as well. Additionally using the Task Parallel Library lets the code look readable and definitely more maintainable than using some type of sync'd/locked counter for checking when all data accesses complete.

Went to the gym last night and discovered they are transitioning to a new authentication system where instead of scanning your card, they instead take your fingerprint.

1. Hi! Who are you! What's going on?!
2. ALL RIGHT LET'S DO THIS!!! WOOOO
3. WE ARE DOING IT!! YEAAAHH
4. oh shit something went wrong
5. Everything turned out better than expected