One of my best friends from college once described a previous job in the financial industry as something akin to "giving guns to monkeys."
He felt that the product he sold, although it was something that could reap tremendous benefits for his customers if used properly, was something that more often than not harmed customers' livelihoods because the tool was too unwieldy and naunced for the average person to use correctly.
Like my friend in the financial industry, programmers are faced with a similar quandry - do we give our users enough rope to potentially hang themselves (more freedom) or do we provide a more authoritarian, constrained, "baby-proofed" experience (less freedom?)
All programmers are UX designers
Giving guns to monkeys and baby-proofing aren't about bugs or errors in the software. The concepts are both about making judgement calls in user experience design, and it's not just the UX gurus who have to worry about this sort of...
I've been meaning to give RestSharp a go since I first started using Hammock in my startup project's codebase, just because I had heard some good things about RestSharp's auto-parsing capabilities.
This weekend I cobbled together a small example using del.icio.us' RSS feeds (not to be confused with its draconian REST API) for users and RestSharp performed magnificently, although its POCO -> XML Element mapping process requires a lot of experimentation before you get it just right.
During the month of May, 2010 I took an unpaid leave of absence from work for the entire month and set off to launch my own web-based startup company.
My objective was to take a month off work, shut myself away in my apartment, spend a month coding up all of the basic plumbing I needed to get the first core part of my service in working order, and profit. Needless to say, I failed to reach my goals, but not for any of the typical reasons like poor project planning, lack-of-focus, and so forth. No, I failed because I took the experiences of other entrepreneurs too literally and tried to “be my own boss,” without appreciating what that really means.
Success doesn't occur in a vaccuum
Discussion: How to Use RestSharp / Hammock to Automatically Parse the YouTube Response Format into POCO Objects
If you've been following me on Twitter over the past couple of weeks, you might have noticed that I've been a little frustrated with the YouTube GData API lately. Simply put: XML makes me sad. Since that frustrated Tweet I've developed a solution using LINQ-to-XML and a bunch of hard-coded namespaces which isn't how I would prefer to do it.
I would much rather use the built in object deserialization capabilities in RestSharp or HammockREST. I'll be honest - I do not have a damn clue how to use Hammock's built-in deserialization capabilities. I tried tinkering with it on my own to no avail, and there's not much documentation to speak of.
RestSharp has some more detailed documentation on its deserialization capabilities, but it doesn't answer some lingering questions I have. So without further aideu, I'd like to solicit the opinion of the developer community....
I recently developed a self-sorted IList implementation for a project and I needed some automated way to unit test it - so naturally, the best way to automatically test a sorting function is to force it to sort the results of an unsorting function ;). Just for reference, IList is the interface implemented by every sort of List<T> variant in the .NET Collections library, with the notable exception of SortedList which is really a misnomer given that it actually implements IDictionary instead of IList.
I was excited at the prospect of developing my own unsorting method, but sadly a quick Bing query revealed a couple of solutions developed by programmers far more diligent than I, and I decided to roll both of their solutions into a pair of generic extension methods which I have tested and built into my solution. Let's take a look at them:
Solution 1 - Randomizing an IList<T>...
I feel a little bad about posting this given that Jon Boutelle, the CTO of SlideShare, already admitted that this portion of the SlideShare 2.0 REST API sucks and that they're going to fix it eventually, but given that I'm in the middle of rewriting my original SlideShare Presentation XML deserializer I wanted to post my current solution to this problem and solicit the opinion of the .NET community in order to find a more elegant solution, if one exists.
Here's the problem - if you're trying to query any number of presentation objects from SlideShare, you're inevitably going to make a call to get_slideshow or to some method which depends on it. That's an unavoidable fact of life when you're dealing with the SlideShare API. For the most part, the SlideShare API's response format is intuitive and intelligible - here's an example response using...
I wanted to repost a presentation that I saw on Twitter yesterday which highlights some interesting trends in the state of open web APIs across the board:
Here are some cliff notes:
- SOAP is losing marketshare to REST or SOAP's share is simply being dilluted by the avalanche of new REST APIs - the charts don't make it clear;
- JSON is on the rise;
- OAuth is surging and is now adopted by 80+ services; and
- APIs are maturing in their practices.
The project I'm currently working on involves numerous REST APIs from a multitude of very different services. In my initial prototype, which I've since scrapped, I went with trying to use a local wrapper for each REST API incorporated into my project, meaning I used the GData library for handling YouTube, FlickrNET for Flickr, etc...
As you can imagine, having N libraries for N different REST APIs in my service snowballed into a maintainability nightmare. In my new redesign I decided to use a generic REST wrapper in .NET, and as it so happens there are two full API-agnostic REST libraries in .NET: HammockREST and RestSharp. If there's one thing you can fault both of these libraries for, it's lack of documentation - they're both new comers to the .NET open source community, so I'm going to contribute some documentation for Hammock and RestSharp, starting with...
All user input is evil, and you know it. Since the inception of .NET, ASP.NET developers have had access to the ASP.NET Validators Control Library, which made the previously tedious process of validating form input simple and in many instances, trivial. Microsoft's Enterprise Library makes this familiar ASP.NET functionality available at the object level in your applications via the Validation Application Block, which I've been using throughout some of my new projects.
It can take a while to get familiar with the Validation Application Block, so my goal here is to show you how to quickly get started with it using attribute-based validation, which in my opinion is the simplest way to implement validation. By the time you're doing reading this you'll know how to use built-in validators such as the RangeValidator, RegexValidator, DateTimeRangeValidator, and so forth.
Introduction to the Validation Application Block Built-in Validators
I write a lot of parse-heavy applications, so naturally I spend a fair amount of my development time writing and testing regular expressions. Regular expressions are one of those programming constructs where you always have a clear idea of what you need to do but you work with them just infrequently enough that you can never actually remember the exact syntax. And if you're like me, this means a multi-hour regex 101 refresher until you get it right.
Rather than testing my regular expressions in the middle of a unit test or in some temporary debug code, I've started using .NET Framework Regular Expressions Demo (scroll down to the bottom) provided by Regular-Expressions.info. It's a simple Windows Forms application that allows you to run quick regex tests using the System.Text.RegularExpressions engine, which is nice because it's actual regular expressions engine you'll be using in your .NET production code.
Let me show you how it works using a couple...