Tuesday, December 11, 2007
Using Google Gears on a Weblog
My buddy Niall Kennedy has added Google Gears support to his weblog. While most folks think of Google Gears as just a plugin that helps you go offline, it also includes interesting tools that can help with web site performance, such as a local server that can serve resources and a local database for storing client-side data. Niall specifically used Gears to improve the performance of his blog by having all the images and resources of his blog get cached into the Gears local server. The end result of this is that when users hit his site in the future, images and other ancillary resources are served from Gears rather than his remote web site, improving the load time of his page.
A similar effect can be achieved by simply turning on HTTP/1.1 caching for your images and scripts. However, this caching is on a file-by-file level. The nice thing about Gears is you can bundle an entire set of resources at once, versioning them. You do this with a simple manifest file that you put on your web server. Here is Niall's:
Read more info on manifest files here; Dion Almaer has also written a tool that can help generate them for you.
Note that the manifest file isn't enough; you will need to create a bit of JavaScript that loads the manifest file for Gears. It would be cool if Gears would do this automatically, perhaps when the file has a well-known name on the root, such as /x-gears-manifest.json or something; note that this isn't on the roadmap right now -- it's just a random idea from me.
Niall also tied in a bit of reporting so he could track how many of his visitors are using Google Gears using a clever trick. In his JavaScript he put some Urchin tracking code to see how many folks grabbed the Gears manifest file (Niall told me it was ok to share this):
A similar effect can be achieved by simply turning on HTTP/1.1 caching for your images and scripts. However, this caching is on a file-by-file level. The nice thing about Gears is you can bundle an entire set of resources at once, versioning them. You do this with a simple manifest file that you put on your web server. Here is Niall's:
{
"betaManifestVersion":1,
"version":"1.01",
"entries":[
{"url":"../css/design.css"},
{"url":"../css/resume/style.css"},
{"url":"site.js"},
{"url":"../css/images/body_bg.gif"},
{"url":"../css/images/frame_bg.gif"},
{"url":"../css/images/roundcorners.gif"},
{"url":"../css/images/blog-backgrounds.gif"},
{"url":"../css/images/icons.gif"},
{"url":"../css/images/feed-readers.gif"},
{"url":"../css/images/img_bg.gif"},
{"url":"../css/images/preview.gif"},
{"url":"../css/images/postcomment.gif"},
{"url":"../css/images/search.gif"},
{"url":"../css/images/icons/email.gif"},
{"url":"../css/images/icons/phone.gif"},
{"url":"../img/headshot.jpg"},
{"url":"../css/images/headers/about.gif"},
{"url":"../css/images/headers/contact.gif"},
{"url":"../css/images/headers/home.gif"},
{"url":"../css/images/headers/personal.gif"},
{"url":"../css/images/headers/resume.gif"},
{"url":"../css/images/headers/soccer.gif"},
{"url":"../css/images/resume/msft.png"},
{"url":"../css/images/resume/technorati.png"},
{"url":"../css/images/resume/nextag.png"},
{"url":"../css/images/resume/callan.png"},
{"url":"../css/images/resume/aeosports.png"},
{"url":"../css/images/resume/amex.png"},
{"url":"../css/images/resume/pricegrabber.png"},
{"url":"../css/images/resume/ucla.png"},
{"url":"../css/images/resume/java.png"}
]
}
If Niall wants to refresh all of these resources, he can just change the "version" number; Gears will then refresh all of the resources when this happens.Read more info on manifest files here; Dion Almaer has also written a tool that can help generate them for you.
Note that the manifest file isn't enough; you will need to create a bit of JavaScript that loads the manifest file for Gears. It would be cool if Gears would do this automatically, perhaps when the file has a well-known name on the root, such as /x-gears-manifest.json or something; note that this isn't on the roadmap right now -- it's just a random idea from me.
Niall also tied in a bit of reporting so he could track how many of his visitors are using Google Gears using a clever trick. In his JavaScript he put some Urchin tracking code to see how many folks grabbed the Gears manifest file (Niall told me it was ok to share this):
store=server.createManagedStore('niallkennedy');
store.manifestUrl='/js/gears-config.json';
store.checkForUpdate();
urchinTracker('/js/gears-config.json');
Now if Gears initializes and is present, we reached the urchinTracker() call and the fact that Gears was initialized is registered with Urchin. BTW, if you don't know what Urchin is its a tool that you can plug into your web pages to get analytics and find out what pages are being accessed and how.Labels: gears, google gears, weblog
Thursday, November 29, 2007
Advocating for the Web and Developers
I'm really passionate about the web and developers; I believe the web is one of the greatest gifts of our time, an amazing open system akin to the Library of Alexandria dropped into our laps. Much of my career has been about either extending the current web to have new functionality, such as Dojo Storage, RSH, and Dojo Offline, or imagining new kinds of browsers and new iterations of the web, such as Paper Airplane and HyperScope.
This coming Monday (December 3rd) I'm honored to be joining Google as a Developer Advocate. My job will be to evangelize the range of open source tools and APIs Google has released, such as Google Gears, GData, Android, and more. Google and the Web are in a virtuous cycle -- Google's DNA is built on an open web. When the Web does well, Google does well. Even better, Google is an open source, geek institution, where engineers are respected and run the place.
When I interviewed with the Developer Advocate team I found that all of them were passionate about evolving the web, keeping it an open resource for the world. Google has developed an amazing stable of open source tools that haven't had as much exposure as they should.
For example, have you checked out GData? It's basically smart syndication, what we used to call the lower-case semantic web at Rojo, where you have intelligent, semantic web services without the cruft and complexity of RDF -- you can access many of Google's sites as syndication feeds, delivered in Atom, and can update them using the Atom Publishing Protocol. GData is basically Atom + Atom Publishing Protocol, both open standards. There are GData feeds for Google Docs, YouTube, Calendar, and more -- nothing is stopping others from creating GData feeds as well, such as using GData behind the firewall for Enterprise 2.0 type niftiness.
Another cool tool is Google Gears, which is the team I will be working with initially. Google Gears is a browser plugin that helps to evolve the web in-place -- users can download a small plugin that augments the web browser with new functionality. The initial functionality is offline web applications, similar to the Dojo Offline work I did with SitePen. Google Gears is fully open source, under a BSD license. Do you have an idea on how to evolve the web, perhaps with cross-site XHR or cross-site package caching? You can create a Gears module and take part in the open source community.
I'm really excited about Google Gears ability to help sidestep the 5-year diffusion process it normally takes to get new functionality out to the web. Rather than waiting upwards of 5 to 7 years for a client-side relational database to appear in all the web browsers, for example, Gears simply bundled SQLite into itself, exposed it with a JavaScript API, and baked it into the Gears plugin. I think we are just beginning to see the power of Gears. Hopefully it can act as an accelerator to help keep the web open and functionally evolving over the next few years as users demand more from their web applications.
Google has a saying in our philosophy to "focus on the user and all else will follow." When it comes to developers I believe the same is true -- "focus on the needs and interests of the developer and all else will follow." To be honest I wouldn't be working at Google if I didn't believe Google has the ethics and drive to focus on developers and make the web a better place.
To that end, I want to make some promises to the wider community -- if you see me wavering on these I invite you to challenge me and call me out on them.
I promise to be honest and transparent. I will do my best to give you my real answer -- if I think some Google technology is not appropriate for the task you are trying to solve, I will tell you so and recommend a non-Google technology. I will also strive to be as transparent as I can. I know that Google has a strict secrecy policy, but working within that I will ensure that I remain in communication with developers as much as I can so they are not blindsided.
I promise to not suffer from NIH (Not Invented Here) syndrome and remain humble. While Google has alot of smart people, I believe that there are more smart people outside of Google than inside. NIH is a common problem that companies face -- they can refuse to look at external technologies that were Not Invented Here, promulgating their own instead even when the external ones are superior and winning. I will work hard to make sure I don't fall into that fallacy, and remain humble.
I promise to collaborate. One thing that used to frustrate me when I was outside of Google was the difficulty in collaborating with people inside of Google. Everything was either secret or was thrown over the fence already mostly finished. I promise to work hard not to replicate that -- I want to collaborate and brainstorm with folks across the community and other companies to figure out how to make the web a better place, with everything from structured brainstorming sessions at conferences, to hack days to actually implement some of these ideas. Let's start hacking.
I promise to not simply disappear. I will continue blogging, taking part in open source communities such as Dojo, and showing up at conferences. I won't simply disappear into the Googleplex :) There will probably be a slow down at first as I get aculturated to the new environment, however. I'll continue to hack on Dojo Offline -- hopefully I'll get some time to work on it at Google since it runs on Gears. I will continue to be a member of Douglas Engelbart's community and the HyperScope project, doing jams when we can to work on things like granular addressability and Purple Include -- in fact, I'm excited to see what kinds of stuff I can hack internally at Google to support advanced hypertext.
Any thoughts on all this? Post some comments and let's chat.
Best,
Brad
This coming Monday (December 3rd) I'm honored to be joining Google as a Developer Advocate. My job will be to evangelize the range of open source tools and APIs Google has released, such as Google Gears, GData, Android, and more. Google and the Web are in a virtuous cycle -- Google's DNA is built on an open web. When the Web does well, Google does well. Even better, Google is an open source, geek institution, where engineers are respected and run the place.
When I interviewed with the Developer Advocate team I found that all of them were passionate about evolving the web, keeping it an open resource for the world. Google has developed an amazing stable of open source tools that haven't had as much exposure as they should.
For example, have you checked out GData? It's basically smart syndication, what we used to call the lower-case semantic web at Rojo, where you have intelligent, semantic web services without the cruft and complexity of RDF -- you can access many of Google's sites as syndication feeds, delivered in Atom, and can update them using the Atom Publishing Protocol. GData is basically Atom + Atom Publishing Protocol, both open standards. There are GData feeds for Google Docs, YouTube, Calendar, and more -- nothing is stopping others from creating GData feeds as well, such as using GData behind the firewall for Enterprise 2.0 type niftiness.
Another cool tool is Google Gears, which is the team I will be working with initially. Google Gears is a browser plugin that helps to evolve the web in-place -- users can download a small plugin that augments the web browser with new functionality. The initial functionality is offline web applications, similar to the Dojo Offline work I did with SitePen. Google Gears is fully open source, under a BSD license. Do you have an idea on how to evolve the web, perhaps with cross-site XHR or cross-site package caching? You can create a Gears module and take part in the open source community.
I'm really excited about Google Gears ability to help sidestep the 5-year diffusion process it normally takes to get new functionality out to the web. Rather than waiting upwards of 5 to 7 years for a client-side relational database to appear in all the web browsers, for example, Gears simply bundled SQLite into itself, exposed it with a JavaScript API, and baked it into the Gears plugin. I think we are just beginning to see the power of Gears. Hopefully it can act as an accelerator to help keep the web open and functionally evolving over the next few years as users demand more from their web applications.
Promises
Even though one of my jobs is to promote Google's technologies to the developer community, that is only half my work -- the other half is to advocate for all of the developers outside of Google within Google. I will be internally advocating and fighting for the interests of developers and the web in general inside the halls at Google.Google has a saying in our philosophy to "focus on the user and all else will follow." When it comes to developers I believe the same is true -- "focus on the needs and interests of the developer and all else will follow." To be honest I wouldn't be working at Google if I didn't believe Google has the ethics and drive to focus on developers and make the web a better place.
To that end, I want to make some promises to the wider community -- if you see me wavering on these I invite you to challenge me and call me out on them.
I promise to be honest and transparent. I will do my best to give you my real answer -- if I think some Google technology is not appropriate for the task you are trying to solve, I will tell you so and recommend a non-Google technology. I will also strive to be as transparent as I can. I know that Google has a strict secrecy policy, but working within that I will ensure that I remain in communication with developers as much as I can so they are not blindsided.
I promise to not suffer from NIH (Not Invented Here) syndrome and remain humble. While Google has alot of smart people, I believe that there are more smart people outside of Google than inside. NIH is a common problem that companies face -- they can refuse to look at external technologies that were Not Invented Here, promulgating their own instead even when the external ones are superior and winning. I will work hard to make sure I don't fall into that fallacy, and remain humble.
I promise to collaborate. One thing that used to frustrate me when I was outside of Google was the difficulty in collaborating with people inside of Google. Everything was either secret or was thrown over the fence already mostly finished. I promise to work hard not to replicate that -- I want to collaborate and brainstorm with folks across the community and other companies to figure out how to make the web a better place, with everything from structured brainstorming sessions at conferences, to hack days to actually implement some of these ideas. Let's start hacking.
I promise to not simply disappear. I will continue blogging, taking part in open source communities such as Dojo, and showing up at conferences. I won't simply disappear into the Googleplex :) There will probably be a slow down at first as I get aculturated to the new environment, however. I'll continue to hack on Dojo Offline -- hopefully I'll get some time to work on it at Google since it runs on Gears. I will continue to be a member of Douglas Engelbart's community and the HyperScope project, doing jams when we can to work on things like granular addressability and Purple Include -- in fact, I'm excited to see what kinds of stuff I can hack internally at Google to support advanced hypertext.
Any thoughts on all this? Post some comments and let's chat.
Best,
Brad
Labels: gdata, google, google gears, projects
Friday, July 06, 2007
New Dojo Offline Release
I am proud to announce a new beta release of Dojo Offline. This release has a huge amount of exciting new functionality, including a full port to Google Gears, a port from Dojo 0.4 to 0.9, and more.
Dojo Offline is an open-source toolkit that makes it easy to create sophisticated, offline web applications. It sits on top of Google Gears, a plugin from Google that helps extend web browsers with new functionality. Dojo Offline makes working with Google Gears easier; extends it with important functionality; creates a higher-level API than Google Gears provides; and exposes developer productivity features. In particular, Dojo Offline provides the following functionality:
- An offline widget that you can easily embed in your web page with just a few lines of code, automatically providing the user with network feedback, sync messages, offline instructions, and more
- A sync framework to help you store actions done while offline and sync them with a server once back on the network
- Automatic network and application-availability detection to determine when your application is on- or off-line so that you can take appropriate action
- A slurp() method that automatically scans the page and figures out all the resources that you need offline, including images, stylesheets, scripts, etc.; this is much easier than having to manually maintain which resources should be available offline, especially during development.
- Dojo Storage, an easy to use hashtable abstraction for storing offline data for when you don't need the heaviness of Google Gear's SQL abstraction; under the covers Dojo Storage saves its data into Google Gears
- Dojo SQL, an easy to use SQL layer that executes SQL statements and returns them as ordinary JavaScript objects
- New ENCRYPT() and DECRYPT() SQL keywords that you can mix in when using Dojo SQL, to get transparent cryptography for columns of data. Cryptography is done on a Google Worker Pool thread, so that the browser UI is responsive.
- Integration with the rest of Dojo, such as the Dojo Event system
To get started: See the Dojo Offline home page; read the new tutorial titled "Creating Offline Web Applications With Dojo Offline"; download the new Dojo Offline 0.9 beta SDK; and play with the demos.
Labels: announcement, dojo, dojo offline toolkit, dojo storage, google gears, release
Thursday, May 31, 2007
Presenting at Google Developer Day
Hi folks; I'll be talking today at the Google Developer Day on Dojo Offline + Google Gears integration down in San Jose. I'll be showing a prototype of integration, with some cool exciting functionality that I haven't discussed before. The combined Dojo Offline/Google Gears release will happen in a few weeks. My Google Dev Day presentation is at 4:30 PM, and is part of the Nuts and Bolts session near the end of the day (the GWT team will be there too). Google is helping to fund the Dojo Offline/Google Gears port, and I am consulting with them through SitePen.
Labels: dojo, dojo offline toolkit, google, google gears
Subscribe to Posts [Atom]
