March 15, 2004
@ 04:35 PM

It what seems to be the strangest news story I've read this year I find out Sun snatches up XML guru what I found particularly interesting in the story was the following excerpt

One of the areas Bray expects to work on is developing new applications for Web logs, or "blogs," and the RSS (Resource Description Framework Site Summary) technology that grew out of them. "I think that this is potentially a game-changer in some respects, and there are quite a few folks at Sun who share that opinion," he said.

Though RSS is traditionally thought of as a Web publishing tool, it could be used for much more than keeping track of the latest posts to blogs and Web sites, Bray said. "I would like to have an RSS feed to my bank account, my credit card, and my stock portfolio," he said.

Personally I think it's a waste of Tim Bray's talents having him work on RSS or it's competitor du jour, Atom, but it should be fun seeing whether he can get Sun out of it's XML funk as well stop them from spreading poisonous ideas like replacing XML with ASN.1.

Update: Tim Bray has a post about his new job entitled Sunny Boy where he writes

That aside, I’m comfy being officially a direct competitor of Microsoft. On the technical side, I find the APIs inelegant, the UI aesthetics juvenile, and the neglect of the browser maddening.

Sounds like fighting words. This should be fun. :)


 

Categories: XML

My homegirl, Gretchen Ledgard (y'know Josh's wife), has helped start the Technical Careers @ Microsoft weblog. According to her introductory post you'll find stuff like

  • Explanation of technical careers Microsoft.  What do people really do at Microsoft?  What does a “typical” career path look like?  What can you do to prepare yourself for a career at Microsoft?
  • Sharing of our recruiting expertise.  Learn “trade secrets” from Microsoft recruiters!  What does a good resume look like?  How can you get noticed on the internet?  How should you best prepare for an interview?
  • Information on upcoming Microsoft Technical Recruiting events and programs. 
  • I hope Gretchen dishes up the dirt on how the Microsoft recruiters deal with competition for a candidate such as when a prospective hire also has an offer from another attractive company such as Google. Back in my college days, the company that was most competitive with Microsoft was Trilogy (what a difference a few years make). 

    I remember when I first got my internship offer and I told my recruiter I also had an offer from i2 technologies, she quickly whipped out a pen and did the math comparing the compensation I'd get at Microsoft to that I'd get from i2. I eventually picked Microsoft instead of i2 for that summer internship which definitely turned out to be a life altering decision. Ahhh, memories.    


     

    After lots of procrastination we now have online documentation for RSS Bandit. As usual, The current table of contents is just a place holder and the real content is Phil Haack's Getting Started with RSS Bandit. The table of contents for the documentation I plan to write [once the MSDN XML Developer Center launches in about a week or so] is laid out below.

    • Bandit Help
      • Getting Started
        • What is an RSS feed?
        • What is an Atom feed?
        • The RSS Bandit user interface
        • Subscribing to a feed
        • Locating new feeds
        • Displaying feeds
        • Changing the web browser security settings
        • Configuring proxy server settings
      • Using RSS Bandit from Multiple Computers
        • Synchronization using FTP
        • Synchronization using a dasBlog weblog
        • Synchronization using a local or network file
      • Advanced Topics
        • Customizing the Way Feeds Look using XSLT
        • Creating Search Folders
        • Adding Integration with your Favorite Search Engine
        • Building and Using RSS Bandit plugins
      • Frequently Asked Questions
      • How to Give Provide Feedback
      • Contributing to RSS Bandit

    If you are an RSS Bandit user I'd love to get your feedback


     

    Categories: RSS Bandit

    I'm not sure which takes the cake for geekiest weeding proposal, popping  the question on a customized PC case or on a custom Magic: The GatheringTM card.

    Anyone else have some particularly geeky wedding proposals to share?


     

    It is now possible to use RSS Bandit to read protected Live Journal feeds now that they support HTTP authentication. Brad Fitzpatrick wrote

    Digest auth for RSS
    Aparently this was never announced:

    http://www.livejournal.com/users/USER/data/rss?auth=digest

    Get RSS feeds (including protected entries) by authenticating with HTTP Digest Auth. Good for aggregators.

    Good indeed. Given that I agitated for this in a previous post I'd like to thank the LiveJournal folks for implementing this feature.


     

    Categories: RSS Bandit

    I've written about this before but a recent mail from David Stutz and rumblings about slipped dates pushed this topic to the forefront of my mind today. If you have competition whose mantra is to ship "little components that can be combined together" and "release early, release often" is it wise to counter this with a strategy that involves integrating monolithic applications into even larger applications those multiplying the complexity and dealing with integration issues?

    On the one hand, no one can argue that the success of Microsoft Office isn't related to the fact that it is a suite of programs that work well together but on the other hand as David Stutz wrote in his farewell email

    As the quality of this software improves, there will be less and less reason to pay for core software-only assets that have become stylized categories over the years: Microsoft sells OFFICE (the suite) while people may only need a small part of Word or a bit of Access. Microsoft sells WINDOWS (the platform) but a small org might just need a website, or a fileserver. It no longer fits Microsoft's business model to have many individual offerings and to innovate with new application software. Unfortunately, this is exactly where free software excels and is making inroads. One-size-fits-all, one-app-is-all-you-need, one-api-and-damn-the-torpedoes has turned out to be an imperfect strategy for the long haul.

    Digging in against open source commoditization won't work - it would be like digging in against the Internet, which Microsoft tried for a while before getting wise. Any move towards cutting off alternatives by limiting interoperability or integration options would be fraught with danger, since it would enrage customers, accelerate the divergence of the open source platform, and have other undesirable results. Despite this, Microsoft is at risk of following this path, due to the corporate delusion that goes by many names: "better together," "unified platform," and "integrated software." There is false hope in Redmond that these outmoded approaches to software integration will attract and keep international markets, governments, academics, and most importantly, innovators, safely within the Microsoft sphere of influence. But they won't .

    Exciting new networked applications are being written. Time is not standing still. Microsoft must survive and prosper by learning from the open source software movement and by borrowing from and improving its techniques. Open source software is as large and powerful a wave as the Internet was, and is rapidly accreting into a legitimate alternative to Windows. It can and should be harnessed. To avoid dire consequences, Microsoft should favor an approach that tolerates and embraces the diversity of the open source approach, especially when network-based integration is involved.

    I don't agree with the general implication of David's comments but I do believe there is a grain of truth in what he writes. The issues aren't as black and white as he paints them but his opinions can't be written off either. The writing is definitely on the wall, I just wonder if anyone is reading it.


     

    Categories: Life in the B0rg Cube

    I hung out with Lili Cheng on Tuesday and we talked about various aspects of social software and weblogging technologies. She showed me Wallop while I showed her RSS Bandit and we were both suitably impressed by each other. She liked the fact that in RSS Bandit you can view weblogs as conversations while I liked the fact that unlike other social software I've seen Wallop embraced blogging and content syndication.

    We both felt there was more to social software than projects like Orkut and she had an interesting insight; Orkut and tools like it turned the dreary process of creating a contact list into something fun. And that's about it. I thought to myself that if a tool like Outlook allowed me to create contact lists in an Orkut-style manner instead of the tedious process that exists today that would really a killer feature. She also showed me a number of other research projects created by the Microsoft Research Social Computing Group. The one I liked best was MSR connections which can infer the relationships between people based on public information exposed via Active Directory. The visualizations produced were very interesting and quite accurate as well.  She also showed me a project called Visual Summaries which implemented an idea similar to Don Park's Friendship Circle using automatically inferred information.

    One of the things Lili pointed out to me about aggregators and blogging is that people like to share links and other information with friends. She asked about how RSS Bandit enables that I mentioned the ability to export feed lists to OPML and email people blog posts as well as the ability to invoke w.bloggar from RSS Bandit. This did get me to thinking that we should do more in this space. One piece of low hanging fruit is that users should be able to export a category in their feed list to OPML instead of being limited to the exporting the whole feedlist since they only want to share a subset of their feed. I have this problem because my boss has asked to try out my feed list but I've hesitated to send it to him since I know I subscribe to a bunch of stuff he won't find relevant. I also find some of the ideas in Joshua Allen's post about FOAF + De.licio.us  to be very interesting if you substitute browser integration with RSS Bandit integration. He wrote  

    To clarify, by better browser integration I meant mostly integration with the de.licio.us functionality.  For example, here are some of the things I would like to see:

    ·         Access to my shared bookmarks from directly in the favorites menu of IE; and adding to favorites from IE automatically adds to de.licio.us (I’m aware of the bookmarklet)

    ·         When browsing a page, any hyperlinks in the page which are also entries in your friends’ favorites lists would be emphasized with stronger or larger typeface

    ·         When browsing a page, some subtle UI cue would be given for pages that are in your friends’ favorites lists

    ·         When visiting a page that is in your favorites list, you could check a toolbar button to make the page visible to friends only, everyone, or nobody

    ·         When visiting a page which appears in other people’s favorites, provide a way to get at recommendations “your friends who liked this page also liked these other pages”, or “your friends recommend these pages instead of the one you are visiting”

    I honestly think the idea becomes much more compelling when you share all page visits, and not just favorites.  You can cluster, find people who have similar tastes or even people who have opposite tastes.  And the “trace paths” could be much more useful

    Ahhh, so many ideas yet so little free time. :)


     

    Categories: RSS Bandit | Technology

    March 11, 2004
    @ 04:54 PM

    Dave Winer has a proposal for merging RSS and ATOM. I'm stunned. It takes a bad idea (coming up with a redundant XML syndication format that is incompatible with existing ones) and merges it with a worse idea (have all these people who dislike Dave Winer have to work with him).

    After adding Atom support to RSS Bandit a thought crystallized in my head which had been forming for a while; Atom really is just another flavor of RSS with different tag names. It looks like I'm not the only aggregator author to come to this conclusion, Luke Huttemann also came to the same conclusion when describing SharpReader implementation of Atom. What this means in practice is that once you've written some code that handles one flavor of RSS be it RSS 0.91, RSS 1.0, or RSS 2.0 then adding support for other flavors isn't that hard and they basically all have the same information just hidden in different tag names (pubDate vs. dc:date, admin:errorsReportsTo vs. webMaster, author vs. dc:creator, etc). To the average user of any popular aggregator there isn't any noticeable difference when subscribed to an RSS 1.0 feed vs. an RSS 2.0 feed or an RSS 2.0 feed vs. an  Atom feed.

    And just like with RSS, aggregators will special case popular ATOM feeds with weird behavior that isn't described in any spec or interprets the specs in an unconventional manner. As Phil Ringnalda points out Blogger ATOM feeds claim that the summary contains XHTML when in fact they contain plain text. This doesn't sound like a big deal until you realize that in XHTML whitespace isn't significant (e.g. newlines are treated as spaces) which leads to poorly formatted content when the aggregator displays the content as XHTML when it truth it is plain text. Sam Ruby's ATOM feed contains relative links in the <url> and <link> elements but doesn't use xml:base. There is code in most aggregators to deal with weird but popular RSS feeds and it seems Atom is already gearing up to be the same way. Like I said, just another flavor of RSS. :)

    As an aside I find it interesting that currently Sam Ruby's RSS 2.0 feed provides a much better user experience for readers than his ATOM feed. The following information is in Sam's RSS feed but not his Atom feed

    • Email address of the webmaster of the site. [who to send error reports to]
    • The number of comments per entry
    • An email address for sending a response to an entry
    • An web service endpoint for posting comments to an entry from an aggregator
    • An identifier for the tool that generated the feed
    • The trackback URL of each entry

    What this means is that if you subscribe to Sam's RSS feed with an aggregator such as SharpReader or RSS Bandit you'll get a better user experience than if you used his Atom feed. Of course, Sam could easily put all the namespace extensions in his RSS feed in his Atom feed as well in which case the user experience subscribing to either feed would be indistinguishable.

    Arguing about XML syndication formats is meaningless because the current crop that exist all pretty much do the same thing. On that note, I'd like to point out that websites that provide multiple syndication formats are quite silly. Besides confusing people trying to subscribe to the feed there isn't any reason to provide an XML syndication feed in more than one format. Particularly silly are the ones that provide both RSS and Atom feeds (like mine).

    Blogger has it right here by providing only one feed format per blog (RSS or Atom). Where they screwed up is by forcing users to make the choice instead of making the choice for them. That's on par with asking whether they want the blog served up using HTTP 1.0 or HTTP 1.1. I'm sure there are some people that care but for the most part it is a pointless technical question to shove in the face of your users.


     

    Categories: XML

    I just read a post by Bruce Eckel entitled Generics Aren't where he writes

    My experience with "parameterized types" comes from C++, which was based on ADA's generics... In those languages, when you use a type parameter, that parameter takes on a latent type: one that is implied by how it is used, but never explicitly specified.

    In C++ you can do the equivalent:

    class Dog {
    public:
      void talk() { }
      void reproduce() { }
    };
    
    class Robot {
    public:
      void talk() { }
      void oilChange() { }
    };
    
    template<class T> void speak(T speaker) {
      speaker.talk();
    }
    
    int main() {
      Dog d;
      Robot r;
      speak(d);
      speak(r);
    }
    

    Again, speak() doesn't care about the type of its argument. But it still makes sure – at compile time – that it can actually send those messages. But in Java (and apparently C#), you can't seem to say "any type." The following won't compile with JDK 1.5 (note you must invoke the compiler with the source -"1.5" flag to compile Java Generics):

    public class Communicate  {
      public <T> void speak(T speaker) {
        speaker.talk();
      }
    }
    

    However, this will:

    public class Communicate  {
      public <T> void speak(T speaker) {
        speaker.toString(); // Object methods work!
      }
    }
    

    Java Generics use "erasure," which drops everything back to Object if you try to say "any type." So when I say <T>, it doesn't really mean "anything" like C++/ADA/Python etc. does, it means "Object." Apparently the "correct Java Generic" way of doing this is to define an interface with the speak method in it, and specify that interface as a constraint. this compiles:

    interface Speaks { void speak(); }

    public class Communicate  {
      public <T extends Speaks> void speak(T speaker) {
        speaker.speak();
      }
    }

    What this says is that "T must be a subclass or implementation of Speaks." So my reaction is "If I have to specify a subclass, why not just use the normal extension mechanism and avoid the extra clutter and confusion?"

    You want to call it "generics," fine, implement something that looks like C++ or Ada, that actually produces a latent typing mechanism like they do. But don't implement something whose sole purpose is to solve the casting problem in containers, and then insist that on calling it "Generics."

    Although Bruce didn't confirm whether the above limitation exist in the C# implementation of generics he is right that they have the same limitations as Java generics. The article An Introduction to C# Generics  on MSDN describes the same limitations Bruce encountered with Java generics and shows how to work around them using constraints as Bruce discovered. If you read the problem statement described in the article on MSDN it seems the main goal of C# generics is to solve the casting problem in containers.

    What I find interesting about Bruce's post is the implication that to properly implement generics one most provide duck typing. I've always thought the behavior of templates in C++ was weird in that one could pass in a parameter and not enforce constraints on the behavior of the type. Yet it isn't really dynamic or latent typing because there is compile time checking to see if the type supports those methods or operations.

    A few years ago I wrote an article entitled C++ in 2005: Can It Become A Java Beater?  in which I gave some opinions on an interview with Bjarne Stroustrup where he discussed various language features he'd like to see in C++. One of those features was constraints on template arguments, below is an excerpt from my article on this topic

    Constraints for template arguments

    Bjarne: This can be simply, generally, and elegantly expressed in C++ as is.

    Templates are a C++ language facility that enable generic programming via parameteric polymorphism. The principal idea behind generic programming is that many functions and procedures can be abstracted away from the particular data structures on which they operate and thus can operate on any type.

    In practice, the fact that templates can work on any type of object can lead to unforeseen and hard to detect errors in a program. It turns out that although most people like the fact that template functions can work on many types without the data having to be related via inhertance (unlike Java), there is a clamor for a way to specialize these functions so that they only accept or deny a certain range of types.

    The most common practice for constraining template arguments is to have a constraints() function that tries to assign an object of the template argument class to a specified base class's pointer. If the compilation fails then the template argument did not meet the requirements. 

    The point I'm trying to get at is that both C++ users and its inventor felt that the being able to constrain the operations you could perform on the parameterized type as opposed to relying on duck typing was a desirable feature.

    The next thing I want to point out is that Bruce does mention that generic programming in C++ was based on Ada's generics so I decided to spend some time reading up on them to see if they also supported duck typing. I read Chapter 12 of the book Ada 95: The Craft of Object-Oriented Programming where we learn

    In the case of a linked list package, we want a linked list of any type. Linked lists of arrays, records, integers or any other type should be equally possible. The way to do this is to specify the item type in the package declaration as private, like this:

        generic
            type Item_Type is private;
        package JE.Lists is
            ...
        end JE.Lists;
    

    The only operations that will be allowed in the package body are those appropriate to private types, namely assignment (:=) and testing for equality and inequality (= and /=). When the package is instantiated, any type that meets these requirements can be supplied as the actual parameter. This includes records, arrays, integers and so on; the only types excluded are limited types...

    As you can see, the way you declare your generic type parameters puts restrictions on what operations you can perform on the type inside the package as well as what types you can supply as parameters. Specifying the parameter as ‘range <>’ allows the package to use all the standard operations on integer types but restricts you to supplying an integer type when you instantiate the package. Specifying the parameter as ‘private’ gives you greater freedom when you instantiate the package but reduces the range of operations that you can use inside the package itself.

    So it looks like Ada gave you two options, neither of which look like what you can do in C++. You could either pass in any type then the only operations allowed on the type were equality and assignment or you could pass in a constrained type. Thus it doesn't look like Ada generics had the weird mix of static and duck typing that C++ templates have.

    I am as disappointed as Bruce that neither C# nor Java support dynamic typing like languages such as Python or Smalltalk but I don't think parametric polymorphism via generics has ever been used to solve this problem. As I have pointed out neither Ada nor C++ actually give him the functionality he wants so I wouldn't be too hard on Java or C# if I was in his shoes.


     

    Categories: Technology

    Sam Ruby writes

     Ted Leung: If I'm looking for thought leadership from the community, in the Java community, I'm looking towards the non Sun bloggers -- these are the folks doing AOP, Groovy, SGen, Prevalence, WebWork, etc. This shows the rich ecosystem that has grown up around Java. If I look at the .NET community, I pretty much look for the MS bloggers.

    Let's not confuse cause and effect here.  There used to be plenty of .Net bloggers who didn't work for Microsoft. 

    It seems Sam and Ted have different ideas of what thought leadership is from me. When I think of thought leadership I think of ideas that add to the pool of common practices or impact the way developers work and think. Examples of thought leadership are the ideas in the GoF's Design Patterns or the writings of Joel Spolsky.

    I read a lot of blogs from Microsoft and non-Microsoft people about .NET development and I see more thought leadership from non-Microsoft people than I do from Microsoft people. What I see from Microsoft people is what I'll term accidental thought leadership. Basically if I'm the developer or PM that designed or implemented component X then it stands to reason that I'm better placed to talk about it than others. Similarly if I'm one of the folks designing or implementing future technology Y then it stands to reason I'd be the best placed to talk about Longhorn/Indigo/Avalon/WinFS/Whidbey/Yukon/etc. Also the other thing is that it more interesting to read about upcoming future technology than it is to read about how best to use existing technology which is why people tend to flock to the blogs of the folks working on future stuff and ignore the Microsoft bloggers talking about existing technologies until they need a workaround for some bug.

    Personally, the only real thought leadership I've seen from the 200 or so Microsoft blogs I've read have come from folks like Erik Meijer and Don Box. I see a lot of Microsoft people blogging about SOA but to me most of them are warmed over ideas that folks like Pat Helland have been talking about for years. When I think of thought leadership in the .NET world I'm more likely to think of Sam Gentile or Clemens Vastersr than I am to think of some blue badge carrying employee at the Redmond campus.  

    What I do find interesting is that a Sun employee, Simon Phipps, is actually trying to use this to score points and claim that the lack of Sun bloggers with insightful posts is due to a "wide community as you'd expect from the openness of the JCP". When Microsoft folks weren't blogging and directly interacting with our developer community people railed because they felt the company was aloof and distant from its developers. Now we try to participate more and it is a sign that “it's a closed-source dictatorship - no amount of pushing up-hill will fix that”. I guess you can't win them all. :)  


     

    Categories: Ramblings