Tuesday, August 30, 2011

Google's use of the +1 button for search ranking

So firstly, a confession: I had always assumed that Google used +1 ratings in some small way for search engine rankings. Perhaps I'm misreading their blurb, but it seemed that they were pretty much advertised as such to web publishers. Clearly the influence would have to be small, as +1 ratings are easily fakable, but I assumed they were used in some way.

According to a recent Wired article, it seems that this isn't yet the case, but that Google are still in the process of considering using tihis nformation.

A couple of problems I see:
  • as Ryan Singel notes, it's easy enough for web site authors to "fraudulently" arrange +1 clicks on their own site, so some kind of filtering would presumably be required, and the degree of influence that +1 ratings had would need to be quite carefully balanced and monitored;
  • it may be that certain more "socially oriented" sites are more susceptible to the +1 or "Like" concept; just because a site is more focussed on social networking doesn't necessarily mean that its content is more "worthy" or relevant in response to a given search.

Wednesday, August 10, 2011

The problem of spotting scams

Ed Bott writes an interesting article on the subject of Why do people fall for trojans? As he explains, one of the problems is that the steps that one must go through to make even a legitimate purchase can often resemble the experience of a scam, including false alarms such as Windows warning us that our legitimately purchased item "might harm your computer".

This is also one reason why I think schemes such as the "verified by Visa" scheme for credit card purchases, in addition to being senselessly irritating, are actually a bad security measure because they imitate during a legitimate procedure precisely a process that an attacked might exploit or which might be the warning sign of an attack. Or in other words, in both this case and the scarey dialogs that can appear in Windows while you are downloading and installing a legitimate program, we are actually risking that what should be warning signs actually become ignored due to being "dulled by familiarity".

Sunday, August 7, 2011

The Google files

The current milestone in the Google-Oracle debacle has been reported this week to hing around two e-mails, one dating back to 2005 and the other a draft of an e-mail possibly constructed after Oracle's patent claim expressing a need to negotiate a licence for Java.

Whilst the first of these e-mails discusses strategies for what to do "If Sun doesn't want to work with [Google]", if will be interesting to see how much this weight carries in light of the subsequent 2007 blog posting in which Sun's CEO apparently praises and supports Google for their use of Java technology in Android.

The scond, apparently only a draft of an e-mail, but slightly dammingly indicating "We conclude that we need to negotiate a license for Java under the terms we need." poses other interesting questions. How admissible as evidence is a draft of an e-mail reported to never have actually been sent? And if it is established that this draft was composed after Oracle first raised its case (from the reports I've seen, the timing still does not appear clear), how damming is an e-mail saying "we need to negotiate a license" if it effectively in response to Oracle saying "You need a license".

I'm not a lawyer, but it will be interesting to see how this plays out.

I would still be interested to see a re-examination of the actual patents in question. As I've expressed before, my opinion of at least some of these is that they appear to essentially be fancy verbiage to describe procedures that are inherently obvious to an expert in the field, with little in the way of an actual invention.

Saturday, August 6, 2011

"Lost Programming Skills"

All too familiar with that "corporate IT solution" consisting of various inefficient black boxes haphazardly glued together using a plethora of acronyms?

This article entitled Lost Programming Skills looks at some of the once common knowledge which has not been passed on to generations of programmers. Interestingly, they highlight the inability to appreciate I/O issues (as much as, say, code optimisation).

Monday, August 1, 2011

Why Java 7's hotspot bug is a bad bug

I'm responding partly to Alex Blewitt's article in which he downplays the severity of the Hotspot bug exhibited in Java 7.

First of all, I think that in principle he may have a good point: previous Java releases have exhibited bugs which are arguably just as severe if not more so, there has been a temporary workaround, and they have been fixed and the world has carried on ticking. It's also true that any critical application upgrading to Java 7, as with any major upgrade of a key system component, would be mad not to have a regression plan should the proverbial shit hit the fan.

Where I disagree with downplaying this bug is that I believe the problem is largely one of process rather than the substance of the actual bug:

  • this is the first major release of Java since Oracle took over stewardship of the Java language: eyes were on them to see how they would handle it;
  • this is the first major release since the departure of various key ex-Sun employees;
  • the bug(s) in question were reported before the release and were exhibited by code present in the experimental stage in releases of Java 6 (or to paraphrase: "if the fix for that known serious-sounding bug wasn't tested properly, then what else wasn't tested properly?");
  • the precise circumstances under which the bug(s) exhibited themselves were not clearly published, let alone by Oracle;
  • without knowing the details, a vague birds-eye view of the problem (a "bug with JIT-compiling nested loops") sounds like a bug in a fundamental function of the JVM that you would ideally want to work reliably 100% of the time.

Alex Blewitt takes the view that: "since Java 7 has only just been released it would be unlikely to be used in production environments yet". I don't buy this view. If this is an alpha release, then call it an alpha release. But if your position is that you are making a "release", then that quite reasonably means "this is a version that has been through rigorous testing which I believe is suitable for use in production environments". Let's not flannel our way out of this: it was a cock-up.

If I were using Oracle Database for any critical applications, I would certainly now be looking for some reassurance that they take the testing and release procedure of their database products more seriously than they do Java...