Not only has this developer ruined the user experience but he’s exposed vital information to a potential villain. E.g. from this message I can tell the site is running SQL Server on the back end. I can tell there’s a table named tbl_Payment_Master which is owned by the built in dbo account. I can tell there’s a primary key on that table and I’m even told the data database name. So I’m all set for a SQL Injection attack. Remember this is a PAYMENT application most likely with credit card information stored therein.

This is just lazy, like the guy doing the rubik’s cube above.

Now basically, the only new principle involved is that instead of power being generated by the relative motions of conductors and fluxes, it is produced by the modial interaction of magnetoreluctance and capacitive directance.

The original machine had a baseplate of prefabulated Amulite, surmounted by a malleable logarithmic casing in such a way that the two spurving bearings were in a direct line with the pentametric fan. The latter consisted simply of six hydrocoptic marzel vanes so-fitted to the ambifacient lunar wane shaft that side fumbling was effectively prevented.

The main winding was of the normal lotus-o-delta type placed in panendermic semi-boloid slots in the stator, every seventh conductor being connected by a nonreversible trem’e pipe to the differential girdlespring on the up-end of the grammeters.

The Turbo Encabulator has now reached a high level of develement, and is being successfully used in the operation of nofer trunnions. Moreover, whenever a barescent skor motion is required, it may be employed in conjunction with a drawn reciprocating dingle arm to reduce sinusodial depleneration.

You can watch the full video here:

The Open Ajax Alliance has been in existence since late 2005/early 2006. In that time I am not sure what they’ve done other than publish the OpenAjax Hub.

The charter is “The OpenAjax Alliance is an organization of vendors, open-source initiatives and Web developers dedicated to the successful adoption of open and interoperable Ajax-based Web technologies. The alliance’s prime objective is to accelerate customer success with Ajax by improving the customer’s ability to mix and match solutions from Ajax technology providers and helping to drive the future of the Ajax ecosystem.”

I can see how back in 2005 the view might have been “hey, there’s a lot of buzz about Ajax, why not form an alliance so we can make things go smooth”. Truth is I don’t think any of these vendors were too concerned with interoperability, at that time they all wanted to one-up each other and get their latest/greatest ajax platform out the door.

As history now shows, there haven’t been a whole heck of a lot of interoperability problems (not due to the openAjax alliance). Since the underlying data of Ajax is XML or JSON, it’s fairly hard to make things not interoperable. Let’s define interoperability in this context;

1. if you combine two or more javascript libraries (in fact the OpenAjax alliance goes even more specific and says “Ajax” libraries) will they each function.
2. Can two or more libraries exchange data.
3. Can two or more libraries trigger or subscribe to the same events.

I’ve probably missed a few things but those are the basics. Unless the library goes completely overboard it’s likely to be fairly safe.

That said, are the so many issues in the field that it warrants formation of an alliance across companies? Hardly.

One reason that interoperability of Ajax frameworks has not been an issue is that folks typically don’t use more than one. The ones they DO mix and match are typically very lightweight and tend not to step on one another’s toes. E.g. Prototype.JS and JQuery* can quite happily co-exist.

So why bother with this Alliance? I don’t know.

These groups make me nervous. They’re typically “name dropped” in meetings when you’re actually trying to get something done. “We can use OpenHub, it’s industry standard”. This is like a grenade going off. The magic combination of “Open”, “Industry” and “Standard” is like the Queen of Diamonds to the Manchurian Candidate. The room perks up and folks align their points of view with the speaker.

OpenAjax Hub amounts to less than 200 lines of JS code, including comments. I challenge anyone to find the download link on OpenAjax.org. Did we need an alliance in existence for 4 years to nail that?

Alliances such as OpenAjax are an example of design by committee that that by their very nature stymie innovation. Think about it, you’ve got 1 or 2 representatives in the alliance from 8 or 9 companies that are otherwise competing with one another. They meet once a week for an hour long con-call. Every new feature or requirement is proposed, reviewed, submitted for feedback over a very long period before being implemented. Hardly agile development.

So what’s my point? I think the ideas put forth by OpenAjax are valid, noble ideas. Interoperability between Ajax frameworks, great idea. But how many times has this issue come up in the real world? If it IS truly a problem I’d argue we don’t need an alliance to fix it. If anything I think the alliance makes it happen slower. With all that said, if I DID face the problem of using two different Ajax frameworks on the same page, I’d probably look to the OpenAjax Hub to fix it. Hey, no one ever got fired for hiring IBM.

