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.
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.
On November 5th I gave a talk at the Twin Cities .NET User Group entitled ‘Using web service APIs in your applications’. I started out with a very brief overview of how REST APIs work and then talked about the current state of using REST APIs in .NET. I followed that up with a demonstration of a new OSS project I’m working on for making accessing REST APIs much easier. The project is called RestSharp but in the talk I refer to it as Stillwater as that was my working name for it prior to coming up with the final name.
Next I put RestSharp to use by writing a Twitter search bot that runs as an Azure worker role searching for mentions of a search term and then creating FogBugz tasks from the results. Then I demonstrated using Twilio to receive phone calls (utilizing ASP.NET MVC) and create FogBugz cases from those incoming phone calls. And lastly I demonstrated how to use RestSharp with Twilio’s REST API to initiate an outgoing phone call from a .NET app.
This was my first formal technical presentation (I gave one at jQuery Conference, but that was much more informal) and you can tell early on in the video. Stick with it however, things smooth out as they go along. Also, the audio is a little tinny with some minor background noise, but it’s not unbearable.
I’ll be posting more about RestSharp/Stillwater soon as I get closer to launching it. You can follow @RestSharp on Twitter, follow the project on GitHub or visit the official site (nothing there yet though).
Watch the Video (49:25)
Download (right click, save as): MP4 (103MB) | WMV (135MB)
