New Virtual GSA Release

There is a new VGSA release from Google, not sure if it is widely available yet though. The release is aimed at fixing some of the issues with the first release. Two key issues that appear to have been fixed from the brief testing I have done so far are;

• Timezones: I can now set my VGSA to be GMT instead of California time :-)
• DHCP: I can now restart my VGSA with a different I.P. allocated via DHCP and the VGSA will fire up without issue

I need to check if the serving is still impacted if the I.P. address changes, but it does look like this next VGSA release fixes the major issues from a sales tool perspective.

Google Apps Gotcha

If you create your Apps domain with anything other than English-US, you lose functionality as per the post below;

YOU CANNOT CHANGE THE LOCALE ONCE YOU HAVE SET IT!

This means that if you need the full functionality and you have already set up your domain with some other locale you are stuffed!

I need to check with Google if this is something that their support team can resolve under the covers!

My advice - ALWAYS CREATE APPS DOMAINS AS U.S. REGARDLESS OF YOUR LOCATION OR NATIVE LANGUAGE!

Google Apps Training - Day III

If you live outside the USA don't expect Apps. to work properly!

If you set the locale for apps. to anything other than English-US (an oxymoron if ever there was one) then a bunch of functionality disappears;

• you loose some admin functionality (like groups)
• you loose mobile functionality (like being able to add users to Calendar events)

The basic message is, set your locale on Apps. and all of your access devices to English-US or accept limited functionality and bizarre behavior.

Hopefully, this is something that Google are working on fixing!

The Art of the (im)Possible!

I have been looking at what is or could be possible using the 'Google Driven Architecture'. Some initial ideas are;

• Ability to connect users with specialist product advisers as part of their search experience.
• Ability to push offers to customers on their mobile devices based on their proximity to stores.
• Ability to push alerts out to customers as specific information / products / offers get published on sites.
• Ability to push alerts to corp. users when competitors publish specific information or when specific external / internal events occur.
• Ability to visualise unstructured content using Geo and Data API's as part of the search experience.
• Mashup formal Geo and Crowd Sourced Geo data.
• Drive workflow using unstructured data events.
• Sync your todo list with Geo and Alerts; prompts you to act on your todo list based on proximity of relevant services etc.
• etc. ...

Google Apps Training - Day 2

The best thing I learnt on day 2 was not really related to Apps. If you want to use an Android users Google Account for apps on the handset you can't simply get their current session or OAuth them. You can ask them for their creds. and use these with the AuthSub to sign them on to Web Services and can then get a token.

It looks like Google Single-Signon for Android is still some way off.

Google Apps Training - Day 1

Learnt a couple of interesting things that I dodn't know about Google Apps;

• most of the Google products use the GData API; learn this API and you should be able to interact with most of the Google product set from your own apps.
• you can SSO with Apps. very easily.
• In the premium version of Apps. you get App Engine, so you can easily integrate bespoke functionality; Java for App Engine should be due out soon :-).
• To roll-out Apps. for large numbers of users is not straight-forwards; there is a certain amount of bespoke development required to provision users and integrate with existing repositories + migrate data.
• There are a bunch of helpful tools available for integrating with LDAP for user provisioning; but this is not as easy as you think.

Virtual GSA & VMPlayer

It seems the IP issue I was having with the VGSA may be down to the fact that I am running it in VMPlayer rather than Workstation. I need to look at this further but it may mean that you can use the VGSA as a sales tool after all.

Return of the Thin Client (ish)

Does anyone else think that ASUS EeePC (NetBooks) + Google Apps. is not dis-similar to Sun Microsystems attempts to market Java Thin Clients to the desktop about 8 or so years ago?

Sun were ahead of the infrastructure capabilities back then, their timing was way off. It is surprising that they have not been more active in this space now that the Infrastructure is there.

Google for the Enterprise

So I am involved in bringing Google to the Enterprise ....

There are a bunch of products that work well together and fit well with the needs of enterprise customers. I am currently struggling with one major issue that I need to resolve, at least in my own head, to make this successful. It is the same issue that may enterprise architects have struggled with in the past and I guess continue to struggle with and it is one that leads to a never ending, and often heated, debate;

"What technology stack do I use?"

Let me explain. There are a bunch of technologies that are being used to deliver and enhance the Google product set. At the core is Apache and Python, then there is Java and PHP. Plus, there are a bunch of enterprise customers that want to deploy into a Microsoft environment. I want to package solutions up around the core Google Enterprise Technologies into reusable products. Given that many enterprises have standardised their infrastructure on particular platforms and technologies what do I do.

Do I adopt the array of technologies being used currently to deliver Google solutions or do I look at re-engineering existing solutions around a common platform? As an example, to deploy the GSA with features like Search As You Type, Parametric Search, Feeds and Connectors I would have to support Java, Python, PHP, Apache HTTPD with CGI and Tomcat. Do I re-engineer the PHP and Python functionality so that everything is Java and Tomcat (or Servlet Engine of choice) or go with the broader set of technologies? 

The problem with standardising on a single technology is that I cannot then leverage the available functionality as it evolves; for example, each new release of SAYT is released as PHP and I have to re-engineer to Java! In the SMB & Consumer space having a bunch of different technologies to support a solution is not an issue, but in the Enterprise it is.

"If one standard is good, many must be better" does not ring true for the Enterprise.

I think the answer is that I have to support Java and .NET (providing duplicate functionality for each platform) and re-engineer anything that is released using a-n-other technology. This is not great - I can see this leading to problems. The ideal would be that Enterprise customers become less choosey about the technologies they deploy which, would require a massive mind-shift for many CTO's / CIO's.

Also I wonder, how much longer it will be before Java and .NET go the same way as C, C++, CORBA, COBOL etc. How long before Enterprises migrate to Ruby or PHP or Python or the next thing as their standard platform?

I want to write my solutions using all of these technologies, but I don't think that my customers will accept that! I want to standardise using Python (or PHP or Ruby), but I don't think my customers will accept that either! I want the Google developer community to get behind a standard platform so that I don't have this problem - but that would take all the fun out of it!

Eclipse for Android II

It appears that the DDMS view in Eclipse is broken. When you launch your application in the Emulator or on your handset via USB you then need to launch the DDMS tool from the Android SDK. You will then be able to see the information produced by Log.<x>.

Android Undocumented Features

I have just uncovered another undocumented feature in Android. This one suggests that no-one bothered testing the platform before they put it live.

On the G1 you can specify that LAT / LON data is captured when you take a picture. That data should be stored in the Content Provider with the other image data. This does not happen (at least not on my G1). So I have to manually query the LocationManager when I take a picture and attempt to get the current location of this device; which as it turns out is not possible! You can get last known or you can wait for updates by registering with specific providers, but you cannot request location data at a specific point in time.

This functionality does not appear to work on the Emulator either so at least it is consistent! The more that I develop against the Android API's the more disappointed I am becoming with them; the design leaves a great deal to be desired. This is a real shame because this could be such a powerful platform it is criminal that the execution of the concept to date is so poor.

Roll on Android 2.x