Monthly Archives: November 2010

Getting paid to do something you love doing is awesome!

Posted by on November 15, 2010 No comments

A lot of people who work, don’t like their job. It’s a fact. If you were at a party and you asked people if they like the job they get paid to do, the response would be largely negative. That you are reading this, on this blog, indicates that you are probably a programmer. Then, on the assumption that you are in some capacity employed as a programmer, I can say to you that you are a lucky person.

Why?

It is simple, really: A large percentage of the programmers I have met,  have worked with or follow on Twitter absolutely love to write code, whether it is for a website, a desktop application of some kind or they are just monkeying around with something. They love it! I love doing it. A number of my friends love doing it. And the best thing?

We get paid to do it!

Don’t get me wrong here, I know plenty of people who turn up at 9am and go home at 5pm and wouldn’t even consider writing anything for themselves or doing any open source work. For them, it’s like a factory job, albeit a (generally) much better paid one. Jeff Atwood (love him or loathe him) has a great post about these sorts of programmers titled “There are Two Types of Programmers”. Even though these programmers might not code in their spare time, I’d still say that 99% still like their job.

I’ll place myself firmly in that 20% block of programmers though. I wouldn’t say I was a rock star programmer, I’m certainly not bad, but I do always want to constantly improve myself and my ability. As the old saying, “Practice makes perfect”. I definitely love my job. Maybe I could do without some of the meetings and the office politics which comes from working in a large company, but still, I love what I do.

I get paid to do what I love doing; I consider myself lucky.

Damn you empty catch block

Posted by on November 8, 2010 3 comments

In the code I help maintain in my day job, I see a lot of the following code:

try
{
/* code */
}
catch(Exception)
{
}

I see it in several different languages almost daily. It really frustrates me that my colleagues and predecessors did this. I stamp it out ruthlessly.

Here is a great post on why empty catch blocks are bad. Here is a great question and series of answers on StackOverflow about best practices for exception handling.

Github C# API: Handling the response with RestSharp

Posted by on November 1, 2010 No comments

Once we make a request to Github.com with RestSharp, we get a response, and RestSharp gives us a RestResponse object, with which we can do something with the content. The content will be in the format that we specified when we made the request, either JSON, XML or YAML.

Oh crap, complicated string parsing…

RestSharp to the rescue! We don’t have to worry about parsing the response content, because RestSharp can do it for us.

What we need to do, is model the response content into a POCO (Plain Old Clr Object):

public class User
{
	public virtual int Id { get; set; }
	public virtual string Login { get; set; }
	public virtual string Name { get; set;}

	...
}

Note that in this User class, I’ve made the properties virtual, this is not necessary for RestSharp to function correctly, it’s more habit on my part from working with NHibernate; however it does mean you can reuse the same models with NHibernate (if you wanted to do something like store the response in a database, for example).

Then we need to modify our client such that when we execute the request, we instruct RestSharp to construct an instance of the User object. Create the client in the usual way and also create the request in the usual way. The magic is in how the client executes the request:

var request = new RestRequest
				  {
					  Resource = string.Format("/user/show/{0}", username),
					  RootElement = "user"
				  };

var response = client.Execute<User>(request);

var user = response.Data;

As you can see, the Execute method has a generic overload. Internally, RestSharp detects that because we have used this overload, we want to deserialise the response content into an object of the given type, and it performs the deserialisation and constructs an instance of the object. The way that it does this is by looking at the Content-Type header in the response, and it uses the correct deserialiser depending upon the Content-Type. You can see more detail about this on RestSharp’s Github project pages.

It is really easy to work with the response from your REST request with RestSharp, you can access the raw string content of the response, or deserialise it into a POCO – it’s up to you.