Posts tagged with: "google"

I saw the article ’Google’s First Real Threat: Twitter’ pop up in my RSS readers today from a couple sources and didn’t click through and read; I had already learned the power of Twitter Search on multiple occasions (see my previous discussion here). But then something funny happened: I got an e-mail from O’Reilly saying that all three of my RailsConf proposals were accepted. Then I heard from a colleague here at Intridea that his talk was accepted.

This seemed, frankly, too good to be true. So I hit up Twitter Search for RailsConf, and sure enough, everyone seemed to be elated about getting their proposal(s) accepted. This confirmed my suspicion, and I contacted O’Reilly immediately. In fact, I contacted O’Reilly and they weren’t even aware of the problem yet. I may have been the one who alerted them to the issue in the first place. Confirmation came a few minutes later via the RailsConf Twitter account. While I’m a bit disheartened that I’m not necessarily speaking at RailsConf, it was an object lesson in just how powerful Twitter search has become.

Is Twitter a replacement for Google? No. But Twitter provides an instantaneous connection to what is happening to people right now, and in some (many) circumstances it can give you answers that Google never would, even after they re-index the web. This also to me serves as a lesson in how to truly compete with Google. Don’t try to “out-Google Google” like Cuil did. Instead find a way to provide a search that Google can’t touch, that can’t be created simply by crawling the web endlessly looking for new content.

Pay attention to where Twitter search goes in the coming months and years, because it’s no joke: real time search is a big deal.

Though I feel bad for jumping on the bandwagon, the Google App Engine is worth talking about because it represents what could be a major critical point in the development of web applications.

To this point the production of web applications has largely been the business of startups small and large. While the development of the applications involved can sometimes be a one-person operation, the infrastructure to run a production-ready scalable app has largely been beyond the reach of individuals and hobbyists. Google’s move, while still in its early stages, could be a watershed moment in app development.

De-Brandification

One thing that the App Engine might do is begin to separate web applications from the branding/marketing needs they currently have, at least in the initial stages. The app gallery access to a list of applications, all of which are easily accessible with your Google account, provides a brand-new experience for users. Rather than hearing about a new app that happens to do something that a user wants, instead they can now actively browse through a listing of applications, all rated and all easily accessible with a single sign-on. Do you care what company makes the widgets you stick on your Dashboard or your iGoogle page?

This isn’t necessarily bad news. Apps can still generate ad revenue and charge for services, but who makes the app becomes far less of a factor than how good it is at doing its thing.

Apps Get Smaller

With a central directory and a free base infrastructure, applications do not need to be all things to all people. They don’t even need to be most things to most people. The profit model for an application simply becomes a question of revenue recouping development time. While AWS provides a much less expensive server infrastructure than traditional mediums, the value of free cannot be underestimated, especially when it comes to the individual.

If a developer knows they can host an app that can scale to thousands of users with no cost, there is a stronger incentive than ever before for ‘the hobby project’, something that the developer thinks is cool but may or may not have real-world marketability. This is a dream come true in an increasingly agile industry: ‘throw it at the wall and see what sticks’ becomes not only viable but likely preferable when the barrier to entry is lowered by such a drastic degree.

Enter the Hobbyist

This low barrier to entry is going to foster a new generation of hobbyist apps. Many, perhaps most, will likely be worthless at least in some aspect. But a few will be brilliant gems, developed by a single person on a zero dollar budget. Hobbyists can create their projects on the side, release them in the wild, and see what gets a following, all at zero cost except the time spent developing the app.

This obviously isn’t applicable to all apps and situations, and venture-backed startups will still have just as much of a place, but the entry of hobbists into the web app mainstream could be a kickstart for competition and interoperability.

Nothing if Not Consistent

The final piece of the Google App Engine puzzle is that by providing a single platform – BigTable, Python, Google Account Access, and a standardized SDK, it will be much easier for App Engine projects to interact with each other semantically since they will all be built on essentially the same structure. As a Rubyist, I certainly look forward to more language support, but I think there is some power in the one-dimensional approach that, although it limits options, also provides a consistent target.

An analog to this is video game development. Up until the most recent generation, PC gaming was considered the platform for the truly ‘hardcore.’ But for developers, a consistent platform target that was deployed in millions and millions of homes won out against the configurability of the PC market. I think the same thing could be happening in the web app world: configurability is great, but if 90% of all apps can be hit by a single offering, it may be more worth it to have the consistency. This does not include language dependence, but if the App Engine SDK were available for all the big scripting languages, it would maintain that consistency while giving developers flexibility in implementation.

