June 27th, 2008

Good Bye Appendix, Hello Google App Engine

While an appendicitis is a painful, uncomfortable and ultimately debilitating condition - one which I have suffered with for over a year, its remedy (Laproscopic surgery, way too much money to an evil hospital, a shitton of painkillers and a week of bedrest) is fairly tame as far as surgical procedures go.

PHPitis is another condition I have been suffering from. It’s not early as painful and has provided me with a decent income and professional growth. It is also not a pussy inflamed organ with no apparent value pressing up against all the nicely formed and functioning organs around it. However, the feeling that there is something not right “down there” remains.

I’ve always known that python is the best language out there. I don’t mean to start yet another stupid language fight, because every language is fine and dandy. But honestly, every programmer I respect has told me the same thing, they wish they could just write python. The only knocks against python are:

  • Lack of hosting options
  • Lack of Jobs / Skilled personnel

The first one, is obviously stupid, because it is as easy to run as PHP, but is totally chicken and egg. The second is pretty much the same. You have to be a better programmer to write python, and so there are less people who can, so there are less CTOs wanting to risk a language with less people available.

Anyway, for what it’s worth, I love python, and I’m not that good at it yet, because I never get jobs in it, and it’s hard to get clients signed up for something that isn’t hosted anywhere…. Until now.

A day before I went to the hospital for an examination into yet another bout of my awful stomach pains which turned into the aforementioned surgery, I got my App Engine key in the mail.

I am affraid of the big G as much as anyone, and this offering is too new to judge. I won’t bore everyone with the questions everyone is asking about if your code can be moved or not, what is the guarantee they will keep it around, etc. I just want to say that the data api and the security of knowing that such terse syntax with so much power will scale till the end of the googleverse is exciting.

I highly recommend everyone give it a whirl, and discover / rediscover beautiful code. I was thinking of “killer apps” to build on it. My first inclination is that the “killer app” for the gapjinn (as I have now started calling it) is something with the following characteristics:

Uses Google Apps data apis

As much as possible, the application should store it’s data in google sites, google docs, google calendar, etc. This is because google will always have a commitment to making these two platforms work together AND you will not be made irrelevant because you can’t integrate.

Uses Google Apps provisioning APIs

Because SaaS is in, and you will want to make setup super easy.

Uses Google for authentication

Because you will not survive in the enterprise if you can’t take advantage of single sign-on services. As long as you are using all the google apps stuff, you should authenticate the same way.

Is niche enough that it does something better / easier / more focused than native google apps
OR

Provides an integration between different google apps and a 3rd party service

On the first count, it’s about creating a wrapper, basically a new interface layer to an existing google apps platform. Sometimes simple is too simple. For instance, using a series of tags and and a small amount of data store in the Google BigTable, I bet you create a really quick and dirty CRM using google contacts + gmail + google sites + google calendar.

On the second, I think the potential to provide bridge functionality between more mature best of breed apps like basecamp, unfuddled, salesforce, will make quick enterprise dashboards possible. Something like a dashboard / middleware layer between this stuff.

Let’s see…

May 11th, 2008

6 premises for killer apps on the Google App Engine or Good bye Appendix, Hello Google Apps

An appendicitis is a painful, uncomfortable and ultimately debilitating condition one which I have suffered with for over a year. However, its remedy (Laproscopic surgery) is fairly tame as far as surgical procedures go - way too much money to an evil hospital, a shitton of painkillers and a week of bedrest

PHPitis is another condition I have been suffering from. It’s not early as painful and has provided me with a decent income and professional growth. It is also not a pussy inflamed organ with no apparent value pressing up against all the nicely formed and functioning organs around it. However, the feeling that there is something not right “down there” remains.
Read the rest of this entry »

April 8th, 2008

Google Search Appliance / Google Mini Integration for Drupal

Google’s enterprise search technology is becoming an increasingly popular choice for IT managers to manage their intranets and pool data from multiple sources.

It provides:

  • Excellent keyword searching (obviously) based on pagerank as well as customizable weighting factors
  • Recommended links
  • Source and Date Biasing
  • Good support for different char sets
  • Incredible speed and performance
  • Support for multiple collections and frontends
  • An easy REST interface for API integration

Leveraging Google’s technology on your CMS (Drupal) gives us the following benefits:

  • Potential for more relevant results
  • Integration with 3rd party databases and sites
  • Advanced search features like synonyms, stemming and language detection

How the module works

See the Google Appliance for Drupal module page for more details on implementation.

First thing you need to do is to setup the module so it knows where to connect to:

Google Appliance Settings

At the minimum, you need:

  • Search name (this will appear on a new tab on the search screen).
  • Host Name ( the URL or IP where your GSA or Mini is located )
  • Collection (which collection you wish to search ).
  • Client ( This doesn’t matter much, it just has to be valid. This is equivilent to the “frontend” in the GSA ).

Okay, done? If you want to, enable caching (which will cache results so you don’t need to re-query for the same search within the timeout period) and set the debug level.

Now, you’ll need to tell the mini where to crawl. For this, just go to your GSA administration screen, and punch in the url of your site. For node pages, the module will add meta-tags for the following:

  • Taxonomy (Advanced search filter coming soon!)
  • Date Modified and Created (Date sorting coming soon!)
  • Author
  • Status (pub/unpub)
  • Language (if using i18n)

After installing the module, you will see a new tab on the search screen:
Google Tab

Fire off a search and see your results (drupalified).

Google Results

In addition, you can enable the recommended links block, and if you have configured key matches in drupal, they will show up in this block.

This module is still in Beta, so expect some issues. Here are a few I know of:

  • No meta tags on non-node pages, means they will be found, but won’t have the type / author, etc fields in the results
  • Does not use url() on incoming links, which means if the mini finds node/123 pages, they won’t get aliases

There are probably lots more, but hopefully, this will get people who are interested in this going and we can work on making it better.

I am available for GSA and mini consulting and custom integrations, just contact me

How To find me

Telephone: +1 510.277.0891 | Email: jacobsingh at gmail daht calm

Solution Graphics