Blogbody

With the upcoming release of WebWork 2.0 beta 2 (just waiting for Ognl 2.6.4 to be released), I'm going to begin a document-a-day effort on my blog. Essentially, I'm going to document some feature at least once a day and post it here. Hopefully someone will consolidate these in to a real document :)

To kick off this announcement, I'm going to point out yet another reason why Struts is really bad (I won't say sucks, I already said that in my title :P). Look at this taglib, last commited by Craig McStruts himself.

There are two important things to note here:

Object args[] = new Object[] { arg0, arg1, arg2, arg3, arg4 };

That is the code that constructs the arg list for internationalizing messages. Notice something terrible bad here? No? Let me spell it out: your i18n messages can only have four arguments! I guess you better start chopping your messages up to support Struts.

The bigger, more annoying thing that this implies is that the number of args is not dynamic. The args are specified as tag attributes arg0, arg1, arg2, and arg3. And since these attributes aren't evaluated against any sort of expression language, the only way to use dynamic values for these args is to either use javascript (NASTY) or to use <%= someString %>. Both suck.

There are a few things going on here. In WebWork, this could be done by doing:

 <ww:text name="'i18n.key'">
  <ww:param value="someExpr"/>
 </ww:text>

• dynamic number of params are supported
• easy access to a bean property via someExpr

In Stuts "someExpr" wouldn't work because the only way to access bean properties (formbeans) is via the bean:property tag. And of course, you can't do a JSP tag in the attribute of another JSP tag (at least not in pre-2.0 days, not sure about post-2.0).

The most disturbing thing of all this is that no one in the Struts community has complained (at least enough) for this to change? This is just typical of Struts users -- they either don't develop any real applications that demand a good framework, or they just live with Struts acting as a very poor wrapper around raw servlets.

Posted by Patrick Lightbody at 12:08 PM | Permalink | Comments (11) | TrackBacks (2)

My mother just sent this article to me:

t r u t h o u t - William Rivers Pitt | Anyone But Bush

Without getting too much in to a political diatribe (I know most of my 3 whole loyal readers are here for technology rants, not politics), I pretty much agree with everything said there. I am a democrat, but mostly because of the social issues they support. I hate to admit it, but I am probably pretty similar to Arnold in my political views -- except for the fact that he voted for prop 187.

So I don't hope Bush doesn't get re-elected because he's not a Democrat (God forbid Lieberman became President, he's probably just as bad!) -- but more because he's a slime ball. What saddens me the most about Bush's term is that it has made very painfully obvious how gullible and, dare I say it, stupid the majority of US citizens are. In my ignorance, I truly thought we were past that.

Posted by Patrick Lightbody at 11:46 PM | Permalink | Comments (2)

After seeing a comment on of my previous posts from the author of Jameleon, I've decided I need to take another look at it once the documenation on the site has been updated to give examples that aren't so cryptic. I can't imagine that someone would purposely create something that makes testing harder, so I must assume that I just didn't understand the project. When I get a chance I'll be sure to look in more detail.

But Christian, you must get rid of those cryptic examples -- they only hurt my head! :)

Posted by Patrick Lightbody at 11:35 AM | Permalink | Comments (2)

I recently finished reading The Tipping Point, where the author discusses how epidemics can start (be tipped) by tiny things, such as who is delivering the message. He gives an example of this in Paul Revere's ride, and how people listened to him because Paul was a likeable, social guy who seemed to have a smart head on his shoulders.

While that all made sense to me, I hadn't really seen an example of it really "in my face" until I saw this post on TheFeature.
The author clearly states that he would check out Spoke solely because Mark Granovetter (on our Technical Advisory Board) was the one who invited him. I'm sure that if I had invited this guy, I wouldn't have had nearly the same impact.

Anyway, I just thought it was interesting to see someone actually spell out one of the core concepts presented in The Tipping Point. Usually it's not so obvious :)

Posted by Patrick Lightbody at 11:31 AM | Permalink | Comments (1)

