Thursday, October 15, 2009
Saying Goodbye to Dojo
Being a part of the Dojo project has been an amazing opportunity for me. Dojo Storage helped legitimize the idea of doing client-side storage, and the experience working on it helped shape parts of the HTML5 Local Storage API when it was being developed. Creating Dojo Offline went from crazy prototype idea to real shipping code thanks to SitePen and Google, and led to my involvement with Gears and also helped shape aspects of the HTML5 Offline work.
The last year and a half, though, I really haven't been able to be a part of the Dojo community, and I don't see that changing. Dojo Storage and Dojo Offline are being used by real users and real sites but I simply haven't had the bandwidth to fix important bugs or add new functionality. There comes a time when an open source programmer has to admit that they simply can't juggle so many balls in the air at once.
I've essentially left the Dojo community the last year and a half but consider this blog post more formal. Other things have swept me up and forced my time. I can no longer maintain Dojo Storage and Dojo Offline. This is a great chance for the users and developers who use both of these packages to step up to maintain them and continue developing them; I pass the baton to you. You won't be sorry being a part of Dojo; I know I haven't.
I wish I was good at everything; I'm obviously not ;) The particular thing I'm good at is coming up with some strange new idea, then doing several passes of engineering and work to make it real and bring it to a shippable state and get it past the 'giggle factor'. I've done this with things like Really Simple History, coworking, and more. I'm good at the 0.1, 1.0, and 2.0 phases. Past that, I'm not particularly good. I guess the wisdom of 'old age' is accepting your strengths and weaknesses ;)
So long, and thanks for all the fish!
Wednesday, March 26, 2008
Updated Dojo Storage ZIP file + Demos
The ZIP file I put up for the new release of Dojo Storage was broken. Here is a new one with the critical bug fixed (basically the test file did not point to the right location). Also, I'm now hosting the new Dojo Storage release on my web server so you can play with the testing file here and the Hello World demo here to get a taste of Dojo Storage without having to download things yourself. Note that this is based on Dojo 1.1 and is a pre-release, since Dojo 1.1 will go out Real Soon Now (tm) but is not out yet. Thanks to Andrew Woolridge for pointing out that things were broken.
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
- 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.
Sunday, June 10, 2007
The Little Guy
Google Gears the first offline web application toolkit?
"One thing I hate that the IT Industry is that when someone releases a piece of technology that is completely revolutionary, and no one takes stock, however when some company with a lot of clout in the industry such as Google or Apple release, everyone think that they rock!
From my RSS feeds I stumbled across this article in ZDnet "Can Microsoft change 'gears' for the sea-change ahead?". The title was attractive so I started reading it, however early on in the article I came across this:
"During that time, I have drawn attention to the work being done with JavaDB and Derby as examples of how the offline problem might get solved. But, ultimately, I have routinely said that when the problem gets solved, it will get solved by Google. Last week, with Google's announcement of Google Gears, that day came."
Once I read this I stopped reading why? Because Google Gears is NOT the first offline web application toolkit. The first on to my knowledge is Dojo Offline. Dojo is a popular AJAX framework, and Dojo Offline extends basic Dojo's capabilities by allowing Dojo applications to be used while you're offline....So why is it that the IT industry does not recognize achievement and give credit where it's due?"
Thanks for the blog post Irfan!
I actually just sent David Berlind, the author of the ZDNet article, the following email:
Hi David! My name is Brad Neuberg; I created an offline open source framework named Dojo Offline in conjunction with SitePen. I wanted to point to an inaccuracy in one of your articles:
"Can Microsoft change 'gears' for the sea-change ahead?"
You claim that Google Gears is the first offline toolkit. In fact, Dojo Offline (and Dojo Storage) shipped before Google Gears with a similar model: a very-lightweight plugin that extended the browser to cache resources when offline, in conjunction with a simple API to help you build offline web applications.
As one of the 'little guys' who works hard to do my innovation out in the open and much of the time for free, it's important to me that I at least get credit when I create something before others. Most of my ideas usually sound weird and are ignored when I first float them, such as the offline problem which I've been attacking for the last few years, with focused solutions such as Dojo Storage, Dojo Offline, and others, or coworking when I first started it, so it's important to me that I get credit when they finally go mainstream so folks take me seriously on my next weird idea.
Thursday, June 07, 2007
Moving On: Coworking, Really Simple History, and Flash Storage
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.
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.
Thursday, May 31, 2007
Presenting at Google Developer Day
Tuesday, May 29, 2007
Dojo Offline Interview
Monday, April 23, 2007
Dojo Offline Beta Released: Toolkit for Offline Web Apps
This was such a crazy application for me to work on. I've been crunching away on the offline problem for years, throwing different things against the wall to see what would stick: AMASS, Dojo Storage, early offline work using Dojo Storage and browser caching tricks, and now Dojo Offline. This project was a serious coding stretch for me; it involved using 6 different languages, 3 of which I don't even know (Perl, NSIS, Bash Shell Scripting) and one in which I'm frankly not very good at (C). Here's the languages it took for me to get this out the door:
- C - for local proxy
- Java - for server-side portion of Moxie demo app, using servlets and MySQL to create a full syncing example
- Perl - for Mac OS X installer
- Bash Shell Scripting - for Mac OS X installer
- Nullsoft Scriptable Install Script - for Windows installer
This project almost didn't happen multiple times -- there were many times in which I thought it would be impossible and got pretty close to giving up, but the thought of not delivering kept me going. What we have up is a beta -- there are bugs and glitches for some edge cases, but the functionality is there and the core use cases work well. We now just have to drive the beta forward and keep iterating to press the bugs out across more and more tested PCs. Very special thanks to SitePen (Dylan Schiemann and Carrie Sackett in particular) -- without their support the Dojo Offline Toolkit would never have happened.
I'm really going to need the help of the wider community to pitch this tent. Dojo Offline is really just a scrappy open source project, and like any low-to-the-ground open source project it's resource constrained. What we really need is one or two more really good C-programmers. With that the sky would be the limit.
Ok, now I'm going to go sleep for a very long time :)
Subscribe to Posts [Atom]