This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Monday, December 03, 2007

Really Simple History 0.6 Released

Brian Dillard releases Really Simply History 0.6! Congratulations Brian!

(BTW, I'm on the Google Bus for my first day of work; wish me luck)

Labels: , , ,


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.

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: , , ,


Thursday, June 07, 2007

Moving On: Coworking, Really Simple History, and Flash Storage

Every so often I look back over the projects I'm doing and take stock. I have a little inner thermometer that I check in on from time to time, and if I'm feeling stressed out and not having fun anymore it gives me information and a clue that I need to revisit what I've been doing. When I feel this, I create a Not Do Do List and figure out stuff that I need to let go of. Lately, I've been feeling stressed out and not having as much fun, feeling like there is a monkey on my back, so I've been doing things like morning pages, meditation, visual journaling, and other stuff to see what I need to change.

On a deeper level, I've been looking over what I'm good at and what I'm not good at. It seems my natural role is as an inventor pragmatist. I initially create an idea that is different than what is out there, envisioning something wierd and different, then do the hard work of making it initially pragmatic and real to prove to the world that it should be taken seriously whereas before it was ignored. Then, about a year or two down the line, others show up who have other skills that I am not as good at but are very important at this stage, such as community building, event planning, and more. I'm really good at brainstorming an idea, prototyping it, and then taking it into the initial reality stage with working code that can be used in the real world, in real software. I'm good at release 1 and 1.5, but not as good at release 2 and release 3. I'm not good at organizing groups of people, creating events, or cranking on the same code base once the initial idea and implementation has been proven to the community. I used to beat myself up about this, but I've realized that I just have to focus on what I'm good at and create situations where others can help me at the things I'm not as good at.

I've realized there are a number of projects that I created that have moved beyond this initial phase and are now successful and standing on their own legs, and it's time for me to find new maintainers for them and let them go, put them on my personal Not To Do List so to speak. These are coworking, the Really Simple History library, and Flash-based client-side storage. I need to find new maintainers for some of these projects so I can focus more time and attention on Dojo Offline. Also remember that almost all of the time I spend on these projects is free-time that I don't get paid for, and I only have so many hours in the day to hack on cool new stuff.

Coworking

I created coworking about 2 years ago. I had been working for a startup, Rojo, and wanted to go into business for myself as a consultant. However, I somehow wanted the community and structure of a workplace with the independence and freedom of working for myself, so I created coworking. Coworking was a way for independent contractors and workers to have a common space to work from, rather than hacking from home, with a more community minded focus. I rented some funky space from a small non-profit called Spiral Muse and ran it for about 8 months. Through a nice coincidence the Spiral Muse space was where I met my sweetheart, Bekka Fink, at a party months before. We couldn't store permanent stuff at the space, so I had to setup folding card tables every morning when I got there then break them down at the end of the day. For the first month I had no one, and just went to the space and worked there by myself, going through the action of setting up the folding card tables and wondering if anyone would ever show up. Eventually I had a full house, with an eclectic group of folks: a screenplay writer, a computer researcher, an open source hacker rolling his own computer language, and others.

From time to time people would drop by who were interested in the idea of coworking but weren't able to join the Spiral Muse space. I would tell them "if you were to steal this idea and make it your own, what would you do?" They would then wander off, a seed planted.

I had to close the Spiral Muse space after about 8 months since it was hard to grow within it's small size and it was getting hard to staff it; during that time those folks who had dropped by to check out the space started banding together to create an even better space, one that was larger and open more days of the week. This was the Hat Factory space, in San Francisco.

Since then coworking has spread around the world, with spaces already in or forming in New York, Paris, and more. There is an active Google Group with hundreds of members and a very active wiki. Coworking has been covered by Business Week, the New York Post, and more. Chris Messina and Tara Hunt are now the most active leaders of the coworking movement and are instrumental in moving it forward, creating events, organizing, and more. I've stepped out of an organizing role in the coworking movement to focus on other projects and am no longer a member of a space.

Really Simple History

I created the Really Simple History (RSH) library about two years ago. It was one of the first libraries to effectively solve the history and bookmarking issues inherent with Ajax applications. I had two goals with RSH: one, to show that history and bookmarking were important in Ajax applications (most developers at the time thought you could just throw this feature out and ignore that you were working in a browser); and two, that you could achieve this in contemporary web browsers using various browser tricks.

Today, RSH is used by a huge number of websites to solve Ajax bookmarking and history issues; it is also integrated into alot of other open source projects. Members from the Yahoo YUI team and the Google GWT team have told me that the BSD-licensed Really Simple History code base and techniques were instrumental in their own history libraries. RSH has been written up in online articles and books, and is now used by developers in their daily practice. Respecting the back button and creating a bookmark mechanism are now accepted practices in the Ajax industry, so I don't need to beat that drum anymore.

Unfortunately, I have not been able to do any real work on RSH for about 1 1/2 years. Important work remains: doing better QA on Internet Explorer 7, using one of the various Safari history/bookmarking techniques that have been discovered, fixing some bugs that can occur in various edge cases, and more. My focus on Dojo Storage and Dojo Offline have not allowed me to do work on this library; I am constantly getting emails with bug fixes and inquiries, and I feel terrible that I haven't gotten a new release out the door for awhile.

I am looking for a new maintainer for the RSH library. I want to make sure I find someone who will treat it well because alot of folks depend on it, so if you are interested please email me (bkn3 AT AT columbia.edu) and give me your qualifications, open source experience, and where you plan on taking the library.

Flash-Based Client-Side Storage

I've been hacking on the offline web problem for a few years. I knew before I could work on offline access to an application's user-interface, though, I had to figure out how to store data permanently on the client-side, beyond the 4K cookie limit. About 2 1/2 years ago I started searching around for a way to do this, experimenting with giant bookmarklets and other wierd stuff to see if I could find a clever back door. I then realized I could use a hidden Flash applet to store megabytes of info.

I rolled a prototype of this Flash based storage called AMASS (Ajax Massive Storage System) to see if the idea was tenable, and it turned out to work well. I then rolled another version of it and refactored it into Dojo, and got it to work in Safari as well; I also did a bunch of (grotty/interesting) hacks to get it super-fast for storing large datasets.

Once Flash-based storage stabilized, I moved on to the other part of the offline problem, which is finding your user-interface when you are away from the network, and rolled Dojo Offline in partnership with SitePen. Of course, one month after we released Google released Google Gears, a similar offline solution, so we created a partnership with them to port the Dojo Offline APIs on top of Gears. I'm in the middle of coding that port now. The next release of Dojo Offline will include a Dojo SQL module to use SQL-based storage, and a new Dojo Storage provider that uses Gears to store its data. Dojo Offline will no longer be dependent on the Flash Dojo Storage provider or the Firefox 2 Dojo Storage provider, and I would like to find a new maintainer for those. My preference for client-side storage is now to use Dojo Storage in conjunction with Google Gears. There are a number of startup companies that are using the Flash storage provider, however, and many users have told me they want to keep it; there are a number of enterprises that are also using it. I will port the Flash Storage Provider to the new Dojo 0.9 release that is coming out soon, but moving forward I would only like to personally maintain the GearsStorageProvider and the public Dojo Storage API. There are a number of cool performance and bug fixes that folks would like to get into the Flash Storage Provider, and this would be a great way to get your feet wet with the Dojo project. Please email me (bkn3 AT AT columbia.edu) your qualifications, open source experience, and future plans for the Flash Storage Provider if you would like to take this on.

Labels: , , , , , , , , ,


This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]