Showing posts from March, 2008

The Semantic Web in Action Article From Scientific American Online and Free

The Semantic Web in Action, originally published in the December 2007 issue of Scientific American, is now online and free. The original article published in the May 2001 issue of Scientific American was certainly due for an update.

The original article made a lot of grand promises, while the December 2007 article details current efforts at applying semantic web technologies to real life problems. Check it out if you're interested in how companies are building the semantic web today.

What If We Ran an Iron Coder?

I've been a fan of Iron Chef America for a while. Fast paced and some very interesting dishes, it's entertaining and even a bit educational (for the epicurean viewer).

Being a geek at heart, it leaves me wondering what it would take to create an Iron Coder competition. With the right "ingredients" it just might work.

First, we'd need a play-by-play announcer and a color commentator. On Iron Chef America, this single role is played by Alton Brown. We might be able to get away with a single person, but I often like the banter of two announcers. It is, of course, their job to explain what is going on and provide insight and entertainment during the battle.

There is, of course, the Secret Requirement. This brings us to the question of what type of code are the two Iron Coders creating? I come from a web application background, so this is my first assumption. You can't pit an X-Box programmer against a Perl script kiddie. For now, let's stick with buildi…

REST, Hypermedia, and JSON

Enjoying Sam Ruby's latest post titled Connecting, I was reminded that designing a RESTful system means much more than just adhering to a uniform interface (often the first attribute of a ROA that is promoted).

When designing a Resource Oriented Architecture, you mustn't forget about hypermedia and how your resources link to one another, and how those links are expressed through your representations.

Which brings me to JSON. A nifty little format, indeed. And one that, if you are building a modern web service, you should be investigating and implementing. However, if you are indeed building a hypermedia system with JSON, how do you express your links?

I know how to do this in XHTML and RDF, but not sure how to express or render a URI and have it mean "link".

I've love to be able to do something like this:

"name": "Cool Beans",
"account": ""

However, any JSON client will have a tough tim…

Why Flickr Doesn’t Do FOAF

Tim Berners-Leeasks "So do you think Flickr could be persuaded to source FOAF?"

Given what I've heard from Stewart Butterfield (co-founder of Flickr), the answer is a No.

Back in 2004 (Mon, Nov 29, 2004 at 8:41 PM to be exact), I wrote Flickr asking if they could add sha1 hashes of user emails (in an obvious attempt to be able to convert the data into FOAF). Here's the original request email:


Would it be possible to add a sha1 hash of a person's email address to
the response of flickr.people.getInfo ? I understand that we don't
want to give out email addresses, and it's nice that the API doesn't
expose them. But to help in uniquely identifying users across
systems, a good identifier is often their email address. To safe
guard against spam, creating a SHA1 hash is a good way to hide the
email, yet still provide a unique identifier for the user.

This sha1'ed email address becomes a candidate key to the user, so to speak.



To which …

Addressing Doubts about REST

Thinking about REST or need to address some lingering concerns about adopting REST? I found the article Addressing Doubts about REST full of pragmatic, down to earth answers and advice for comparing REST and WS-* (or, RPC).

Nothing new, but a solid collection of answers to how you should think about REST and how you should apply it to your system.

I especially appreciated how the author points out that if you are worried about transactions across your systems, that's probably a design smell and you want to re-think your approach. Never expect that transactions will work reliably across many systems. Instead, build in logic to recover from error states. This is not a REST issue, but instead a large system design issue. REST simply makes it easy to pass the state of your resources between systems.

RSpec is Fun

I've been using RSpec with my latest project, and it's a welcome change from the traditional Test::Unit for Ruby.

RSpec is a more natural way to write tests for your software. It seems to be much easier to compose tests, and anything that makes testing easier is OK in my book.

A specific example of why I'm falling for RSpec:

You can easily group common tests together, and include this grouping in your main tests. Of course you can do this in any number of ways with Test::Unit, but RSpec makes it so clean and obvious.

Here's an example of a very common set of tests that I need to run again all my controllers:

describe "Requires Authorization", :shared => true do
describe "when not logged in" do

describe "when accessing index page" do
it "should redirect to login page" do
get 'index'
response.should redirect_to(new_session_path)

describe "when accessing new database page" …

Active Record, Parent-Child Relationships, and Validations

I've been reading through Advanced Rails Recipes, and so far I like the book. It has a nice collection of tips and tricks for the experienced Rails developer. This is the kind of book that you have to quickly scan through when you get it, so you know what tips are available. Remembering that the book has the solution for your problem at hand is the tough part.

One common requirement for web frameworks is being able to handle nested forms on submit. It's too common to present to the user a complex form, representing many different, usually nested, objects. The difficulty isn't really in displaying or formatting the nested HTML form itself, but in handling the submit. How do you save or update all of the objects easily and efficiently? What if there's an error?

The excellent and always useful RailsCasts had a series of episodes that handle the nested form issue (Complex Forms 1, Complex Forms 2, and Complex Forms 3).

There's a problem with their approach, and it&…

links for 2008-03-17

links for 2008-03-14

links for 2008-03-07

links for 2008-03-05