Showing posts with label google. Show all posts
Showing posts with label google. Show all posts

07 June 2008

Tell Me How You Really Feel About The New Google Favicon

Isaac Schlueter of Foo Hack has devised a strategy for reinstating the original Google favicon using a local apache proxy server. Personally I think visual identity has always been a weak spot for Google and the new icon really doesn't bother me much anyway (I tend to look at tab titles mostly and Safari doesn't even show favicons on tabs). Still, I have to admire him for doing something proactive and not just whining about it.

27 May 2008

Google Launches Its Own JavaScript Library CDN

Google just launched it's AJAX Libraries API. This is great news for the smaller, independent libraries but with Dojo already being hosted by AOL this move would seem to actually hurt their ability to optimize client caching by splintering deployment. I imagine the Dojo team is supporting this so maybe they know AOL is a horrible company with deplorable customer relations and an even worse environmental track record something I don't.

10 April 2008

Google App Engine And The Value Of What It Isn't

Since the announcement monday of Googles App Engine service I've heard little but complaints (apart from a few informed assesments) from the internet at large. Now this doesn't surprise me and I'm sure on some level the App Engine teams is grateful for the attention, negative or otherwise. However, I think this reaction sheds some light on how many web developers have become so entrenched in their own development "comfort zone" that they can't see the value in exploring beyond the boundaries of their own languages and frameworks.

Google Hasn't Taken Anything From You

From some of the reactions I've read this week you'd think that by choosing Python as the initial language for App Engine Google had somehow rendered all other development environments obsolete (and ran over everyone's dog in the process). There also seems to be a number of developers lamenting how hard it will be to "port" their existing applications to this new environment as if that had been mandated by some higher power. Why can't we just get along look at this from the perspective that whatever options you had for web application development on Sunday, you now have one more. Whether you choose to use it or not.

You Got Your Framework In My Framework

Another issue that's rubbing people the wrong way is the simple fact that either their framework of choice isn't supported (Pylons, Turbogears, CherryPy) or isn't fully supported (Django). I use, and respect, these frameworks but I personally think it was a mistake to "support" Django in App Engine. Whatever they gained by playing to one of the largest Python web developer communities, I think they lost more by giving people the impression that App Engine is just another mod_python to bootstrap your framework to. App Engine IS an application framework, maybe not a full stack, but enough that there are as many parts of Django that are either redundant or incompatible as there are parts that are functional.

You Can Choose Your Own Colors Even When You Have To Color Within The Lines

I've spent a decent part of this week evaluating the App Engine SDK and having a blast building my own framework to fill in the holes in Googles service. As so much functionality is available from the SDK, it's been easy to assemble the few pieces I need and wrap them up in a package that I think will be flexible enough to handle pretty much any project I can throw at it. Based loosely on the Pylons framework, A simple WSGI "front controller", Routes, WSGI based app controllers and a few convenience utilities was all it took to get a fairly robust system up and running. As an added bonus, the entire framework (apart from external libraries) is spread over only 3 files.

We're All Still Working Out The "Kinks"

My little framework's not perfect yet, and probably never will be, but neither is App Engine. I still need a good template engine, and a web form generation library for the datastore models would be nice. But even without these "niceties" it's a very productive environment considering it probably took me less then 6 hours to build. I've be denied certain choices I've become reliant on (PIL, Mako), but with quality of the initial APIs and Googles repeated insistence that the framework is nowhere near feature complete leave me at least hopeful for replacements in leu of fixes.

09 April 2008

App Engine Revisited

So I still haven't gotten my App Engine invite (sigh) but I've been working with the SDK and I've got a skeleton framework up and running with WebOb and Routes for controller dispatch. I've also put together a simple blogging application. I find the system limited, but limited in a way I think will inspire creativity among those who like to push the boundaries they've been given.

The included WSGI framework is admittedly simple, and I'm personally not that fond of the parts of Django they've managed to shoehorn into the environment so I think I'll be rolling my own framework for all future projects. A sort of Pylons lite, if you will. Routes, Mako (if possible *crosses fingers*, I have "issues" with Django templates) and Googles data store/ORM. I'm still debating the necessity of a session framework like Beaker if I'm going to be using the Users API but it would be nice to have.

Anyway, I hope to get an invite soon (hello? anybody?) but at least I'll be ready when I do. Hopefully this blog will soon be served up from AppEngine!

08 April 2008

Google Announces Google App Engine

The highlights for now:

  • Python! *Squeeee*
  • No C Extensions (boo! understandable, but still boo.)
  • WSGI!
  • Django!
  • Google Mail, Apps and Accounts integration!
  • BigTable™
  • FREE!
  • Did I mention Python and WSGI?!

I've got to go change my pants now, but I'll post my extended thoughts later. I'm furious I didn't hear about this sooner and get one of the initial invites. WTF internets?!