Microformat: hJob

Given recent [apparently failed] move by Michael Arrington, Om Malik, 37signals, and paidContent to consolidate syndicated job listing prompted me to initiate hJob discussion in the microformats group. Come join the group mailing list if you are interested. It's just getting started. If there is enough interest and momentum, I'll push for an early informal F2F to make sure all the ducks are aligned.

What I want to see happen is right jobs listings syndicated out closer to the consumption side, not just sitting on the production side like it is now.

Bubble Farting over Kiko Auction

Om Malik and Stowe Boyd reports that Kiko eBay auction closed at $258,100. Actually, Om wrote the auction just closed and brought in $258,100. The auction was closed but did the Kiko guys receive the money? As far as I know, they haven't and Kiko auction bid history showing a flood of bogus bids from two bidders (ogijun and wswire) doesn't inspire much confidence in the legitimacy of the winning bidder.

So, everyone, try to refrain from bubble farting until the fat lady coughs up some greenbacks.

Note: iBATIS Types and TypeHandlers

Just a note to myself to keep some often used technical details where I can find them. Please ignore.

Predefined type aliases (i.e. used in parameterClass):

  • string
  • byte
  • long
  • int
  • integer
  • double
  • float
  • boolean
  • date – java.util.Date
  • decimal – java.math.BigDecimal
  • object – java.lang.Object
  • map – java.util.Map
  • hashmap – java.util.HashMap
  • list – java.util.List
  • arraylist – java.util.ArrayList
  • collection – java.util.Collection
  • iterator – java.util.Iterator
  • cursor – java.sql.ResultSet

Predefined Type Handler Names:

  • CLOB, LONGVARCHAR
  • BLOB, LONGVARBINARY
  • OBJECT
  • DATE, TIME

iBATIS really needs more documentation and in easier to access format. It sucks to have to fire up Acrobat just to find some bits of details.

Web 2.0 Act 2: Integration War

Recent uproar over Kiko's demise and conversations that followed made me laugh, hard. Is Google the new Microsoft? Nasty question. Google has to grow continuously and that growth has to come from somewhere. A better question is: will Google compete unfairly? If one considers integration leverage unfair, my answer is yes.

It won't be so bad for a while though because all the big boys (Google, Yahoo, Microsoft, and AOL) will be competing with each other to offer the best integrated web services which means acquisitions and partnerships for small companies. But pretty soon, the picture will turn darker, making it near impossible for small companies to survive without joining one of the big boy's integrated service network and, to succeed, companies will have to spend millions of dollars to get a prominent link on the big boy's main page.

A network of Web 2.0 companies can't compete with those of the big boys because there is no hub to rally around. If one somehow managed to organize and integrate all the small companies represented at the TechCrunch party, the result would confuse the users and constrain the companies. APIs? I am sure the big boys will use APIs to rally third parties to their side in the war, but the silkroad will eventually be turned into puppet strings.

It's useless to ask whether Google is the new Microsoft. Ask instead how can small companies survive the chaos to come.

JBoss Rules Rules

Wow. Drools has changed quite a bit since I last used it. Beside the name change (bought by JBoss) and new features, it now sports a nice Eclipse-based workbench for editing rules. Rule syntax has changed from awkward XML-based one to an easier to read template-based expression language. Very nice.

I've used Drools to drive PassMark Security's realtime forensic engine (now part of RSA Adaptive Authentication product). Drools was used not only for policy-based risk analysis but also as a blackboard of sort to which analysis modules (i.e. bayesian) and distributed forensic evidence sources (i.e. account management systems, wire transfer services) can be plugged into.

Essentially, bundles of low-level facts (i.e. IP address) are thrown into it everytime the customer does something. As low-level facts are added, high-level rules fire to add higher-level facts (derivatives) and modules fire to pull related facts in from outside like accounting department that may impact risk level evaluation or from data center monitors to provide 'environmental' facts. At any given point, bayesian engines may kick in to contribute what they think is going on over time or scope of activities.

Fun stuff although there are deployment issues which is why there was not much pushing going on in the architecture. You can easily (cost and tech wise) to pull information out of most enterprise systems but pushing new information into them gets expensive very quickly. My big picture was to turn what I had into a central hub for integration and extension of enterprise systems. Oh, well. I think that picture was too big/out-of-scope for RSA. With EMC (which bought RSA), it might be another story.

Anyhow, I am going to play with the latest verson because these kind of technologies can be very useful if used appropriately.

Bubble 2.0

I don't know. TechCrunch party feels to me like an echo chamber, whole lot of people with dreams and hopes seeking mutual assurances from others like them. While I am all for dreams and hopes, this just doesn't feel right. Maybe I am overly concerned. We'll see.

Mail-in Authentication: Password-less Authentication, Kinda

Given that practically every non-financial protected website I frequent offers password recovery or reset via email (forget your password?), I don't think passwords are even necessary for these sites. A time-limited security token issued through weekly or monthly email containing a URL with one-time password effectively removes the need for passwords.

I am calling it mail-in authentication for lack of a better name. The intention is to replace those 'signin' and 'login' buttons with 'mail-in' buttons and remove the password field.

This is how mail-in authentication would work from user experience point of view:

  1. User registers at the site by entering an email address.
  2. User opens the email and clicks on the authentication link.
  3. Site issues a time-limited token cookie containing user and device identity hints. User is signed in at this point.
  4. Next time User visits the Site, user signs-in automatically unless the token is bad or lost.
  5. When the token is not accepted for whatever reason (expired, failed validation, flagged as being used in a replay attack elsewhere, deleted, or roaming), User is returned to step 1.

Note that there is one password still needed, the one used to access email. That's where Kinda comes from. In this scheme, email password becomes the universal password of sort.

While I don't recommend this authentication scheme for web applications with medium to high security needs, I think it's acceptable for low level security needs. To meet roaming requirements, temporary session token can be issued automatically when access from an unknown device is detected.

Update:

Paul Madsen points out that latency, spam (more specifically chance of getting past spam filter), privacy concerns (giving out email) could make mail-in authentication unusable. Those are valid points but I've got a trick up my sleeve that'll cover those. I am just not ready to share it yet cuz I want to validate the UX flow with a prototype.

ActiveGrid on Eclipse

ActiveGrid is joining the Eclipse gang. Peter probably doesn't remember because he was too busy making the pitch but I advised him to consider building on Eclipse nearly two years ago. Maybe billing him for the advice might have made him take it more seriously. It was a serious mistake to not leverage all the momentum building up behind Eclipse.

Well, it's better late than never.