Web 2.0 Stores > Fast, Simple, Search Engine Friendly Ecommerce

We spend so much time looking at web-applications these days that we tend to ignore desktop apps. Still, every once in a while there’s room for pleasant surprises, and today was one of those days with the release of CSS Edit 2.5 (by Macrabbit) and Coda (by the guys at Panic). I guess it is a little weird to be singing praises to desktop applications when it is a known fact that access-anywhere is the killer feature, but even with Ajax or RIA environments like Flex, there’s (at this point) no way to get the same kind of “gratification” from web-apps. The web still doesn’t manage to compete with the responsiveness and the constant look and feel of a great desktop application. This is unfortunate, and although changing at a rapid pace, its just not there yet. (more...)

Google this week announced the release of the Google AJAX Feed API. What is it? It’s a JavaScript library that lets you mashup RSS and Atom feeds entirely on the client, thus no need for server-side coding. In addition, one of the useful core features is that it can automatically map XML attributes to a JSON result format. To get a sense of what it can do, one of their example mashups has been added to our listings: the Google AJAX Tune Bar that lets you add iTunes RSS feeds to any page. If you’re familiar with JavaScript programming you’ll note that typically this sort of client-side mashup would have some limitations due to browser security constraints restricting data to only come from the same server a given page was delivered. But Google works-around this by having their servers act as a proxy cache for all feed requests made via the API. Which leads to a couple of other implications: “The AJAX Feed API, like Google Reader and the Google personalized homepage, caches individual entries within feeds and reconstructs feeds based on those entries. Consequently, feeds from the AJAX Feed API may not reflect the exact XML file from the URL you request. In many cases, you can request more entries from the AJAX Feed API than are currently available in the live feed.” It is also interesting that we’re seeing more JavaScript-based APIs from Google, including the AJAX Search API and the ever-popular Google Maps API. We’ll probably see more in the future given that they’ve introduced a new base url of google.com/jsapi and a generalized JavaScript API load process: “Loading the API requires two steps because Google is moving to a new model of loading AJAX APIs to make it easier to include multiple Google APIs on your pages. Subscribe to the Google AJAX APIs Blog for announcements as we start rolling out this new AJAX API loading mechanism.” This is one of those very useful but somewhat subtle APIs that has more power than may be initially apparent.

The Google AJAX API team has announced a genuinely useful Feed API that gives an Ajax developer the ability to access feeds, cached in the fast Google edge cache where appropriate, from across the web using a simple JavaScript API. This is a subtle service that does one thing that is currently a pain-point for developers of certain applications. Ajax developers now have a clean way to access public feeds on any domain, and get access to the content in a uniform way. Gone is the need for us to create a proxy on the server to access feeds from other domains. Gone is the need to have to deal with all of the feed types. RSS, Atom, RDF, we can now use either MIXED_FORMAT or JSON_FORMAT to use the uniform access. The full set of feed formats supported is Atom 1.0, Atom 0.3, RSS 2.0, RSS 1.0, RSS 0.94, RSS 0.93, RSS 0.92, RSS 0.91, RSS 0.9. The unified feed result elements are: title, link, description, author and a list of entries[]. The entries[] list has the following elements: title, link, content, contentSnippet, publishDate, and categories. XML and mixed formats allow you to also get access to the XML document itself, and then you can use standard DOM tactics to get what you want from that content (e.g. getElementsByTagName). You would want to use XML if you needed to grab out something specific from the feed, such as the digg:count. RSSBling Redone Funny story. Ben and I created Ajaxian.com as a place to host RSS Bling back in 2005, as you can see via the Wayback Machine. It was only later that we started the blog. RSS Bling was an offline RSS reader that we create as an example of doing offline and Ajax before it was cool. We got a lot of mileage out of doing presentations and unplugging the net and seeing that it still worked. One of our problems was getting access to feeds. We could have created a proxy to feeds, but instead we used bloglines as the proxy, and got the data from there. With the new Feed API we can go directly to the feeds itself. We ported RSS Bling to use the API, and you can view it here. Once you load the Feed API, you can grab a feed using google.feeds.Feed, passing in the feed URL, setting any values on it (e.g. the mode to use, how many entries you want in the result size, etc.), and then calling load(callback). The callback allows the API to grab the feed asynchronously, and holds the result itself. Here is an example from RSS Bling that loads a feed and shows the entries in the main window: I am really looking forward to seeing how the API is used. For more infomation you can visit the Ajax Feed API home or check out the FAQ.

If you’re interested in developing with any of the many Google APIs, you may want to mark May 31st on your calendar. That’s when Google is hosting their Google Developer Day 2007 in ten cities around the world. It gives you a chance to meet the Google developer product teams, maybe learn more about GData, KML, or, just tell Google what you want. Highlights by location include:

• In Beijing: Guido Van Rossum, creator of the Python programming language, now Google engineer
• In London: Chris DiBona, Google open source programs manager
• In Tokyo: Google engineering manager and Apache Software Foundation chairman, Greg Stein
• In Madrid: Google data APIs technical lead Mark Stahl
• In Sydney: Google Maps senior engineer Lars Rasmussen

Being a blogger for quite a few years I couldn’t help but read Tim O’Reilly’s post about a Code of Conduct for bloggers, following the Kathy Sierra incident that flooded TechMeme with outrage (and rightfully so) with the preposterous personal threats against Kathy. And having read and thought about it, I decided not to write about the proposed Code of Conduct because honestly I knew others would do a great job of dissecting it first. But there’s a couple of ideas that I feel are important to bring up at this point: Blogging is about community, and any community has bad seeds. This is one of the consequences of being human - you are bound to have people disagree with you, dislike your work and diss your efforts. Not being “right” for everyone is what makes you strive to become better every day. Just imagine a world where no one would voice their opinion against you - perfect, right? Wrong. This makes it easy to assert that yes, anonymous comments are wrong or to be frowned upon, but it doesn’t necessarily mean they shouldn’t be accepted. People do feel more comfortable speaking their minds about certain things if they do it anonymously - again it is only natural. There’s obviously a big line between an opinion and a threat, and here naturally common sense applies. It is the nature of the blogosphere to be “unmediated” (remember the whole “We are the media thing”?), and a Code of Conduct only serves as an excuse for traditional media to discredit both bloggers and those who read blogs. Naturally rules apply to blogs - but those should only be the rules upon which society itself is based on. The blogging community doesn’t all move in the same direction, and that’s the beauty of it. There’s no need for a formal ruleset to control the tide. This is obviously a philosophical question and not a moral question. We all understand when lines are crossed and action must be taken, but isn’t trying to regulate something that excels in (well,) entropy and unmediated growth a little too “weird”?