So beware of “alliances” (unless you’re on CBS Survivor**).

* JQuery supports OpenAjax Hub through an extension.
** Be doubly wary of alliances.

Sorry, then why does it ask for a Zip Code on the main page and make it mandatory??? do you think America is the Earth? Do you think everyone on earth has a zip code?

That’s like saying baseball has a "World Series" when only US teams participate.

Or like saying the NBA champs are the "World Champions". Ehh, call me old-fashioned but you didn’t play any other countries!!!

WikiYou relies on a person’s vanity to willingly volunteer your personal information. Don’t fall for it.

Ask a question in a meeting on any of these and you’ll give off an air of being really tech-savvy. Unfortunately the question and answer will be pointless. People ask anyway:

1. BPEL compliance (Business Process Execution Language): "Is your engine BPEL compliant?" Doesn’t mean anything. You’ll never switch orchestration engines. Even if you do and your orchestrations are BPEL compliant you will still have re-work to do to get them up and running.
2. "Pure Java": Doesn’t mean anything. When was the last time you switched application server? From say BEA to WebSphere??? Never happens. I don’t understand it but for whatever reason folks feel more comfortable if their code is "portable" even if they never port it. 
3. "Lightweight container": Everything’s a lightweight container. I have yet to meet a heavyweight container but if I do I’ll shake it’s hand.
4. "Do you support WSRP?": Web Services for Remote Portlets: Useless feature that should never be used. Sort of like a toilet with a passenger-side airbag.
5. "Your business folks could edit this process": No they couldn’t or if they could it’s typically not a good idea to let them.

I’m sure there are others, what other useless but sought after features can you think of?

Judging by the responses at TheServerSide.net [LINK] it would seem the answer is unfortunately no.

If you look at the spec though it’s pretty blatantly obvious to me that the real answer is it was never alive!!!

WSRP stands for Web Service for Remote Portlets. It lets you share a portlet hosted in a portal with other portals based on configuration alone.

The host (WSRP producer) instantiates the portlet and then serializes it into XML, including HTML and wraps the whole thing in SOAP. It also does things like URL re-writing to avoid collisions with the consumer. It even does things like re-writing the javascript.

It’s a super lazy approach and the problems are numerous:

a) The size of the data packet over the wire: Includes Presentation and Data combined.
b) Have to layer security on top of it. Can flow security contexts over in some cases but generally you’ll want to do WS-Security over SOAP. Now you’re really bloated.
c) Context: The portlet think’s it’s running on it’s host portal, can’t interact with other portlets on the screen as it doesn’t know where it’s being hosted.
d) Things like Ajax or javascript-ish controls are going to be tough to debug.
e) Performance: All that stuff on the wire.
f) Additional processing for stuff like Request.Redirect to strip out HTTP headers.

The list goes on and on and yet this spec is on V2.0 now!!! I don’t understand it but there you have it. With things like JSON/REST/SOAP and the ease by which you can create a UI nowadays you’d think folks’d wise up, take the hit and build a native portlet to consume a data web service. You’re life will be so much easier in the long run and you’ll get better mileage from the data web service than you will from WSRP web services.
<shakingHead rollingeyes="true" />

A nice curiosity but I found it a bit repetitive for long viewing. Someone definitely put a lot of time into this but it seems destined to failure as I can’t imagine anyone ever leaving such a thing running on their machine for very long.

This is an example of over-thinking the problem.

Asirra is a "research" project at Microsoft that uses pictures of cats and dogs to tell if you’re human or script. Try it out here [LINK]. Since 2 pictures, one of a cat and one of a dog would give a bot 50/50 chance of getting it right, Asirra has the user click all pictures that are cats (for example) out of a line up of 12 animals. (I had this exact idea which I’d cited in my book (ISBN:0470097779) but with meat and eggs). It’s a little better but still complicated imho. Plus it takes up a tremendous amount of space on the page.

I use a simpler method, just answer the question "what’s my name", if you don’t know then you might be a robot. Now if it ever became a problem I could rotate the question, or re-word it in a way that’d make it difficult for an NLP (Natural Language Processing) enabled script robot to decipher. You’ve got to keep things as simple as possible but no simpler.