As I’ve mentioned previously, I’m someone who likes his code logical and tidy. While I’m just as guilty of playing the F5 game (a.k.a. “try it and see”) as any other developer, it really bothers me when I write code I don’t understand. I’ll spend hours researching a handful of lines of code in a sample posted on someone’s blog. I like to think that it makes me a better programmer. After all, I’ll be in a much better position if I have to write something similar in the future, or to troubleshoot any bugs that appear. And those pesky bugs love hiding in the dark corners of your code.
But that habit of mine can also lead me down some rabbit holes. I’ve given a name to one hole I tumble into on a regular basis. I call it “Fighting the Framework.”
First, a definition. Fighting the Framework occurs whenever you, the programmer, begin second-guessing the code library, development environment, or other tool designed to make your life easier. This second-guessing might happen because you’re convinced that the framework is too heavy, carrying unnecessary baggage when you only need a few lines to handle a particular case. It could happen because the style or idiom of the language is unfamiliar to you. It might be because the framework gets between you and the metal, forcing you to deal with high-level abstractions when you already understand the fundamentals. Whatever the reason, when you’re Fighting the Framework, you’re doing the programming equivalent of swimming upstream. The flow is against you. Everything seems harder than it should.
It’s at this point that I’ll waste hours of time researching alternate frameworks, refactoring already working code, staring off into space, or reading Slashdot. When you see a programmer doing things like this, it’s the equivalent of a child pushing peas around on the dinner plate, trying to find a configuration that tastes better.
Eventually, you just have to accept the fact that every possible configuration of peas on the plate will taste exactly the same — ick — and eat them. Don’t fight the framework. You picked it for a reason. It’s good for you. Perhaps even character building.
I’m in exactly this position with Microsoft .NET right now. Gordon and I picked the Microsoft platform for two solid business reasons:
At the same time, our choice of platform comes with some hefty drawbacks.
Deciding what technologies to use in your product is hard. ReadWriteWeb lists five things to consider when picking a platform. Eric Sink provides guidance about building on solid foundations. Yet despite all the great advice, it isn’t easy to settle on one or two core providers. Especially when you feel you have to accept their entire programming paradigm, warts and all.
In the last two weeks, I’ve dealt with no fewer than three different .NET namespaces that have come up short. I could write several blog articles about what was missing — and probably will at some point — but right now I’ve got to stop dreaming of Rails, Adobe Air, or Google Gears. It’s time to take my own advice: Dean, the grass may be greener on the other side, but for now you’ve still got to mow your patch.
Don’t fight the framework.
Just because you can do something doesn’t mean it’s a good idea.
We decided to use the Windows Communication Foundation to drive our REST-based web service. In hindsight, it was a poor choice. REST support in WCF seems like it was a last-minute addition to .NET 3.5. You can certainly hack something together, but I’ve found few real-world examples on the Internet, and most of those sidestep the tricky issues.
Here’s the short of it: WCF was designed for RPC-SOAP. More importantly, it was designed to SOA-enable legacy services that used older communications channels like DCOM. If you’re starting from scratch, and have full control over the output of your web service and the design of your object model, I’d recommend using a different (and simpler) framework.
We’ve gotten a good bit of blog traffic from people looking for help with Windows Communication Foundation and the REST architectural pattern. (It’s good to know that we’re not the only ones needing advice.) Here are the better sources we’ve found so far.
Windows Communication Foundation documentation on MSDN
Good overview presentation on REST and Syndication using WCF
Microsoft’s Picture Services Sample
Justin Smith’s WCF articles on Cybertopian Chronicles
Assorted posts on Rick Strahl’s blog
If you find other useful places to look, let us know!
We’ve been using Firebird as infovark’s SQL database for several months now. It’s an open source fork of Borland’s InterBase SQL server. So far, we’ve been extremely impressed by the database itself. Its companion database administration tool, FlameRobin, is shaping up nicely too. It’s currently in version 0.86, but it handles most of what we need.
Why did we choose Firebird? I’ve worked with a variety of databases during my career, including Microsoft’s SQL Server, Oracle, and MySQL. While we were strongly tempted use one of those, none of them met our criteria. We needed an embeddable, scalable, ANSI-compliant database that we could deploy easily. It also had to have liberal licensing arrangements and low (or no) royalties. That limited our available choices.
Two features persuaded us to give Firebird a try: It was free to use and the entire database is contained within a single file. I’m glad we did; it’s absolutely the right choice for us.
I wouldn’t recommend it for everyone, however. If you haven’t done much work with relational databases, Firebird is not the place to start. While the Firebird community is working on documentation and tools, they’re far behind what you’ll find at a commercial vendor or some other open source products. The Firebird website is tricky to navigate and lacks a search feature. Trying to get pointers from Google is tough, too, due to a certain American muscle car with the same name. (Tip: Search for Firebird SQL to get the database.) You’ll most likely need to rely on a combination of the Firebird website, InterBase documentation, and developer blogs to get specific information.
If you can look past those issues — and they’re common ones in the open source space — you’ll find FIrebird to be a solid database for development across a variety of platforms.
As we mentioned recently, we’re building the infovark server using the REST pattern. Since REST is more a loose set of guidelines than a strict series of rules, it’s hard for implementers to know where to begin.
OK, you could go to the source, chapter 5 of Roy Fielding’s dissertation. Or you could check out the somewhat academic discussions on the REST wiki, though there hasn’t been much activity lately. You can occasionally find good advice from the odd blog post, like the REST for the Rest of Us article at Open Garden. But ironically, there’s not a whole lot of material about implementing REST web services available on the web yet. (If you know of good links, leave a comment.)
For the practical, gritty details of how it’s actually done, you’ll need the Restful Web Services book by Sam Ruby and Leonard Richardson. They describe the principles that inform REST-ian (RESTafarian?) design in detail, taking you step-by-step through two different sample applications. If you’re a Ruby programmer using Rails, you’ll find the book especially valuable, since that’s the language and framework in which most of the examples are done. For those of us using different technology, it’s the thought process behind the examples that is most illuminating.
This is because the key challenge of the REST paradigm is the fact that it can’t really be implemented on today’s web without some workarounds. REST will come into its own with HTML 5. The book steers an interesting course between how REST web services might be done in HTML 5 with how they must be done today. I think the authors get the balance right, but at times it can make for a frustrating read for someone wanting practical advice about building a REST service right now.
But that’s less a criticism of the book than of the openness of the REST concept itself. The occasional what-if digression the authors make is a small price to pay for the amount of sound guidance you get. The appendixes alone, which discuss things like which HTTP status codes and headers are worth implementing and which are worth forgetting, will save you far more time than you’ll lose in reading how great things will be when HTML forms finally support the PUT method.
Until that day comes, keep this book handy.
I’ve just identified a horrible bug in WCF for the .NET Framework 3.5.
A caught exception in a WebInvoke operation will cause WCF to return an HTTP 400 Bad Request status code to the client. Any caught exception. Every time. Regardless of whatever error code you might want to send back.
I found the error by mistake. I’d used “BadGateway” instead of “BadRequest” in my code. If it weren’t for other odd WCF behavior, I wouldn’t have noticed that my status code was being ignored.
Consider the following example:
If no error occurs, WCF will return the status code you specify. A try/finally block will work just fine; WCF returns whatever status code you specify. Enter a catch block, though, and it’s nothing but 400 Bad Request.
Hey, if there’s an error, it must be the client’s fault, right?