Monday Aug 14, 2006

Rumor: Pluto getting RIFd

There was a rumor on CNN today that Pluto is getting RIFd ("let go" if you aren't familiar with the acronym).

[Read More]

Sunday Aug 06, 2006

More REST and Web 2.0 for the Weekend

To many of us, loading up a few words like "Participation" or "AJAX" simply isn't enough to understand what embodies Web 2.0 vs. Web 1.0. The best description, ever, of Web 2.0 is What is Web 2.0 written by Tim O'Reilly.

Perhaps the best quote from the article is "Like many important concepts, Web 2.0 doesn't have a hard boundary, but rather, a gravitational core." O'Reilly then goes on to a meme map (Ok, if you feel foolish and don't know what a meme map is, you are not alone...maybe its Web 2.0 ;-), Wikipedia has a definition of Meme, I can only conclude that a meme map is really a me-me-map that has a map of me in the middle, as opposed to a Mimi Map, or a Mini-Me-Map). Still, the meme map is worth a look.

My friend Eric Olson and I collaborated (about 5 years ago) on a project that very much embodied the Web 2.0 characteristics, so I'm going to use it as an example since it was pre-AJAX and we won't get carried away with examples of Google, Flickr, and other off-the-shelf examples. I will present Stereo Beacon, then use O'Reilly's Web 2.0 "Patterns" to describe the 2.0-ness of Stereo Beacon as well as its weaknesses, thus hoping to illustrate the Web 2.0 patterns presented by O'Reilly.

First, a description of Stereo Beacon: Stereo Beacon is an MP3 player built with the Java Media Framework (JMF). But it wasn't a standard media player, it was fully networked, and fully peer to peer (without a centralized controller). As folks joined a channel, the metadata about their music (not the music itself) would be shared with all of people in the peer network. Anyone in the peer network could request that a song be played, regardless of the song location. The "requests" were queued up and people had votes that they could move a song up or down on the shared channel. As one song ended, a token would be passed to the machine that held the next song and that machine would kick off a multicast playing of the song (through JMF) that the entire peer network would hear in sync. Basically, a shared radio station based on music residing in each other's libraries. Because the files weren't passed around, we felt that we were helping protect digital content (though, there do appear to be rules governing the broadcast of music that could be applied here...still...).

I'll take some liberties with the implementation as I discuss Stereo Beacon and how it embodied Web 2.0 based on Tim O'Reilly's article. O'Reilly presents several principles or "patterns" that describe Web 2.0 characteristics. Stereo Beacon did not embody all of these, so let's talk about those it did:

  • Users add value: Simply put, the more users of Stereo Beacon, the larger your music library and the more variety you would have as users requested songs from each other's libraries. Also, you could use your votes with others to bump requests up or down the queue if you got annoyed at songs.
  • Network Effects by Default: Turn on Stereo Beacon, share your library, be included in the group. Stereo Beacon could also be used as a stand-alone MP3 player, a pretty good one too, but the goal was to start up and connect.
  • Some Rights Reserved: We could have done better, but the library format was easy to read and the passing of information could easily have been converted to a simple XML over HTTP format with simple REST-like resources identified (music library, song, etc...)
  • The Perpetual Beta: We were always tweaking builds and making new versions, had we had more users, the threading model could have been much better and we could have improved it substantially. Also, we didn't really push it out there or on our friends heavily...but when we did, bugs flowed in and we improved things. In addition to bugs, features were added and removed. With more users, this feedback cycle could have been much better with new versions being rapidly created based on the popularity of features (like voting or a "direct from CD" play mode that Eric added).
  • Cooperate, Don't Control: We never published our message framework, we weren't really asked to, but this would have been easy to do. Music players today could learn a lot from this lesson, media streams are incalcuably fun to hack, play with, and enhance.
  • Software Above the Level of a Single Device: As I mentioned earlier, the notion of "A user's music list" was not important to Stereo Beacon. The notion of the "Collective's" music library was paramount. The network blurred the lines between the individual, you had no notion of where your music was being played from, just that you had so much music at your fingertips for which you competed with others to build an anarchic yet similar radio station (late in the development of Stereo Beacon, we added the notion of channels so that someone's "Cure"-centric library wouldn't be mixed with someone else's "Dixie Chicks"-centric library).

Recalling that we were Web 2.0 before Web 2.0 existed, we did have some issues...we used a client-based graphics package that required an install. We weren't HTTP-based (we used socket-socket communications after we evaluated JINI/a still nascent JXTA/Jiro), and we didn't use XML heavily (remember, this was also just as the popular XML-standard interfaces were developing). Things we didn't do well were:

  • Enable the Long Tail: First off, it was probably a mistake to try to do pure peer to peer application programming. Its a fun experiment but, frankly, distributed thread models in a true peer-to-peer environment are hard. Had we went with a central-server model, we could have easily started to build out communities and enabled third-party add-ons based on our resource models and distribution models. This would have also allowed others to build communities based on our server and resource-sharing models, extending our tail outside of our own application box and into community models (of which few were available at the time).
  • Data is the Next Intel Inside: Our data was ripped purely from the MP3 IDV3 tags, then the channel was enhanced with voting information. Had we hosted the communities on our site, we could have easily built server-centric play lists based on the popularity of songs available in "neighboring" communities, thus creating our own extensions of the data and also increasing the Web 2.0 concept of "Users Add Value".

If I didn't have a couple of kids perpetually circling me in my off hours and Eric playing with alternate media streams (you would have to ask him...), the player could easily be rebuilt with substantial improvements in this brave-new Web 2.0 world, for example:

  • Web-based rather than client install: AJAX brings a level of interactivity we didn't have when we first built Stereo Beacon. This interactivity would have allowed a server-based model with little or no client install that simplified our threading models AND allowed us to extend the IDV3 tags with data collected in our community to create a better "Data is the Next Intel Inside". Also, making Stereo Beacon a Web-based Service and in Perpetual Beta rather than a client-installed Perpetual Beta would have allowed us to creep features in and out quickly and enhance them without making our users reinstall Stereo Beacon with each new build.
  • Standard Resource Models: The library formats were put together and single-minded, opening these up and offering our meta-data on the Web could have opened up unexpected community extensions. Also, using a REST architecture (XML over HTTP with message passing) would have allowed users to create add-ons and their own front ends and allowing us to host the "Data Inside" the application rather than controlling the application.

So, in a nutshell, read the Web 2.0 article by O'Reilly. Perhaps my FAVORITE of O'Reilly's patterns is: "Software Above the Level of a Single Device". Nicely done Mr. O'Reilly.

Tuesday Aug 01, 2006

Brain Dump - Things to do with a Master's in CS

Updated with new service: WiFi for a fee.

I've spent quite a bit of time helping my neighbors with their computer in the past few days. We had a lightning strike in the back that fried their ethernet port, they are frustrated talking to the HP support folks, they need their new high-speed Internet. I ended up going over and putting in a new NIC for them and installing their virus software. All in all, about an hour of work.

Still, it really begs the question, how do I monetize this side-job. I mean, really, its non-traditional. Folks know they need work done on their computer stuff, but they often don't trust some random geek (I can use this term since I am one) they call off the street and some businesses prices are just too high. FURTHER, these folks are NOT getting the help they are promised from where they purchased their computer and they are nickel and dimed to death (most of these folks can get free virus software through their ISP yet the companies insist on charging them $60 for software).

So, I have a solution...we all trust the ice-cream truck and our kids are almost giddy when they hear that music.

Here's my plan. Should I ever get tired of working for Sun (or Sun gets tired of me working for them), I'm thinking I will
a) buy an ice-cream truck