A couple weeks ago I ranted about a post I found on a Wiki regarding REST. While I still hold by my opinion that spending time arguing between calling it an application protocol vs. a transport protocol is pointless, I guess I might have gone a bit overboard.

Afterall, I do have several friends both at work and in the opensource community (jkk, joe, etc) that are believers in REST. I don't want people to think I'm just some guy spouting off who has no idea what he's talking about. Hmm... actually, that's probably pretty accurate :) But really, I want to make it clear that I do understand the point of REST -- I just don't see it as a viable alternative as long as there aren't really good tools available.

When I refer to tools, I imagine a REST "tool" being about as useful (and complicated) as a database -- you know, that thing we all take for granted now. What I'm saying is that for a concept like REST to really take off, there needs to be a large and complex framework available that makes it easy to expose complex resources -- not just simple CRUD operations thinly masked over a database.

Without this tool support, your REST architecture won't have a standard foundation to continue to build upon. In fact, your REST architecture will only work with your REST clients, and to get more REST clients (a primary motivation for this style of design) one needs to provide the clients with simple access to the resources: tools.

So you're going to have to build your own tools, in house, rather than spending time solving the business problem at hand. What I envision, instead, is a "standard" (more like vendor) built on top of REST that provides things like XML marshalling, automatic URI resource mapping, query support, interceptors between GET/POST/PUT/DELETE and the final dataset, and caching.

These are thigns that generally must be addressed anyway, and having each project that uses REST re-invent the wheel is just silly. REST is too general to be built upon by itself, it needs a standard tool; otherwise it's just an ethereal concept that could probably be hammered in as a solution to any problem... and everyone knows hammering is never good.

Posted by Patrick Lightbody at 11:21 AM | Permalink | Comments (3) | TrackBacks (1)

Ross Mayfield pointed out that Business 2.0 awarded Social Networking as the Technology of the Year. The article is actually very brief, but it does discuss the difficulties of such technologies when it comes to privacy.

The way privacy is handled between Friendster, and Spoke seems to be on polar opposites. Because Friendster requires you to go through a process of approving people as your friend, the friend has the control over some levels of his or her privacy. The end result is a smaller graph size but with much richer nodes in the graph.

Spoke, on the other hand, takes a different approach. You are "connected" to someone not if you know them, but rather if they say they know you. "Knowing" someone is done by having their basic contact information (as minimal as an email address sometimes). Because there is no approval process, the network is MUCH larger. This is due to the simple fact that most of the nodes in the network are not users of Spoke, but rather just "people" that Spoke has discovered that are known directly by some user of the system.

This approach of course requires much more careful consideration of privacy. When you find a person on Friendster, you can immediately tell how you know that person (Jane knows Bob who knows Mary). In Spoke, this information isn't available, because people generally want to protect some of their relationships. Rather, Spoke only tells you where the path starts ("talk to Jane, she can help"). Then it is up to the next link in the path to carry on the request (Jane asks Bob, Bob asks Mary).

I'm interested to see what people think of these two approaches. Being a developer for Spoke and also a user of Friendster, I see advantages on both sides. Is this difference of privacy (and graph size) just the difference between corporate and home social network software? What about companies like LinkedIn that appeal to the corporate world but take a more Friendster-like approach? Where do they fit in?

Posted by Patrick Lightbody at 11:02 AM | Permalink | Comments (0)

In the last few months I've been exposed to REST as an "architectural style". I won't get in to whether it's good or bad, mostly because I just don't care. What I do want to point out is that there are a lot of nutcases out there when it comes to technology. Last night I came across this:

HowSoapComparesToRest - RESTwiki

I think you're missing the point. You are assuming that HTTP is a transport protocol, and that it therefore exists to carry bits, of which a SOAP-RPC message, which includes a method, is a valid payload. HTTP is not a transport protocol, it is an application protocol. It doesn't send bits, it transfers representational state. If the body of a POST or PUT is not a piece of representational state, you're not doing REST. HTTP already defines the methods, it doesn't need new ones inside the POST body --MarkBaker

