The Gazette ... Issue: 208 (12-22-2003)

Comments (1)

1. Google has most certainly changed things from a pure algorithmic sense. Reports from various searchers, SEOs, and other people that "live" in Google are reporting that search results are not as accurate, relevant, or dependable as they once were and no one seems to be able to put their finger on why. With previous updates, SEOs and Webmasters often took note of drops in relevancy, but that notice was mostly based on their own sites dropping out of the listings. With this update, many of us have begun to have friends and family ask why they are having trouble finding things at Google. Google does acknowledge that there are changes being made to their algorithms, "For the purposes of making the results better in all cases. As with any core logic change, the results will most certainly not be the exact same with each iteration, but each iteration reflects another step towards the goal of achieving greater relevance of the pure search results."
   
   
2. Google is taking a very hands-off approach in addressing these concerns. Attendees of SES last week in Chicago have noted that Google is not talking at all about organic search, the Florida update, or anything not related to Adwords or Adsense. Essentially, they're making a marked effort to shift the focus of discussion to their commercial entities. Are they simply staying under the radar ... promote their revenue producing systems ... or is more likely that they are unable to address the issue without souring the wine?
   
   
3. Google is preparing for an IPO. There's bigtime money at stake here. The success of the IPO, and the long term success of Google.com is directly tied to the stability and profitability of AdWords, AdSense, contextual ads, and other ventures such as "Froogle". As important as the financial success of their commercial ventures, the continued success of their organic search is vital in retaining searcher loyalty, industry-wide respect, and as the "engine" that drives their commercial endeavors.
   
   
4. The IPO can only happen if Google is a "clean" company. This means they must have nothing derogatory on the financial side, and that they must be a self-contained (proprietary) system, with no outside control over structure, code, systems, personnel, etc. In other words, if they owed a billion dollars to someone, that would have to be cleared first. Similarly, if a major portion of their infrastructure was legally owned by a 3rd party, they would have to assume ownership and control over those systems. And therein just might lie the rub.
   
   
5. http://www.jimworld.com/go/to.cgi?l=googlepatent That link will take you to the US Patent Website, specifically to patent number 6,285,999. This is the patent on "Page Rank", a major part of the algorithm that made Google the most dominant search engine in the world. You'll notice a couple of things right off the bat. First, the Patent is granted to Stanford University (which as we all know is where Google has its initial roots). Secondly, as our own Chris Logan pointed out, "This invention was supported in part by the National Science Foundation grant number IRI-9411306-4. The Government has certain rights in the invention." This document nullifies one of the requirements of the IPO (#3 above), as there are 2 outside claims to the Intellectual Property that makes Google what it is (was), and therefore could potentially eliminate their chances of having the IPO at all. Google does acknowledge that Stanford holds the patent, but they made it clear that "although Stanford is the named owner, Google as a company absolutely owns all of the rights contained within." This makes the case that they are under a legal obligation to circumvent the patent a moot point, however the financial obligations may still be an issue. I have spoken with a respected Seattle Patent, Trademark and Intellectual Property attorney about this, and they were able to shed some light on the subject. Legally speaking, both Stanford and the US Government have ownership on the patent. Stanford is the primary, but because the code was developed using a US Grant, the Government retains the right to throw a legal hammer onto the mix if they so choose, as granted by the Bah-Dole Act of 1908: http://www.crf.cornell.edu/bayh-dole.html. The Government has never used the hammer, which exists mainly as a threat, but it is there. Legally speaking, Google can exist outside of the Stanford patent under one of 2 scenarios:
   1. If the license that exists between Google and Stanford explicitly permits it.
      According to Google, they "Own the rights" to use the patented technology. Based on that statement there must be a license agreement between the two parties, which obviously is not going to be part of the public record. Very often, these types of licenses, especially when a university is involved contain some "poison pills" which make it financially or commercially impossible to use the granted work in commerce. Obviously, we're not privy to their negotiations or the specifics of the contract, but one would assume that there's something significant in there that is making Google "blink".
      
      
   2. If Google develops around the patent.
      This is the assumption that this article is making. Big and obvious algorithmic changes, that extend beyond minor tweaks, are certainly being made. One has to assume that either Google and their users were totally unhappy with the previous results and relevance or that they are attempting to exist beyond the grasp and logic of "Page Rank". Our patent attorney agrees ... this is a perfectly ethical and legal practice, and one that is employed countless times. "If Google can achieve the same quality/relevance of results by an alternate means that does not infringe on the specifics of the existing patent, it is perfectly within their legal rights to do so".
      
      
   Note that Google can also exist (and IPO) within the confines of the patent, depending on the specific financial and legal obligations that are contained within their license agreement with Stanford. Is there a poison pill in there that's at the root of this discussion?
   
   

Comments (62)

WE KNOW WHAT YOU DID LAST CHRISTMAS

The early indicators are coming in for this year's holiday shopping season.

Many e-commerce sites are reporting a rise in the percentage of abandoned shopping carts. Think of it as shopping carts being left in the aisles of your local toy store, full of toys but left to sit while the shoppers gets in a car and drives away. It was great having them in your store but a real bummer to see your checkout employees fixing their nails and looking bored.