b) rebrand the ice-cream truck with images and labels like "Getchyour Viruses Fixed Here" and "Is your WIFI secure" and "I can help with your Nano" and "I spy spyware" and, maybe if I want to penetrate the power user "Getchyour home grid from me in under 2 hours"
c) create an 8-track tape (I somehow doubt my MP3 CD would work in the ice-cream truck) with my favorite jack johnson tunes (adults love jack makes them all happy and giddy like a kid).
d) drive around the neighborhood playing my tinny jack johnson 8-track and selling services (two models, they can run out with joy to my truck and their CPU tower and I will fix it in my ice-cre...err...virus truck or i will come in and fix their computer for an extra fee...have you ever seen an ice-cream vendor out of their truck?)
e) when business stagnates i will offer free ice-cream cones to the kids with any service
f) attach a wifi-gumball-like machine to the back of the truck where adults can run up and put in their spare change to wifi enable their neighborhood at $5 / 10 minutes (no guarantee of service remaining in range so I recommend you have a laptop and charged battery). Per the suggestion of a friend, each gumball will have an SSID and WEP password on the surface of the gumball, so jot them down before you eat your gum. can only dream.

Thursday Jun 15, 2006

Flock 0.7 Beta and Me

What am I doing on my vacation day?  Installing and playing with Flock 0.7 Beta, what else?

Flock is a Firefox-based browser that is, well, I suppose you could say "Community Enabled".  Its also still a bit buggy, but then, its a beta.  To be honest, it is in MUCH better shape that the last version I tried.  This is a post from the built-in blogging tools.  I had to experiment a bit, using the "Blogger API" for didn't work, so I started picking and choosing...if this posts without error, then the settings I used are:

API: WordPress Blog


User ID: mine

Password: Idon'tthinkso

The error path for using the "Blogger API" isn't right, so there was no error when you press "Next", it just stops with no error message.  So, hit the "Back" button and try again.

I like the new look and feel, but that is just a Theme, nothing special there.  There are a few VERY noticeable changes in Flock from Firefox:

- Built in RSS Aggregation - Basically, you can set up your RSS feeds in your side bar and they are displayed natively in your browser in a nicely layed out table.  Really, its a great feature.  You can automatically add to your "My News" page by clicking on the Live Bookmarks link that displays to the right of the URL in the address bar.  It took me some clicking around before I realized fact, I was just going to slam the lack of integration when I saw the icon ;-) I think it is VERY cool.  The only question I always have about all of these RSS feeds is whether I would rather surf the sites themselves or look at the RSS aggregation page.  I'm still, personally, up in the air on it.

