UPDATED: My choice of layout wasn’t very clear so I’m updating this for clarity…
Twin Cities Code Camp 8 is coming up and I’d like to submit a talk for consideration. REST has sort of been my thing lately but I don’t want to do an exact repeat of my Twin Cites .NET User Group talk.
Which of the following talks sounds the most interesting to you?
Talk #1: State of REST in .NET
Topics covered:
- 5-minute ‘What is REST’: what, why and how.
- Examples creating RESTful services in MVC, Siesta and OpenRasta (in-depth on one method, quick demo of differences with others)
- Examples consuming RESTful services with framework classes, RestSharp, and ServiceStack.net (in-depth on one method, quick demo of differences with others)
- WCF REST Toolkit probably not covered (there’s only so much time you know)
Talk #2: RestSharp in Depth
Topics covered:
- Assume knowledge of how REST works and how to create/consume services
- What RestSharp does and doesn’t do for you
- How it does it
- Challenges encountered while building it
- Future plans
Talk #3: Utilizing Web Service APIs in your Applications
From my MIX10 open call submission: "Can your web application send and receive phone calls? When your employees call your help desk and leave a message are their messages transcribed and a ticket automatically created? This talk will show you how and explore other practical ways to integrate third-party web service (REST) APIs into your applications. Technologies put to use include ASP.NET MVC, Windows Azure, RestSharp (OSS .NET REST client) and more."
The last one is essentially version 2.0 of my TCDNUG talk.
If I get the chance to present I will definitely record it and post it so even if you’re not attending, your feedback is valuable. Which talk sounds the most interesting to you?
I’ve been doing a lot of link sharing lately through Managed Assembly, @dotnetlinks, @dotnetpodcasts, @dotnetvideos and the recently redesigned DotNetKicks. There’s numerous other .NET link sharing sites, linkblogs and other methods so if you want to take advantage of these resources to get your stuff out there, here’s a list of things to make it easier for those doing the promoting on your behalf.
0. Make good content
Enough said.
1. Use accurate but short titles
When possible, keep your titles under 140 characters (less than 100-120 if you want retweets or your username included) so they can be easily tweeted. Make sure your title is a good summary of the content so the promoter doesn’t have to rewrite it. If you use a title that doesn’t reflect the contents or is intentionally inflammatory (say, if you’re writing about exception handling and your post makes good points but uses a linkbait title, I won’t promote it. Not that you care Karl).
2. Use proper HTML titles
A lot of sites automatically grab the title from the <title> tag on your posts. Bookmarklets (in use on MA and DNK) also grab this. If it’s just the name of your site without the post title, it takes extra work for the promoter to copy and paste it. Don’t clutter up your title either. Site name and post name is all you need. All that extra stuff isn’t giving you the SEO benefit you think it is for starters, but it also requires a lot of clean up when posting.
3. Make your Twitter name easily discoverable
I always try to include the Twitter name of an article’s author (and I’m not the only one) when posting links to Twitter. If I don’t have time to go search for you on Twitter it won’t be included so make sure it’s visible on every page of your web site. Unless you don’t care, which is fine too.
4. Include video/podcast length
If you post videos, screencasts or podcasts be sure to include the length of the video or podcast in the post. The length of a video can be as equally important as the title when determining whether or not to watch it.
5. Space out your posts
Maximize your exposure by spacing out your posts. If you write a whole bunch at once, schedule them out to be posted over a few days. Don’t clog up link sharing sites with a bunch of your posts at once as it will dilute the votes you receive.
6. Post stories yourself, but don’t use Twitterfeed
On most link sharing sites, including MA and DNK, self-submitting is allowed. Just don’t ask your friends to vote it up every thing you post. Also, if you have a link you want shared on @dotnetlinks, just do an @reply to either @johnsheehan or @dotnetlinks and I’ll review it.
The Twitterfeed thing is a personal pet peeve. I’m probably already subscribed to your blog if I’m following you on Twitter. I don’t need to know about it twice. If you really, really want to have your feed reposted on Twitter for the people that don’t like RSS, set up a dedicated account for it. Which reminds me, time to go set up @JohnSheehanBlog.
I’m excited to announce that Managed Assembly is now sponsored by TekPub. To celebrate, TekPub has given me two 1-year subscriptions (each a $200 value) to give away. You can learn more about the contest and how to enter on the contest page.
I’m a big fan of what TekPub is doing and the video quality is top notch. While watching the Git series the other day I was thinking, "I wish I could buy this for everyone." While I can’t afford to do that, giving away some subscriptions is the next best thing.
If you recall back to almost a year ago when I launched the site I stated that one of my goals was no ads on the site. I’m compromising on this stance for a couple reasons:
- The sponsorship rewards users of the site and not my pocketbook.
- The contest will (hopefully) help bring in new users and content to the site, increasing its value to everyone.
- The sponsorship doesn’t interfere with the site in any way. I’ve only added a small graphic/link to the footer.
I think this is really an ideal arrangement for the site. Don’t worry, I won’t be adding any big ads to the front page.
Go check out the contest page and win yourself a subscription!
jQuery 1.4 was released today and jQuery founder John Resig said in a webcast that 1.4.x would be shipping with Visual Studio 2010. The jQuery Snippets for VS 2010 project I released in December currently has support for jQuery 1.3.2. How do you think the new version should be handled?
- Do side-by-side releases targeting 1.3.x and 1.4
- Remove support for 1.3.x and only support 1.4.x since it’s the version shipping with VS
- Update existing snippets to 1.4, add new 1.4 features and add additional snippets specifically for 1.3 only in areas where it differs
I’m leaning toward #3. There won’t need to be many 1.3 specific snippets (mostly in the CDN snippets). It may be confusing for those using 1.3 if they encounter 1.4 specific snippets and they produce code that doesn’t work with their version of jQuery.
What do you think? Comment below with your choice.
I submitted a talk for the MIX10 open call for sessions and I need your help! If you could be so kind as to vote for my talk I would be greatly appreciative!
About this time last year I decided that I wanted to make 2009 the year that I really got more involved in the .NET community and started giving back. Here are the goals I had last December (and a few I picked up a long the way) and what ended up happening:
Goal: 52 Blog Posts
I didn’t get there. This post is #43 for the year, which isn’t bad. I had a lot more I wanted to blog about but just didn’t find the time. I’m not sure what my goal for 2010 is going to be. Here are the numbers (with 2008):
Pageviews: 104,088 (89,539)
Feedburner Subscribers: ~420 (~130, biggest jump explained here)
Top Posts:
Self-proclaimed ‘best’ posts, in no particular order:
My popular posts from pre-2009 continued to be popular (in particular Slightly more dynamic ORDER BY in SQL Server 2005 and .NET Cheat Sheet: ASP.NET 2.0 Page Life Cycle & Common Events, both from 2007) and the .NET Cheat Sheets continued to be the most popular page on the blog while also bringing in the most traffic from search engines.
While I didn’t meet my post number goal, overall it was a successful year for the blog.
Goal: Give 1 Technical Presentation
The best way to learn something is to teach it so I set a goal of giving one technical presentation in 2009. Why just one? Well, I want to be a coder who occasionally speaks instead of vice-versa. I also only want to speak about things I’m building or built (to keep the talks practical) and I don’t kick out enough things to be speaking all the time. I ended up doing 1 1/2 talks.
While at the jQuery conference I decided to do an open spaces talk on using jQuery with ASP.NET MVC since MVC wasn’t being represented as well as I hoped it would. I demo’d the .NET Twitter Stream to a room of about 15 people. I think it went well.
I also was fortunate enough to have a chance to talk at the Twin Cities .NET User Group. While working on this talk, RestSharp was born. You can read more about my experience and watch the recording.
I enjoyed giving both talks and I hope to do a few more in 2010. I’ve submitted an abstract for MIX and will try to do more local events like code camps and barcamps.
Goal: Start 1 Open Source Project
I use so many OSS projects that I really wanted to find a way to contribute back to the ecosystem. My first attempt was a library for reversing short URLs, which led me down a road that involved working with a lot of REST APIs. Not wanting to have to write parsers for all of them, I started kicking around the idea of a SubSonic-like project for REST APIs. I was also looking for a topic for the aforementioned technical presentation and things sort of just fell into place. While working on the talk, the concept for RestSharp (then called Stillwater) really took shape. A few weeks after the talk, RestSharp went live on GitHub. Progress has been steady since and a 1.0 release is nearing.
While playing with Visual Studio 2010 I tried out the new support for Javascript code snippets and was disappointed there weren’t any for jQuery, so I cranked out 130 of them and posted them on CodePlex. The project was retweeted by Scott Guthrie, Scott Hanselman and many, many others as well as covered on Channel 9. Thanks to everyone on Twitter and otherwise who helped spread the word!
Goal: 500 Legit Twitter Followers
First let me say the right thing: Twitter follower count doesn’t matter. That said, on January 1, 2009 I had 38 followers on Twitter. I set at the time what I thought was a ridiculous goal of 500 legit followers by the end of the year. I focused my tweets on technical content (very little personal stuff, that’s what Facebook is for), tried to tweet regularly (but not too much) and tried to provide consistent value in my tweets. My count slowly rose throughout the year. Once TweetDeck introduced groups (eventually supplanted by lists) I was able to follow many more people which also helped boost the count. I also aggressively weeded out spammers, SEO scum and other fake accounts so that the count is more legit. In early December I reached my goal of 500 and now sit at 580 (graph). I appreciate every follower and try not to waste their time. It’s really encouraging to see people only following 20 people who are mostly big names and then to see your avatar next to them.
Bonus: Build a Better Community Site
I’ve already written about why I started Managed Assembly so I won’t rehash that. The site is growing and I’m going to keep improving it in 2010 (hopefully with a redesign sooner rather than later). The site has also spun off some Twitter accounts for sharing links which are growing steadily as well.
Bonus: Win a Developer Contest
As a result of my posts on building a hotline with Twilio, I was honored to win the ‘Coordinating People’ category in the Twilio Developer Contest. I don’t use the netbook as much as I thought I would, but it was still fun to win!
Twenty ten
So what’s in store for 2010? I spent the years preceding 2009 focusing on building web apps instead of tools/resources. This year I sort of took a break from the app building to rev up my skills and get re-energized to build stuff. It’s time to put the tools to work. And that’s what I’m going to do. 2010 is going to be the year I start making some of these crazy ideas (outside of the .NET developer community) I have come to life. Of course I will keep talking about the things I learn on here and on Twitter as I go along. I can’t wait to get started!
A few months back I started a Twitter account called @dotnetlinks to share the most recent interesting links that I came across. It was a combination of my submissions to ManagedAssembly and a couple other ad-hoc submissions I made via Delicious. The response has been good so far. Today a couple folks on Twitter were looking for a tech video aggregator and I thought that a .NET-specific one would be a good feature for ManagedAssembly. If you’ll recall, in my www.asp.net series I mentioned a a similar idea for a podcast directory as well. I haven’t built those yet, but as a start I’ve created @dotnetvideos and @dotnetpodcasts that I’ll start feeding with content as I come across it.
For @dotnetlinks, I don’t post every link I come across. I try to pick the cream of the crop to provide a higher signal-to-noise ratio. For videos and podcasts that won’t be as easy to do since I don’t have time to watch/listen to them all. We’ll see how it goes. It would be cool to integrate those feeds with an aggregator on ManagedAssembly to help promote the quality videos/podcasts and ignore the bad ones.
Give them a follow and if you have any ideas or feedback, let me know what you think.
I came across an interesting post today on using Google Analytics data in your ASP.NET apps. In the comments people started complaining that there was no source code download available. I frequently get this request as well and looking back I can only find one case where I provided a download. I’m writing this post to have something to point to when I’m asked next.
Producing Downloads is Time-consuming
Usually when I write about something I’m pulling it out of an application I’m currently working. Taking the time to remove the parts of the code unrelated to my project, testing it out, compiling the download and keeping it updated when people find bugs can be a lot of work and I’d rather be working on another post or project.
You’ll Learn More Putting it Together Yourself
If I give you an example project and you’re not familiar with how it all works you’ll be doing yourself an injustice by not learning how all the pieces fit together. I know there are ‘git-er-done’ types out there that don’t care if they understand how it works as long as it gets the job done, but that’s not my style and I don’t want to support that mentality.
One Size Does Not Fit All
While my examples may be a good starting point for your project, sooner or later there will come a point where my code is not exactly what you need anymore. I’d rather you built something specific to your needs while incorporating concepts from my posts instead of bending what I’ve built to meet your needs.
I’m Not Here to do Your Job
This blog is my outlet to share interesting ideas and projects I’m working on, nothing more. Hopefully my posts give you ideas and tools (like the .NET Cheat Sheets and jQuery Code Snippets) to help you get your job done better and faster, but it ultimately comes down to you to do the actual work. Go make something happen!
There may be times I find it useful to post a download so as a preemptive disclaimer, I reserve the right to post examples when I see fit. But don’t count on it :)
I love Visual Studio code snippets. I’ve always wished that Visual Studio had them for HTML and JavaScript so I was thrilled to see that feature added in VS2010. I also love jQuery. jQuery is shipping with VS2010, but that’s about the extent of the official support for it. I thought there needed to be code snippets for jQuery and couldn’t find any, so I created 131 of them and started an open source project. You can find links to the project/downloads/docs below.
If you have any suggestions, issues, etc. Please let me know. You can follow me on Twitter for updates on the project. Thanks to Dave Ward, Jonathan Carter, and Rick Schott for testing them out and providing feedback.
One of my goals for this year was to start an open-source project. I had an idea earlier this summer while working on Managed Assembly that I wanted a way to reverse shortened URLs. Some providers (like bit.ly) provide an API for this so that requests to reverse it don’t count in the stats they track and also to pass along additional information about the link. This type of library would be useful for blog engines, link sites, twitter clients, etc.
I set out to write a library that would let you plug in providers for URL shorteners to properly expand URLs. Most of them use REST APIs so I started looking for a .NET library for accessing REST APIs. It should be simple I thought. All this library needed to do was basic HTTP and JSON or XML deserialization and I’d be on my way churning out URL expanders. I ended up getting lazy and just doing a simple GET request against a shortened URL and grabbing the redirect header and using that. It works well enough for what I needed at the time.
Fast forward a few months. My fascination with REST lingered and I had a lot of projects using REST APIs using either API-specific libraries (like the incredible TweetSharp) or example libs provided by vendors which are usually pretty terrible. When I decided to give a talk at my local .NET user group on integrating REST APIs into your .NET applications I started creating a little library for my own use so I could focus the talk on the ideas and not so much the implementation. Turns out this little library was extremely useful. I had my OSS project; RestSharp was born.
First Attempt: There be faeries!
I wanted to make calling an API as simple as this:
var bitly = new BitlyApi(account, secretKey);
var response = bitly.Shorten("http://foo.com");
// response.Results["http://foo.com"].shortUrl == "http://bit.ly/abc";
I thought that everything you would need to know to generate the proper HTTP calls would be included in the class definitions (pseudocode):
class BitlyApi {
[GET]
shortenResponse Shorten(string longUrl) { ... }
}
class shortenResponse {
int errorCode;
string errorMessage;
Dictionary<string, shortenResult> Results;
}
class shortenResult {
string shortUrl;
string hash;
}
That pretty well describes the API for that action. To make a long story short, I tried writing a RestBase class and then proxying the method calls through that, turning it into the right HTTP calls and deserializing the result into the correct type. I encountered a few problems that prevented this from working. First, I ran into some limitations of reflection that I wasn’t smart enough to get around. I tried getting my Func<T> on and using other stuff (like Castle’s DynamicProxy) to get around the issues but it was way over my head. Second, how do you describe a URL like this: /accounts/{accountId}/users/{userId}? I could add another attribute for URL format, but I wasn’t interested in a stack of attributes on every method. It wasn’t going to work the way I wanted. I had to be less clever.
Second Attempt: When in doubt, make it simpler.
I stuck with the base class idea but instead of trying to do the work with magical reflection faeries, I would pass a new RestRequest class from each method to an Execute<X>() method in the base class.
public shortenResponse shorten(string longUrl) {
var request = new RestRequest {
Verb = Verb.GET,
Action = "shorten",
ResponseType = ResponseType.Json
}
request.AddParameter("longUrl", longUrl);
return Execute<shortenResponse>(request); // Execute is in RestBase
}
This supported a lot more scenarios. I added things like base URL, authentication handling, etc. to RestBase and it was working pretty well for most of the (relatively) simple APIs I was testing against.
So at this point I had an API that made it easy to write APIs which is what I wanted, but you couldn’t use it to make standalone requests which would also be useful for one-off requests. Goodbye RestBase and hello RestClient.
Third Attempt: No catchy subtitle.
I moved all my HTTP and deserializaition out of RestBase and into a new RestClient class. My bit.ly proxy was updated to include it’s own Execute method that would handle all the common items for every request:
private X Execute<X>(RestRequest request) {
var client = new RestClient();
client.BaseUrl = "http://api.bit.ly";
client.Authenticator = new ParameterAuthenticator(account, secretKey);
request.AddParameter("version", "2.0.1");
return client.Execute<X>(request);
}
The nice thing about this structure is you could use RestClient completely on it’s own. At this point, I had a structure I was satisfied with. There was still a lot of work under the covers to actually do the real work of making the HTTP request and deserializing the result though.
HttpWebRequest is your friend.
Being lazy and not wanting to write my own HTTP library I started out trying to use the HttpClient from the WCF REST Toolkit to do all the dirty work underneath the covers. It has a lot of deserialization options (XLinq, System.Xml, JsonDataContract, etc.) and does an alright job handling the HTTP requests. But there are problems. My biggest issue is my disdain for attributes and if you know anything about the deserializers included in .NET they sure love their attributes and I didn’t want to muck up my proxy classes with all that ugly.
Another problem I ran into came while trying to implement some of the Amazon S3 API. S3 uses a fairly complicated authentication scheme and I couldn’t get the HttpClient to allow me to set the header necessary to authenticate properly (I’ve since been told this is possible, but I’m past the point where it matters anymore anyway). And the last problem is that the WCF REST Toolkit includes a lot of functionality for producing REST APIs as well as consuming them and I wanted my library to be as small as possible. I also didn’t want to be tied to a closed-source library on an unknown release schedule from a company with a propensity of cancelling side projects like this without notice.
I was really hesitant to write my own HTTP handling, but there’s really not that much to it. It didn’t take me long to get a HTTP class with support for the "big 6" REST verbs and I have total control over the requests. It may not be as robust as some other libraries out there like the HttpClient but it does what it needs to do for now.
“Do your HTTP GET and parse the result like a man!” – Miguel de Icaza
I plugged in JSON.NET to handle JSON deserializing (which it handles brilliantly) and started writing my own XML deserializer. I know what you’re thinking, but you’ll have to trust me that this was necessary to allow for some of the convenience features I wanted to build later on.
The RestSharp XML deserializer takes any .NET class, loops through its public properties, then goes looking for the associated XML element (using LINQ to XML) and converts the XML value into the property type. It handles properties of type List<T> the way would hope and you can nest properties as needed to match the XML schema. This ended up not being as much work as I thought it would because there’s only so many CLR types you can represent in XML.
I wanted to add some "smart" features like automatic name matching as well. For instance, when pulling the value out of the XML it will search for an element with the right name and if it doesn’t find anything, look for an attribute with a matching name and use that value if it exists. If it still doesn’t find a value it tries to find a matching element or attribute with a name that might be in a different format. For example if your property is named AccountId and the XML element is named account_id it will find it and use that value. Try doing THAT with XmlSerializer.
After working up a pretty decent XML deserializer, I went back and updated the JSON deserializer to basically do the same thing but utilizing the LINQ to JSON features in JSON.NET.
Putting it all together
With all of this in place, calls to REST APIs are as simple as:
var client = new RestClient();
client.Authenticator = new HttpBasicAuthenticator("user", "pass");
var request = new RestRequest();
request.BaseUrl = "http://twitter.com";
request.Action = "statuses/friends_timeline.xml";
This could easily be wrapped in an API wrapper class, which I will demonstrate in a future blog post.
Early and often
I have a laundry list of features I want to implement but I figured it was better to get this out there in front of people to start getting feedback. I’ve posted the code up at the GitHub project which you can take a look at and start playing around with. I would love to hear any ideas you have. I’m working on the docs and some usage examples and those will be posted over the next few days. Most updates will be posted on the RestSharp site and the @RestSharp Twitter account, so be sure to subscribe to those if you want to keep up to date on RestSharp as it grows up.
