In my Pluralsight course, Automated Testing for Fraidy Cats Like Me (an introduction to Unit Testing and TDD), I presented a use case that required retrieving  the date of a person’s most recent tweet.

The process of accomplishing that and then completely reworking it again this morning, made me think some more about how we accumulate knowledge even when we don’t have the need or time to take on learning about a big topic.

I’ve learned a lot of things by accident and because I’m curious and something of a pit bull, these become detours to otherwise productive days.

If you follow me on twitter, you see the random, seemingly unrelated things that I’m constantly wrestling with. Here’s an example.

Many Moons Ago, I Had a Silly Idea

I started with a stub method that just returned a date but I wanted to make it a little more real. I ended up spending hours and hours on this, trying to figure out the non-authentication API call to get the data.

Finally I was able to come up with a way to do that:

https://api.twitter.com/1/statuses/user_timeline/julielerman.json?count=1

Note that this was using version 1 of the twitter API and did not require authentication so it was easy enough to use this in my sample.

Then I needed to call it. I wasn’t used to making web calls from outside of some type of web application. So it took me a while to realize that I needed to use System.Net.WebClient.WebClient to execute the call. And exactly what call I wanted to execute took some time to discover as well. Naturally. It turned out that I wanted to use the DownloadString method.

 var uri = new Uri("https://api.twitter.com/1/statuses/user_timeline/" + twitterAlias + ".json?count=1");
 var client = new WebClient();
 var result = client.DownloadString(uri);

So I finally have the tweet. It’s was as string …not pretty. And I had to parse it to get at the DateCreated. I did some more searching and came upon a library I’d heard of (always with accolades!) countless times but had never had the chance to use: JSON.NET.

A little more exploration helped me learn I could use the API’s JObject class to parse the string into a recognized object

const string constTwitterDateTemplate = "ddd MMM dd HH:mm:ss +ffff yyyy";

and then extract the property I wanted:

o["created_at"]

But that didn’t work because it turned out that twitter has it’s very own special way of representing a date. Uggh! Back to GoogleBing for quite some time and I finally came up with the format and then how the heck to transform that format into one that could be read by .NET.

const string constTwitterDateTemplate = "ddd MMM dd HH:mm:ss +ffff yyyy";
var createdAt = DateTime.ParseExact((string)o["created_at"], 
        constTwitterDateTemplate, new System.Globalization.CultureInfo("en-US"));

Finally! I had a System.DateTime I could use!

In the end, I had a handful of lines of code to do what I wanted

public DateTime LatestTweetDateAsUtc(string twitterAlias)
{
  var uri = new Uri("https://api.twitter.com/1/statuses/user_timeline/" + twitterAlias + ".json?count=1");
  var client = new WebClient();
  var result = client.DownloadString(uri);
  var jsonString = result.Replace("[", "").Replace("]", "");
  var o = JObject.Parse(jsonString);
  const string constTwitterDateTemplate = "ddd MMM dd HH:mm:ss +ffff yyyy";
  var createdAt = DateTime.ParseExact((string)o["created_at"], 
    constTwitterDateTemplate, new System.Globalization.CultureInfo("en-US"));
  return createdAt;
}

But it had taken me hours and hours and hours to get to this.

The upside is that I learned about JSON.NET and got a basic understanding of its use.

The date transformation is one of those esoteric things I will forget I’ve done and have to search on the web next time I find I need to use it…this could be years from now. And WebClient…that could come in handy but I don’t foresee a lot of use for the work I do.

Other than the long-overdue exposure to JSON.NET, it was a wasted afternoon.

6 Months Later, I Came Across a Better Way

What I hadn’t discovered was TweetSharp. Because the v1 Twitter API is now depracated, I have to use v1.1. But v1.1 requires EVERY CALL to be authenticated.

So I had to sign up for an application key (https://dev.twitter.com/apps).

Then I looked for some help with how to authenticate my app. The code was a nightmare. More learning curves.

Then I found TweetSharp.

Within 1/2 hr I had authentication set up and figured out how to get a users’s latest tweet. And the best part was TweetSharps Tweet class does the work of transforming the date to a DateTime for you. (Using JSON.NET and possibly code similar to mine. I get I can figure that out by looking at the code on github. 🙂 )

      var service = new TwitterService(_my_ConsumerKey_providedbytwitter, my_ConsumerSecret_providedbytwitter);       service.AuthenticateWith(my_Token_providedbytwitter,my_TokenSecret_providedbytwitter);       var user = service.GetUserProfileFor(
                    new GetUserProfileForOptions {ScreenName = "julielerman"});       var tweet = service.ListTweetsOnUserTimeline(
                   new ListTweetsOnUserTimelineOptions{ UserId = user.Id, Count = 1 }).FirstOrDefault();       DateTime thedate = tweet.CreatedDate;

So….for many, nothing new here.

A Lesson Bigger Than Just The Code

What’s more interesting to me than the actual solution is the process I went through. Getting that twitter date was just a made up scenario that I decided to pursue for my example. It stopped me in my tracks and I became consumed in solving it, not once but twice. First when I was building the course and second when I wanted to share *that* code and discovered the API no longer worked. It’s fun to learn new little things that don’t require you to read a whole book. So I now know enough to be dangerous about JSON.NET and about TweetSharp. However I’m well aware of my limitations.

It also interested me to consider how this process, repeated over the years, has resulted in my having a quiver filled with a slew of little bits of very useful, somewhat scattered, information. This is very different than learning a big topic, like testing or Entity Framework. However they are a starting point at which I can leverage the tool and make it work for me.

Which somehow ties back to my keynote at CodeStock this summer where I spoke about approaching big learning curves one small bit at a time. For example how I’m currently using and benefitting from pieces of Domain Driven Design even though I’m a long way from understanding or being expert at the *whole* thing. However my pursuit of DDD is hardly accidental! I’m working diligently to understand it and use it (and share what I’ve learned).

I’m not sure if I’ve wrapped up with anything useful here but I got what I was thinking about out of my head so I can get back to wrestling with my next topic!

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!