I guess I should be clear here that I'm interested optimizing for effectiveness, notefficiency. By effectiveness I mean that speed of development, qualityof service, time to market, flexibility in the face of changingbusiness conditions, and ability to adapt in general are much moreimportant than overall number of lines of code produced or even averagefunction points per month. That is, a function delivered next week isoften far more valuable than ten delivered six months from now.
To do this, you need to start with the organization: Architecture reflects the organization that produces it. So, first you need to create an organization of loosely coupled small pieces,with a very few well chosen defining principles that let theorganization work effectively.
Each part of the organization should decide on things like the application server platform they should use individually. They're the ones with the expertise, and if there really is a best answer for a given situation they should be looking for it. On the other hand, if there's no clear answer and if there's a critical mass of experience with one platform, that one will end up being the default option. Which is just what we want; there's no top-down control needed here.
So the only case where there's an actual need for top-down organizational platform standards is to get acritical mass of people doing the same thing, where the benefit accruesmostly because of the critical mass, not because of individual projectbenefits. There's not much benefit to bulk orders of Apache/Tomcat, soif you're avoiding vendor lock-in the main reason to do thisis toenable interoperation. But that can be accomplished by picking openstandards and protocols -- pick some basic, simple, straightforwardstandards, make sure that teams know about them and are applying themwhere appropriate, and they'll be able to talk together. This is a risk mitigation strategy rather than an optimization strategy; in other words, you know you can always get something working with a known amount of effort using the loosely coupled strategy. When you're tightly coupled to anything, this is no longer true -- you inherit its risks. Tightly coupling an entire organization to an application server platform also creates a monoculture, making some things very efficient but also increasing the risk that you'll be less able to adapt to new environments.
I'm sitting right now listening to Doc Searls give the closingcomments, which is a good way to close out the day. He's justfinished making fun of hotels and is talking about the Live Web so I'dbetter pay some Attention.
Great. Larry Weber just related an anecdote about an IM based test preparation service which made $30M last year... which is nearly the same as a startup idea I was tossing around with some people three years ago. Well, I guess I need to average that out with all the truly stupid startup ideas I've had in the last three years before kicking myself. :)
panzerjohn at 6:24:16 PM PST Link to this entry | Blog about this entry | Incoming Links | Notify AOL
Beta only features (not going to journals.aol.com this week):
o An AIM presence icon showing status for screen names listed on entries or comments;
o Incoming links searches for other sites linking to that entry
Features going to journals.aol.com this week:
o Blog about this entry to make it easy to link to other people's posts
o Notify AOL about specific posts that violate terms of service
o For Private Journals, the ability to simply make your Buddy List your reader list (adding buddies adds them as readers).
Some fun RFC numerology: 4287 is a single-transpositionpermutation of my office phone extension. It's also the starcatalog number for Alkes Crateris, the primary star in theconstellation Crater (The Cup). Clearly Atom is the Grail. Or maybe my phone is.
Do meta-tags (tags applied to tags or tag-url tuple instances) make anysense? It's tags all the way down... Kevin Marks commentedthat co-occurrences of tags are good enough for most purposes. Need to think about that one.
Kevin's TailRank beta is a "memefinder" as opposed to an aggregator. It uses OPML subscriptionlists to help filter information based on what you and your friends areinterested in -- and he's working on getting some kind of automaticsync-up going. Seems like this would benefit from Ray Ozzie's Really Simple Sharinginitiative. There's a problem here, though -- the whole point ofthis is that you don't have to explicitly subscribe to feeds, but ifnobody explicitly subscribes to feeds, where will the interest datacome from?
Now, I really like the concept of mobile.tailrank.com. I really don't want to manage a set of subscriptions for my mobiledevice and it really can't handle the set of subscriptioins I have onmy desktop. But something that automatically filters interestingnews, with input from my desktop subscriptions, seems like a naturalwin for a mobile service.
Oh, and we had a smooth and uneventful Journals update this morning. Fortunately for Joseph the Intern.
OK, so now for the geek update. The character set encodingissue? Well, basically, the major technical update in thisrelease involved moving to a new web server and servlet engine(Tomcat). Unfortunately, we discovered too late that Tomcat bydefault decides that HTML form data is encoded in ISO-8859-1. Also unfortunately, Journals uses UTF-8 throughout. For most commonEnglish characters, the two encodings give the same bytes; it's whenyou start speaking French (or talking about your re'sume') that you runinto differences. So the problem here is we didn't test thisenough after the switchover and got caught by surprise. Thesolution involves setting the encoding to UTF-8, but doing it in theright place is a bit of a problem -- if you set it AFTER the servletengine starts reading stuff, it ignores you. Personally I thinkit should throw an exception if this happens since encodings are, well,kind of important, as we've demonstrated over the past couple ofweeks. In any case, the solution we're looking involves a servlet filter similar to this one.More generally, we need to figure out how to add this as a general,automatic test so that it's just not possible to skip it -- and so thatwe'll be alerted within hours if some other configuration change breaksthings, hopefully weeks before we make that change to the liveproduction site.
Elwood:It's 106 miles to Chicago, we've got a full tank of gas, half a pack of cigarettes, it's dark and we're wearing sunglasses.
The interesting thing (from our perspective) is that the change waspushed out first to beta.journals.aol.com, and it works fine there. Which means that if you want to see a preview of the change, you canview your blog on beta (use "beta.journals.aol.com" instead of"journals.aol.com" in the URL) and take a look. My personalopinion? Might help a little, but we need to do more. (Therelease also includes a fix that will, hopefully, resolve the entrysaving problem for anyone who still has it.)
In other news, the Washington Post story "You've Got Ads" came out this morning. Some reactions from the blogosphere are here. The press release from AOL got some facts wrong about ads on bloggingservices; I can't comment beyond that since that's an officialcommunication and this blog is highly unofficial. But,when AOL issues a press release that says the sky is green, I don'tthink it's against our communications policy to simply note that,looking out the window, the sky looks awfully blue to me.
I was never happier to be a part of this than I was last Friday, when Igot the chance to be guest editor. In the span of a weekend, Iheard from a lot of people that I didn't know before, and discovered aton of creative journals that I did not know existed. And then,just two days later, it all disappears, thanks to the inconceivable waythat the higher ups of this company thought they could just walk allover us. Unbelievable. I have never encountered such aswing, from high to low, in such a short time. It's incrediblysad for EVERYONE. And for the life of me, I cannot fathom how NOONE at AOL has the decency to at least address the situation. What are they waiting for? The damage has already beendone-there are folks that won't be coming back even if the adsdisappear now. -- Jim
Personal opinion, as a blogger? The ads suck. The communication aboutthe ads? Not so good. And the release problems? Alsonot our finest hour. So, I'm feeling pretty down overall.
Now then... Given that the situation is what it is, what can we doabout it? A dialog would be good. People are commenting on Joe and John's blogs andgrouping and writing petitionsand emails, which is great. I'd suggest oneadditional thing: Post your opinion on your blog. That'swhat they're for, right? And when you do, one more technicalsuggestion that might possibly help with the dialog. Tag yourpost by adding this snippet at the end:
Tag: AntiJournalsAdsWhat this will do: When you click this link, you'll see a list of allblog entries and other stuff tagged the same way. More to thepoint, anyone at AOL can do the same thing and see what people aresaying in one place. Note that you don't have to use Journals tomake this work.
(If you choose Viewas [HTML], you should see this: <a rel="tag"href="http://technorati.com/tag/AntiJournalsAds">AntiJournalsAds</a>.)
I'm assuming here that the posts are actually anti-ads; if you want topost in favor of them, feel free to create a ProJournalsAds tag. I'm not holding my breath.
Aside from that, we are all working to get your feedback to the rightpeople. We'll see what happens. Personally, I'd love to dosome revenue sharing between content creators and us; I think this is acase where everybody could win by taking smaller pieces of the piewhile growing the pie. That won't happen quickly, though, for technical reasons.
Update: We're sending a posse to TagCamp:
EdwinAoki, SaileshDavuluri, SeanSu - Brainstorming ideas around tag spam, or SPAG.
And, we're helping outwith dinner too. Wish I could be there... I might manage a dropin at some point. I hope Edwin or Sailesh or Sean will be eventblogging.
Tags: TagCamp, SPAG.
Some of the more relevant / useful links:
Dave Sifry's reaction: Google's entry validates the space.
Bob Wyman welcomes Google Blog Search because it complements PubSub. Though I think I'm a bit fuzzy on exactly what the distinction is.
Threadwatch has some technical details.
Commentary on Technorati vs. Google from WebProNews (Charlene Li's take).
(Next step: Defining the general Atom protocol standard, which willenable interoperable use of Atom for things like blog editors.)
Cool new beta feature in AOL Explorer (http://beta.aol.com/projects/aolexplorer/index.html?): The Journals side panel. I'm posting this from AOL Explorer right now. Very nice.
This version lets you drag and drop selected text from the page you're viewing in the main browser tab. Really handy for commenting on things!
(The big question is, how long will we be waiting for Longhorn?)
On a side note, I've been behind on blogging and missed congratulatingTechnorati on their cool new look & features. I managed toshow their new consolidated tag searchto an executive yesterday -- searching for tags popped up not onlyposts, but photos from buzznet and flickr. It was a great way topoint out the utility of interoperability.
Kevin made a good point about cognitive load. The cost ofapplying a tag needs to be near-zero. The iPhoto keywords featureis a great anti-example.
The ecosystem is jumping all over tags. LiveJournal added supportfor tags last week. The Mac "ecto" tool now has tag support aswell. Oh yes -- upcoming.org does hCalendar; evdb does hCalendarand hCard. Note to self: Check all these out soon.
I do think people are waving their hands a bit around authorization andauthentication, especially when Tanenbaum talks about an ecosystem ofservices. Do I just give all these services all of my usernamesand passwords? How do I know I can trust some of these littlefly-by-night web services with my private information? Also,Marty, please, please don't curse this by invoking AI.
In the future, I'll Google "concerts in the next week" and get not justwebsites but a consolidated, sortable list of events from all sources.
Best comment of the session (rough quote) from John Seely Brown: "You're doing pragmatics as well as semantics and that's why you'llwin."
What I like about microformats: Start simple and focused. Evolve rapidly. Borrow like crazy. Keep things humanreadable. Decentralize completely. Get real worldexperience. Microformats like tags, hCalendar, and hReview are simple enough (and built oninfrastructure that's solid enough) to let the community buildinteroperable services.
Best part for users: Microformats are based on XHTML. Whichmeans they're human readable HTML as far as users are concerned. No weird XML gobbledygook, no strange attachments, no extra files tocart around.
Specifics: hCalendar is great because it's just vCalendar mappedto XHTML. There was a great demo of a service which turns anhCalendar link into an vCalendar data stream automatically; I'm nowsubscribed to Tantek's calendarthrough this service. hReview is based on what people are publishing onthe web today, just adding some markup so machines can see thesemantics.
Tools are starting to pop up. There's a Greasemonkey script fordoing hCalendar in any text box. Movable Type is adding supportfor writing hReviews. Next step will beservices like Technorati and Google paying attention to the semantics.
Next topic was tags, the uber-microformat (or nanoformat). It'llhave to wait for the next post, though. Need to get some sleep.
I went to Monday's Connected Work workshop mainly in hopes of gettingsome insights into collaboration trends. Not too many surprises-- blogs and wikis everywhere, of course. Some good pointsabout the need to not lock down things too tightly (heresy totraditional IT departments) because your breakthrough ideas usuallycome from cross-fertilization. Quote: "98% of everything shouldbe visible to everyone in the company." Hear, hear.
If you're in the top 1% of coders, maybe you can get away with this. Otherwise, please run a spell checker on your resume before sending it in.
(I'm a really nice guy so I finished reading the resume; the rest was just as bad, though.)
I figure I'm somewhere in the middle of the X-List.
And yes, I think the Blogebrity Swimsuit Edition would be a really bad idea.
"Feedfestis a six-month online multimedia series focused on the increasinglydynamic and powerful content syndication applications that are allowingpeople to consume what they want, when they want, where they want andhow they want. Launched last year as “RSS Winterfest”, the re-namedevent will feature interviews with the thought leaders who are shapingnew ways for content to be published and consumed. This year’s programhas expanded to include other syndication formats besides RSS, and willalso explore the growing syndication of audio and video as well."
Looksinteresting, though I am wondering: Why six months? Do RobertScoble, Steve Gillmor, Bob Wyman, & co. hibernate for the other six?
Note that the proposal also allows servers to require authenticationfor comments -- something that would be a helpful building block infighting comment spam.
Dave cut the Gordian knot involved in defining service orientedarchitecture ("the debate is both endless and pointless") by statingthat it's defined by the dominant technologies: A service is what thedominant products say it is -- and WebSphere and .NET are the dominantproducts, so services means SOAP and WS-*. And I'm not sure, but Ithink he defines 'dominant products' as 'whichever platforms have themost market share among vendors selling tools to enterprisedevelopers'. Which of course rules out anything that doesn't help sellplatform tools :^). I glance at the Internet, which is mysteriouslyworking again, and verify that Dave Chappell is an old-school DCOMguy. He seems very happy that the vendors are finally agreeing on ashared standard for communication; after the CORBA/DCOM/RMI wars, Iimagine so.
He did have some useful points to make about moving to SOA within anorganization, identifying two major approaches: Top down, in which youidentify business needs, document requirements, design an architecture,and implement the services in a well planned, sensible way. The prosare that this is elegant, clean, and sensible; the cons are that it's(nearly) impossible. Requires high investment and long-term businessbuy-in. He recommended the bottom-up approach (just build one service,then another, then start thinking about central SOA issues such assecurity and management) as a practical if ugly approach.
He presented a toy example using C# code. Now, his main points wereabout the orthogonality of OO design and service architectures, whichis all well and good. But I felt that the choice of an example classwith "add(x,y)" and "subtract(x,y)" methods which get turned into webservices sort of obscures the question -- why would we want to dothat? It's a ridiculous web service. Why not pick a toy example thatactually makes some tenuous sense as a web service? For example,a word definition lookup service?
In the short Q&A period, one person asked the obvious question: What about the REST-ish approaches that so many service providers suchas Google, Yahoo!, etc. are using to expose services? Dave's answerwas somewhat revealing, but as a tourist I'm not sure I can properlyinterpret it. He said, #1, web services are defined by SOAP and WS-*because that's what the dominant vendors say; and #2, he doesn't "getinto SOAP vs. REST debates because the REST community..." and there hepaused, and looked thoughtful, and then reiterated "I don't get intoSOAP vs. REST debates". He sure seemed uncomfortable to me.
(Side note: My spell checker suggests "DOOM" as an appropriatesubstitute for "DCOM". Sometimes I think it's really acquired AI and it's just toying with me.)
Lots of good advice and pointers to resources in the talk. He had somevaluable points regarding the different views of what a 'requirement'is to different stakeholders. He presented a frameworkfor separation into business (why), user (what), and functional(high-level how) requirements, and how to categorize requirements intothis framework to help avoid confusion. This becomes particularlyimportant when doing incremental development (which is what almosteverybody does): It's OK to be fuzzy on some of the functionalrequirements before starting a project, but the business requirementshad better be very clear and solid.
Regarding change control boards, I asked how one can scale a CCB so itdoesn't become a bottleneck in a large program. He said (interpretinga bit) that the way to scale a CCB is to identify policies so that youcan distribute responsibilities among CCBs -- only escalating changerequests up to a central CCB if its scope truly warrants it.
The slightly depressing part about this talk was that I knew most ofthe solutions presented; however, none of them helped to solve thereally hard people problems that actually are the root cause ofmost requirements issues.
On a side note, the wireless network stopped working for me during thistalk. I started seeing packet round-trip times of >>1sec to reachwhat was supposedly our DNS server. I think this highlights one of thenonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Centernetwork: When you build a wireless network for a convention center inthe middle of Silicon Valley, make sure that it can handle a fewthousand software engineers with laptops!
Quick takes: Mike stated that UDDI is not used much outside thecorporate firewall (my personal prediction: It never will be in itscurrent form.) IBM and MSoft are repurposing existing applications,such as Tivoli, to help manage corporate web service networks. I askedabout interoperability; monitoring and development tools based on oneof the "big two" platforms will have a difficult time interoperatingwith the other, though the web services themselves should be able torun on either platform with "some data mapping."
The most interesting statements: Dave Chappell mentioned after the talkthat things like security will only have shipping implementations in2006 and reliable messaging doesn't have a final spec yet. Also, on atotally random tangent, I overheard someone behind me saying "XSLTmakes all those lies about 'you can do anything with pointy brackets'true!".
Fortunately, Journals provides a way to both delete a comment and blockthe commenter's user id (screen name) from future comments to thatJournal, which is handy in these situations. But perhaps itdoesn't go far enough. Perhaps there should be anauto-blacklisting feature: If enough different peoplecomment-block a user id, perhaps it should be blocked from any furthercomments anywhere for a significant period of time. It would atleast slow down the spammers.
So AOL Journals plans to support the initiative to make at least one form ofcomment spam ineffective -- the rel="nofollow" attribute. The idea is that this would be honored by search engines such asGoogle, and would mean that these links wouldn't count towardsincreasing the page rank of the target. So, this form of spamwould be rendered useless immediately. Of course, other formswould still persist, but I say it's better to light a candle than cursethe darkness. Or at least do both in parallel.
That's why the announcement of My MSN RSS aggregation with feed search is interesting; a My MSN aggregator, plus MSN Spacesmeans Microsoft can leverage both sides. So they could make itvery easy, for example, to subscribe to the RSS feeds for Spaces ownedby people who comment on your blog. Or do any number of otherthings which increase the value of being an MSN member. And,obviously, these tools still interoperate with the rest of theblogosphere (note that Spaces has had RSS feeds since launch).