So what might be driving this trend to fill up e-carts and not finish the order?

Maybe the store owners did a great job last year of getting all of their orders shipped in time to be sitting under the tree on Christmas morning. Maybe they did better than anyone in their industry.

But they are the only ones to know that.

If you did great last year in meeting your customer's needs, tell someone. Heck, tell everyone. Paste it in big gaudy letters across the top of every page of your site. You either blow your own horn or get painted with the same brush the media used to paint Toys-R-Us last year.

"Gee, Susie. Santa was really sorry but his Elves didn't finish your present but he left you this really pretty piece of paper. He'll send your gift in a few weeks."

No parent wants to have little Susie open a gift certificate from the e-toy store just because the e-store doesn't know yet how to run a business. They want Susie to open a real toy. The parents either got burned last year or they watched any of the thousands of hours of television media firestorm and want to be comfortable knowing that the gifts will be there for Santa to place under the tree. Santa seldom delivers gift certificates. At least mine never did.

Don't be shy about blowing your horn. SCREAM to your visitors that you are the absolute guaranteed place to get gifts on time.

Delivery will be more important this year than having the lowest price.

That's a nice trend!

Comments (7)

1. Thou Shalt turn "REGISTER GLOBALS" off.
   It's flat-out security risk. Turn it off now and learn how to read and react to user input without simply turning the "$_GET" or "$_POST" arrays back into individual global variables.
   
   
2. Thou Shalt check all user input for validity and security.
   Use either escapeshellarg or a simple regex such as: "preg_replace ("/[^A-Za-z0-9]/","",$variablename);" before sending user input to a command line/shell application or into your database. It's doubly important to check user input when basing file operations on it. As an example, if you're allowing something like "language=french" in the Query String, and are then looking for a file called "/data/languages/$language", be careful that someone doesn't change the Query String to "../../../../../../etc/passwd" or you could be in big-time trouble. Make use of is_numeric or is_string, and addslashes before sending user input into your database.
   
   
3. Thou Shalt write thy code using accepted coding standards.
   You're not the only one that will ever have to read, edit, debug, or modify your source code. Follow the standards, and you'll make everyone's life a lot easier.
   
   
4. Thou Shalt use object oriented programming.
   OOP is the way to be. It's more organized, more portable, and by it's nature, more modular. Get out of the dark ages and get object oriented.
   
   
5. Thou Shalt not require pear or other external server modules in commercial applications.
   Not everyone has a dedicated server, and therefore will not likely be able to install the modules you require. Don't shut out part of your potential customer base by being too lazy to write things from scratch.
   
   
6. Thou Shalt use templates and not inline PHP.
   Leave the HTML out of your PHP, and the PHP out of your HTML. Put all of the intelligence and smarts into modules and libraries, and let your end user/designer use full HTML templates to achieve their look and feel. Do not embed PHP into HTML. It's crude, hideous, hard to debug, and quite frankly, the mark of a true amateur. You might take a look at the iWeb ds/X API, which will accommodate this task, as well as provide a stable platform from which to begin your application. When you must include HTML within your application, use a "Here Doc" or an extended string to define it. There's nothing worse than having to wade through line after line of escaped quotes or 15 echo statements in a row.
   
   
7. Thou Shalt use database abstraction.
   PHP has an army of database specific commands. If you rely on, for example, mySQL_xxxx()" to handle your database operations, your application will not run without extensive modification for your users that rely on postgres, oracle, or mssql. Use a database abstraction layer, such as the iWeb ds/X API or PHP's built in DBx Functions.
   
   
8. Thou Shalt hide all non .php files.
   Any data files that need to be created or written to should be stored safely behind the document root of the Web site. Similarly, if you're using libraries and are following the recommend naming convention by giving them an .inc extension, make sure that they, too, are tucked in behind the Document Root. This ensures that someone with a curious mind cannot simply open up a data file or a library file in their browser (.inc files will render as plain text in a browser). If you are unable to do this due to access restrictions or "open_basedir" restrictions, then rename your include files with a .php extension so that they're not viewable, and put your data behind a .htaccess file to hide them from prying eyes. Trust me, people will seek out and find files that you think are hidden away safely. Do your best to stifle them.
   
   
9. Thou Shalt learn Perl if you do not know it already.
   PHP's roots are based in Perl. In fact, PHP makes use of Perl regular expressions in a number of its built in functions. Regular Expressions are extremely powerful, and if used properly, many times faster than PHP native equivalents. Learning both languages will make you a better programmer, as you can better optimize your PHP code to take advantage of it's Perlish features.
   
   
10. Thou Shalt be nice to the perl guys, and equally mean to the .NET crowd.
    Perl certainly has it's place. In my opinion, Perl is still the language of choice for hard core programming such as big number crunching reports, searching, things requiring big-time horsepower, or anything server level or admin oriented. PHP excels at quick-hitting apps, high traffic apps, and because it's a Web-specific language, should be the language of choice for most online database driven applications. .NET is a pig, as is everything else out of Redmond. Keep letting them have it ;)
    
    

Comments (1)