- Built in Community Sites - Well, actually, only Flickr and Photobucket are supported...but its a start.  The photo support is interesting, basically, Flock has introduced a "Top Bar".  When I installed Flock it prompted me for information about my Flickr account.  Once you've added your photo account properly, you can drag and drop into the toolbar from anywhere (from the browser, from your explorer, from your desktop) and a Photo Upload appears where you can tag your photo appropriately.  Once uploaded, the picture remains in your top navigation bar.  Very cool indeed.

- Built in Blog Tools - Like this this point, it doesn't seem "as feature rich" as something like w.bloggar, but there are some interesting options.  For instance, if I want to blog about something I've surfed to, I can simply right click when I'm reading some content and choose the "Blog This" option.  My blog (that I set up during configuration or after in the options) tool pops up and I can start blogging.

- Built in Web Snippets - If I don't want to blog immediately, I can save a location as a Web Snippet.  Then, in the bottom corner of my browser window, I can see all of my snippets.  A bottom navigation bar appears and I can see all of my snippets.  I can then drag the snippet into the main browser pane to go back, or into my blog tool like this: Jonathan Schwartz's Weblog

So, here's what I'm doing...I'm temporarily done with Firefox.  I'm moving to Flock for the time being.  I'm giving it the "three crash test".  When it crashes three times, I'm done.  If you're interested, it has only crashed on me once in an

At this point, I give Flock a B rating (stable, some new stuff, but its not compelling enough for me to risk uninstalling Firefox and IE on my Windows machine).  There is potential...

And just for the heck of it, since everything is Web 2.0 ;-)  I'll give it a 3.5\*(2.0) rating...basically, 7.0 on a 10.0 scale :-)  It definitely advances Web 2.0 concepts through the community integration (one feature I didn't mention is the automatic integration to sites like and Shadows so I can move my bookmarks around.  I'll reserve the right to move my 2.0 rating up or down as I play with it :-)

Blogged with Flock

Monday May 22, 2006

Round 1: Bluetooth vs. the Clothes Washer

It had to happen sooner or later, my Motorola Bluetooth headset was introduced to the clothes washer. [Read More]

Saturday May 20, 2006

Knowledge Tiers

The mechanisms you use to access knowledge (your brain's immediate access information, its remote memories, team members, the Internet and books) are getting closer together. Eventually, the people you talk to will have no clue where your knowledge came from (brain or Internet)! [Read More]

Wednesday Jun 22, 2005

Welcome to my Blog

Welcome to my blog...I'll tell you a little bit about decide if you want to drop back in once in a while. You can even drop a few comments and tell me I'm full of it...or not ;-)

Yes, I'm a software, I don't often subscribe to traditional definitions of an architect. I liked a definition in a book by Martin Fowler (geez...when was the last time I really had to sit and read????), it goes something like this: "architecture is the hard stuff". I like it, very simple. Unfortunately, I find that a lot of "architects" forget about the hard stuff and, worse yet, treat their architectures as infallible. If you don't face down "the hard stuff" (which often occurs late in the development cycle), the architecture is incomplete.

I'm fascinated by the whole architecture thing. Its C-L-E-A-R-L-Y neither a science nor a repeatable practice (when I say "repeatable", I do believe architecture is repeatable within a particular product/context, but its less repeatable if you move from position to position...applying Bredemeyer in two places will be difficult, unless you got lucky enough to start from scratch in both places...and how often does that happen in real life). What an architect is seems to be more in the context of the company and, even, the project that the architect exists on. You'll see my architecture views in later postings. Further, I think architecture and architects must be constantly evolving to address our unique challenges as leaders and creators.

Ahhh, the storage field. You know, I haven't always been in the storage Master's from Washington State was in the area of Filesystems...but then I did database for a while (DB/400), object oriented infrastructure (SOM/400, a CORBA implementation), business infrastructure (SanFrancisco), storage software and hardware, business software again, business architecture, and BACK to storage.... The whole storage field is completely unique. It has network complexity (FC, IP, iSCSI, SCSI, etc...), challenges in processing power (do you have a service processor or not?), its a hardware-centric field where software is often dismissed yet critical to success, and more. Oh yeah, and then there are the politics, standards bodies, layers of protocols, and more.

My approach to the storage field is that of any application writer...adopt infrastructure, leverage open source, don't rebuild commodity parts, be humble in what is yours to invent and can be scrapped together from other places, focus on the CONTENT, leverage your company's strengths. That last, Sun has a billion strengths. Sometimes you look around inside of Sun and there's all of this energy, and it is neither fully tapped and what is tapped is not harnessed all in the same direction.

Is that enough? Obviously this was fairly open-ended, I'll get more focused in future posts. I look forward to discussions with anyone that may read, and please, feel free to jot me a note some time. Or, lurk away.




« July 2016