Now, correct me if I'm wrong, but isn't HTTP the hypertext transfer protocol? I *hate* wackjobs that insist on fuddling over whether it's an "object or a resource", or claiming "it's not a method call, it's a POST". Honestly, what does that mean? Have you nuts ever heard yourself talk? So what if I call it a method. In fact, if your REST architecture is any good I'd hope it has method facads to help your mere-mortal developers inch along.

Some people agree that REST could actually be applied to non-HTTP technologies; because, to be quite honest, those verbs (GET, POST, PUT, DELETE) can easily be reproduced as method calls:

public Widget getWidget(int id);
public void postWidget(Widget w);
public void putWidget(Widget w);
public void deleteWidget(Widget w);

Now some might freak out and say my getWidget() call shouldn't take an id but rather a URI. So what, that can happen under the covers. People seem to forget that when building software there is only 1 thing that matters: *getting the project done on time and within budget*. So what if it's written in PHP if the job gets done -- I know the business people sure don't.

However, let me qualify what "getting the job done" means. It means completing whatever task you were given. Now, if the task were "create a REST architecture" then I guess you don't have much of a choice do you? But if the task is "create project X based upon specs Y and make it extensible for Z" then I can't believe that REST is the only way to do this. Or C++, ruby, PHP, Java, JSP, EJB, SOAP, etc. You get the point.

But let me point out why I would claim that REST is probably the worst technology of choice: tools. SOAP, Java, EJB -- they all have tools, good tools, to help developers utilize the technology. Tools are often overlooked by the supergeeks because they are too caught up in the religion of it all that they can't see people struggling to work with their fancy new technology. If you're working on Java and SOAP, you use Glue -- it's a great tool. For EJB, you use an application server + maybe XDoclet. If you're writing Java, you have this wonderful tool called an I-D-E. It helps you compile and write code and see errors before they happen. Fancy that!

But what tools are there for REST? ... Exactly. So I don't stand here claiming it's bad. I stand here claiming that it's bad *right now*. Sure, you might be able to create some tools specifically for your project, but then you're probably going to miss the requirement that all project boil down to: "in time and under budget". If you can pull it off, more power to you (maybe you can donate your tools to the community too?)

In the meantime, I'll stick with simple tools, like a compiler, to get the job done. The fanatics can keep taking about resources and URIs, but they often forget that underneath it all, a *method* is getting called somewhere and an *object* is being passed around.

Posted by Patrick Lightbody at 11:35 AM | Permalink | Comments (0) | TrackBacks (1)

I recently completed an acceptance test framework for my company, Spoke.

The framework is built off of JWebUnit and HttpUnit and provides a single SpokeTestCase that all acceptance tests must extend. The setUp() method of SpokeTestCase does the following:

• connects to the DB
• drops all open connections using a stored procedure
• restores the DB from a backup that was in CVS (copied via the network filesystem)
• makes a GET call to our 3 servers and instructs them to "reset", causing a new connection pool and caches to be cleared
• sets the base URL for JWebUnit to http://localhost

Because our DB backup snapshot is small and our 3 servers are only started once (right before running the test suite), the overhead for each test is around 3 seconds. This allows us to run several thousand tests over night.

One interesting project I'd like to integrate with is FIT. The concept of providing a JWebUnit-style interface to a Wiki such that non-engineers could write some tests is very appealing.

One particular project that looks utterly useless to me is
Jameleon. Mike Cannon-Brookes pointed it out to me, and while Mike is generally a smart guy, he's smoking crack on this one. Honestly, how does this look at all useful to anyone:

<jmln:httpunit-session application="tutorial">
<jmln:jmln-tutorial-home-page
functionId="load start page"
tutorialHomePageLinkText="here"
tutorialHomePageTitle="Jameleon Tutorial - Start"/>
</jmln:httpunit-session>


I think that JWebUnit does a GREAT job and making things very manageable. FIT is nice for providing an extra layer on top of that so that non-coders can get involved. Jameleon doesn't seem to offer anything to me except a very large migrane. Am I the only one missing the point?

Posted by Patrick Lightbody at 10:57 AM | Permalink | Comments (3)