Archive for March, 2008

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

Monday, March 31st, 2008

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?

Tuesday, March 25th, 2008

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 building simple web applications. I don’t think we restrict to a particular technology. In fact, part of the fun would be to watch a Rails expert go head to head against a .NET expert.

As for the Secret Requirement, this can go one of two ways. Option A would be to mandate a large scope for the application. For instance, “Build a Time Card application!!!” The particulars are left up the Iron Coders. Perhaps there are a very small set of requirements handed down, like “user clocks in” and “user clocks out” and “manager pulls report of this week’s time”

Option B for Secret Requirement would mandate a very small requirement, such as “must use the visitor pattern and two factory pattern implementations!!!” This would let the Iron Coders build whatever they like, as long as they use the Secret Requirement. This more closely matches the original Iron Chef in intent, but how easy is it to create these small requirements? Do they provide enough constraint for the Iron Chefs?

I’m going to lean towards Option A, specifying a broad, yet simple, application domain. Leave the particulars up to the Iron Chefs.

Next up we have Judging. This is where it gets interesting, as need to decide how to choose a winner. In Iron Chef America, they judge the dishes with a point scale across three categories: Originality, Taste, Presentation. For Iron Coder, I’d propose the categories to be Originality, Accuracy, and Construction. Let me explain:

Originality would be the judge’s take on how original the Iron Coder implemented the Secret Requirement. The more interesting, unique, surprising the Coder’s web application, the more points here.

Accuracy is measuring the correctness of the application. This one is tough because there may not be that many formal specs, but given that Accuracy is a judging category, we might need them. In any case, Accuracy measures if the application functions properly. If any bugs or inconsistencies are encountered, points are lost here.

And finally Construction, which is measuring the quality and beauty of the code itself. This is a lot like porn: you know it when you see it. Is the code DRY? Does it use patterns appropriately? Does it follow good OO design? Is it a hack, or is it beautiful? If anything, this category is too broad. In any case, it’s very important and must be judged.

Logistics is something I worry about. Watching people write code isn’t exactly exciting, but I think this even should be live. I’d like to emulate a live studio audience, where viewers can chat along with the action. However, I don’t think the Iron Chef’s should be able to watch the chat (not sure how you’d accomplish that one) This is my biggest unknown. What’s a good screen sharing program? How do we deal with small font sizes? Are there any editors that provide a real-time link (SubEthaEdit comes to mind for collaborative editing)?

Finally, it has to be campy. This should be fun for Iron Coders and viewers alike. I think if we can figure out the logistics issues of actually broadcasting text editors, it could be a fun event.

REST, Hypermedia, and JSON

Sunday, March 23rd, 2008

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": "http://example.org/accounts/23242342"
}

However, any JSON client will have a tough time determining what the meaning of the account value is. Sure, it’s a string. But how should it be treated? And how do I express that to my JSON clients? I’m not about to give them a regular expression and say “if it matches, it’s a URI, and follow it!”

Thoughts? How to express hypermedia in JSON?

Why Flickr Doesn’t Do FOAF

Sunday, March 23rd, 2008

Tim Berners-Lee asks “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:

Hello,

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.

Thoughts?

Thanks!
Seth

To which Stewart replied (and I have his permission to quote him):

Seth, I guarantee that the problem is not that we don’t know how to
provide the functionalty - as you say, it’s easy.

It’s more that it has a lot of complications at the social level. How
do you know whether any of our users *wants* their Flickr profile
(potentially filled with cool, beautiful or emotionally important
family photos) to be associated with their Tribe profile (potentially
filled with descriptions of their kinky fetishes)? I know I don’t want
my professional profile on LinkedIn tied to my clownish profile on
Orkut.

Remember http://beta.plink.org/ ? … read about why it shut down. A
lot of those lessons apply to us. I think Dan Brickley is a super guy,
and I think FOAF is well intentioned. But I also think it has nothing
to do with Flickr (or even Tribe/Orkut/Friendster/whatever).

Last, since approximately 0% of users want or care about this
functionality, it’s not a good deal for us to implement it. It’d be
really neat if there were a machine-readable description of who I am
and what I’m up to online tied to a single idetifier, enabling
software that could make all kinds of inferences about me and tie all
kinds of facts about me together. On the other hand, that would really
suck. If you know what I mean.

We don’t even want to get into explaining to people what this is, let
alone build a UI to allow them to opt out, etc., etc.

I appreciate your enthusiasm, and I know you’re coming from the right
place, but it’s just not something we’re willing to support right now.
(And you can quote me if you’d like ;)

- Stewart

So, at least back in 2004, Flickr was concerned about making it too easy to “connect the dots”. I wonder if this still holds true today? Is anyone else worried about this?

I can certainly see Stewart’s point. But I bet with some solid privacy controls, or as Stewart puts it, “opt in” controls, I think a middle ground could be found. Like it or not, sooner or later there will be systems to tie it all together anyway. Might as well preempt it all and put the power into the hands of the users.

UPDATE: Looks like Flickr now exports mbox_sha1sum checksums from their flickr.people.getInfo API call. Someone saw the light. :)

Addressing Doubts about REST

Friday, March 21st, 2008

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

Wednesday, March 19th, 2008

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)
      end
    end

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

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

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

  end
end

In each of my controller tests, I only need to include:


describe DatabasesController do

  it_should_behave_like "Requires Authorization"

Take a look at that! Reads just like English, I would say.

If you haven’t made the jump to RSpec, I’d seriously recommend you give it a shot. You don’t need to abandon all of you existing unit tests. Both sets of tests will run just fine in your Rails project.

Active Record, Parent-Child Relationships, and Validations

Wednesday, March 19th, 2008

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’s cause is validations. There’s a chicken-and-the-egg problem, in that if you wish to add a validates_presence_of :parent_id in your nested child object (which you should, because it helps to enforce referential integrity), then you will not be able to save the parent and the child objects with a simple call to parent.save

Remember, the whole point of the RailsCasts, and this general problem, is that we wish to easily handle nested forms when submitted. We want to create a parent and its children with one simple submit.

Here’s what happens, thought:

  1. class Parent has many Children, class Child belongs to Parent. Class Child also validates_presence_of parent_id
  2. create a new parent
  3. create a new child with parent.children.build()
  4. call parent.save
  5. the save will fail, because child is invalid, because parent_id is null, because validations for children are run before parents are saved (and thus, create a PK)

(oh, and did you know that when saving a new parent that has new children, the parent will cascade the validations down to the children automatically? I didn’t know this was automatic)

Getting back to Advanced Rails Recipes, the author included the Complex Forms examples from RailsCasts. And there’s no mention of this validation issue. So, being the good beta book tester that I am, I created an errata suggesting the mention this problem with validations.

Note, someone with the name of Mina Naguib mentioned this problem in the comments for Complex Forms 1, although I haven’t tried it out (and sorry for not linking to the comment, the RailsCasts blog doesn’t provide an id for each comment).

So, IMO, this is a common requirement of web frameworks that I don’t believe Rails has solved cleanly and elegantly yet. I’ll keep looking around for a good solution. Suggestions welcome!

links for 2008-03-17

Sunday, March 16th, 2008

links for 2008-03-14

Thursday, March 13th, 2008

links for 2008-03-07

Thursday, March 6th, 2008