There are exciting times ahead, and the community will certainly be watching as more developments arise in the App Engine arena.

Example:

Here is an example of an OpenlySociable Micro app, which implements the ‘Friend List’ app from the OpenSocial documentation site:

require 'openly_sociable_micro'

OpenSocial.make_app :ListFriends

module ListFriends::Controllers
  class Index < R '/'
    def get
      @title = "Friend List"
      render :index
    end
  end
end

module ListFriends::Views
  def index
    javascript :friends
    div(:id => "message")
  end
end

OpenSocial.start_mongrel :ListFriends, :port => 3301, :root => "/"

Here the ‘javascript :friends’ refers to a friends.js widget-specific javascript file that lives in the same directory. OpenlySociable Micro uses the Builder XML library to wrap a view action’s results into an XML format served by Mongrel. This format is the Google Gadget format, which OpenSocial containers like Orkut and Ning recognize and display.

Getting Started:

• Install the gem as described below
• Read through the Camping mini-app
• Look through the examples found here
• Write your first widget!

Installation:

OpenlySociable Micro can be found here:
http://svn.intridea.com/svn/public/openly_sociable/micro/

You can also install the gem by downloading it and running:

gem install openly_sociable_micro-0.0.1.gem

Plans to integrate OpenlySociable Micro into Rubyforge are underway. For now there is a trac setup here here .What is it?:

‘OpenlySociable Micro’ is a clean, simple and concise way of writing OpenSocial widgets. It uses the Camping microframework and Mongrel to allow developers to write self-contained widgets for OpenSocial-enabled websites with none of the overhead of a full-blown Rails application.

Generate the Right Buzz

OpenSocial was released the 1st of November, and there was much rejoicing. Developers rushed to the official site to see what exactly Google was up to. Facebook developers everywhere crossed their fingers as the page loaded up, hoping to find a means of escape from the FBMLized, constantly-changing hell they were experiencing. Surely, Google will have the answer! This is Google we’re talking about — they wrote Gmail, remember the buzz for that launch? They’ll surely deliver! Right?

Release the right thing at the right time (or ‘First Impressions Matter’)

November 2nd was the first day of RubyConf 2007, and while I saw many a Rubyist’s Macbook Pro loading up the API site during the morning sessions – I would say that it’s within reason to declare that there were no libraries or even hacky interface wrappers written that night. This was partly because Google has YET to release the actual meat of the API — the RESTful interfaces to their data. What the developers got on Thursday was a tiny set of extensions to Google’s pre-existing Google Gadget API, which is primarily written in Javascript. Google, if you’re reading this, know that you would have had a beautiful Rails plugin for OpenSocial a day after launch if you had only came through for the early adopters and opened up the REST interface. Release the whole API (or something respectable and usable) if you want to make a solid first impression.

Don’t frustrate your developers

The developers who actively seek out your API and are excited about it at the beginning are the ones who know a good thing when they see it. Don’t alienate them. The Gadget Javascript extensions are great for tiny widgets, but developing with those brings forth their own set of problems. Orkut has an extremely annoying caching bug that pretty much forces developers to add/test/remove/add their app every time they make a change — not a good start, we are no longer in the dark ages. This brings me to my next point – why just Orkut?! Brazil and India are Orkut’s main consumers, or at the very least, the only people who use it pretty much exclusively (even though I hear rumors of hi5 making major strides in South Asia). The last I heard, Friendster, hi5, LinkedIn and Ning were also launch partners, why are my sandboxed apps not running on their sites as well at this moment? Good developers love an all-encompassing solution rather than a targeted one. If one of these developers writes an app for Orkut now, and finds later when LinkedIn or Friendster finally opens up their sites as containers, that their code does not run as well as promised, Google loses trust, credibility and karma points.

In theory, OpenSocial is fantastic — I will not deny that. In time, I can see that it will be a sweet little platform for writing network-independent social apps. The pressure is on, however. The VCs are probably loving this, considering what Facebook apps are worth now, and Google needs to deliver a flawless platform that is ready to whip out of the gate and crush everything in its path. Intridea will be tracking OpenSocial quite closely, stay tuned for more in-depth posts quite soon.Michael Arrington announced OpenSocial on TechCrunch two days before its official release. Prior to that, there were whispers everywhere about Google’s new social platform, but not many seemed to know what exactly was about to go down. Needless to say, this is good buzz. Two days before ‘launch’ the overwhelming mood among web developers, especially us who dwell in the realms of social networking, was one of intense (even feverish at some points) anticipation. What unfolded over the next few days, combined with what we observed of Facebook’s API venture, provides us a set of best practices that we can apply to an API release.