Aehso’s Output

I completely agree with Brad and Fred – Alex Iskold’s The Structured Web and Facebook: What If More Is Less? contain some great concise analysis of the how the web and the networks within it are evolving.

Well worth a read if you’re looking for some food for thought and can spare 10 minutes….

aehso atom, blogging, rss, social, web services, web2.0, xml

Wonderful post (and followup) by Steve Vinoski, spawning lots of other discussions.  I should be surprised by some of the comments but… I’m not – I suspect agendas, pride and reputations may be at play.  Imho, and I stress humble opinion, his views are completely valid. Can enterprise architects disregard the architecture, constraints and protocols that helped the Web scale and adapt to be the global platform it is today?  If they want to build something that will adapt and scale then I also think the answer has to be No.

Platforms like ESBs were built to solve the problem of interconnecting and integrating enterprise systems. The disconnect between how an ESB-based or RESTful solution approach the same problem can mostly be explained by the fact that they both evolved from very different starting points, and therefore have very different principals at their core. 

ESBs, having evolved from DCE-RPC, CORBA based RPC architectures, have always required static definition of non-uniform remote interfaces.  The modern WS-Deathstar-type ESBs are still based on this concept, with WSDL interface typically backed by statically compiled implementations (or if you are exotic XML based mediation languages).  The remote interface semantics can be augmented by a variety (cluster f&@k?) of ‘enterprisey’ features like transactions, routing and reliability defined by a collection of related specifications but it turns out that implementations based on some of those specifications do not interoperate or scale.  This is primarily a function of questionable specification development processes and over complexity.

In the end the non-uniform interfaces at the heart of these solutions tightly couple the clients and servers and this coupling is the underlying limiting factor on the adaptability and extensibility of these systems.  I still really struggle to find a successful real world internet-available IDL or WSDL based web service that has been used in a series of completely unexpected contexts (i.e. mashups) or that has evolved beyond more than one or two revisions without completely breaking backward compatibility for old clients.

In parallel the RESTful HTTP standard emerged and provided the platform for the Web that has scaled and adapted to truly global proportions.  This wasn’t an accident – the Web succeeded because of the RESTful principals upon it was built – stateless, client server, layered systems that support caching and of course the true use of Hypertext As The Engine Of Application State (thankfully now referable to as ‘the hypertext constraint‘).  To me HATEOAS is the most critical feature of RESTful solutions. It is the one feature that negates the need for non uniform interfaces and it is here where the two approaches diverge dramatically.  It also isn’t an easy concept to grasp for folks who are used to traditional RPC oriented systems. 

Regardless, the recent emergence of dynamic languages like Python and Ruby, and their respective web application frameworks, Django and Rails, is now making it economically efficient for anyone to produce RESTful web services that can scale and that are reusable.  Steve is just expressing his opinion that this approach works better.

Don’t get me wrong – the ESB approach has been proven to succeed and
scale but primarily in limited deployment environments and usually only when considerable resources are thrown at the solution.  To put it another way, the inherent limits in non-uniform interface based systems can be pushed through use of sophisticated tools and language bindings but this only be achievable when considerable resources are thrown at the solution.  I think this is what Steve is getting at – I don’t think Steve is saying ESBs are “bad”, just that they are not the best platform for building internet scale services/resources

(Hey, check it out, I didn’t mention SOA once!)

BTW, I’m reading The Future Of Ideas at the moment, hope to write more about that soon, but it does relate to the notion of control mentioned in Steve’s latest followup post.

aehso architecture, atom, django, enterprise, esb, internet, python, rails, rest, rss, ruby, sca, soa

Great to see Wordpress 2.3 shipping with support for Atom 1.0 and APP (draft 17 compliant I’m guessing). I haven’t updated this blog yet (for fear of borking plugins/themes that I have enabled) but from playing with a local test install this afternoon I see Wordpress now publishes the following feed URLs out of the box:

1. <wordpress-root-URL>/?feed=atom – Atom 0.3 format feed
2. <wordpress-root-URL>/?feed=rss – RSS 0.92 format feed
3. <wordpress-root-URL>/wp-app.php/service – APP Service
4. <wordpress-root-URL>/wp-app.php/posts – “Wordpress Posts” APP collection feed
5. <wordpress-root-URL>/wp-app.php/categories – “Wordpress Posts” APP category document
6. <wordpress-root-URL>/wp-app.php/attachments – “Wordpress Media” (attachments?) APP Collection

I am a little curious about why the HTML doesn’t contain a <link> for 4 though – its absence makes it kind of difficult to auto discover the collection feed URL. I’m also curious why both 1. and 4. exist. I always assumed that the APP collections would just point to the real Atom feed URL, with APP clients authenticating to send HTTP POST, PUT and DELETE requests. Was this necessary because of bad feed readers/aggregators or was my assumption just plain wrong?

Update: Sam Ruby has some good commentary, doesn’t answer my question though…

aehso api, app, rss, wordpress

I have been quiet haven’t I!  The recent blogging hiatus was for two very good reasons though – I went on vacation to the US with Aine (hi sis!) and since getting back I’ve been up in Sligo meeting the good folks at Nooked whom I’m joining as their new CTO. 

Exciting times ahead, Nooked already have great products but they also have the vision and plans to deliver a truly disruptive feed commerce platform – more on that later.

This is going to be great!

aehso atom, nooked, rss, web2.0

Speed up feed reading with Google Reader by learning a couple of simple keystrokes to avoid ever reaching for your mouse:

Lather:

• Open Google Reader
• Shift-n – Selects your first folder (or feed)
• Shift-o – Opens the folder (or feed)
• 2 – Switches to the (abbreviated) entry list view

Rinse:

• <space-bar> – Expands the first/next feed entry
• j, k – Expands the next or previous feed entry
• n, p – Selects the next or previous feed entry
• o – Expands/collapses the current feed entry
• v – Opens current entry URL in a new tab or window
• s – Stars the current entry
• Shift-a – Marks all unread feed entries as read

Repeat:

• Shift-n, Shift-o – Select & open next folder/feed

Help:

• ? – Opens a popup keyboard shortcut guide

See, no need to use the mouse!

aehso atom, google, rss

This should be an easy one for Google to fix but it’s still borken. Since the weekend, Google Mobile Reader on Opera/N800 is failing to render the home page with the following error:

XML parsing failed: xml processing instruction not at start of
external entity (Line: 5, Character: 0)

The offending page content reads as follows:

<!--
Content-type: Preventing XSRF in IE.

-->
<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd"><html
xmlns="http://www.w3.org/1999/xhtml"><head><itle>Google
Reader</title>
<meta http-equiv="content-Type" content="application/xhtml+xml;
charset=UTF-8" />
<style type="text/css">
...

Err, why is there a comment before the XML declaration? If this is supposed to be valid XML it shouldn’t be there. I’m surprised the various other mobile platforms are forgiving enough to ignore this (or is it borken on them too and nobody has noticed?). Please Google, fix your XML.

(discussion ongoing here)

aehso atom, google, rss, xml

Google Reader is now using Google Gears to enable offline reading of your 2000 most recent items.  Check the top right corner of your reader for a new ‘Offline’ button to trigger installation.

Ars (and lots of other sites) have the user details, check out the Gears API Developer’s Guide for more info on the implementation.

It’d be fantastic if they did a version for Opera(or Minimo)/OS 2007/N800!

aehso atom, google, rss, web2.0

I was trying to use Google Reader on my N800 at the weekend and it just didn’t work well enough to be usable. The page layout and text size really isn’t suited to a 800×480 display, I was scrolling far too much to reach important buttons/links and some of the AJAX controls (such as the tree nodes) just did not seem to react to touchscreen input.

However Google Mobile Reader has more than saved the day. This stripped down version of reader is designed primarily at mobile phone handset users, but it works very well on the N800.

The main page, once logged in, shows the ten most recent posts with convenient page-forward and mark-as-read-and-page-forward links:

The Subscriptions page is simplicity itself – a flat list of feeds, with feeds that contain new posts at the top of the list.

Each Feed page (http://www.google.com/reader/m/view/feed%2F<HTTP-encoded-feed-URL>) is almost as simple but with one line of the entry body under each item, and additional navigation/mark links at the bottom:

Each Entry page (as above with additional query string) is also simple, with convenient links to see the original feed entry page, along with links to star, mark as read and move to next.

Note my recurring use of the term ’simple’. In this environment, simplicity really does win the day and in this case it adds up to a very usable service. The fact that it is perfectly synchronized with my laptop feed reader is a significant plus. I left NetNewsWire behind a long time ago because I just couldn’t coordinate reading sessions across my home mac and my work pc. This is really another type of client that I want to read the same data access the same service with.

And then I noticed that they have a custom Google Reader for the Wii too, with bonus Wiimote integration! It is going to take a lot to get me to ever switch to a different feed reader.

aehso atom, google, n800, rest, rss, web2.0

It is odd isn’t it. Google have one of the best online feed readers on the market but it has absolutely no search capability. Zero, nada, no way to keyword search through the entire history of the feeds that I subscribe to. That is just plain wrong for a Google product. Every time I try find an old post I end up switching to the Google Blog Search but that does not restrict result to feeds I have subscribed to with Google Reader.

What a mess. But apparently Google realise that it is a mess. Poor Microsoft, trying to bully their way into search, are making a bigger and far more extensive mess.

aehso blogging, rss, search

I switched from Bloglines to Google Reader a while back for the various reasons already expounded by many ex-Blogliners. That said, Google Reader still isn’t perfect for me, and I sometimes think about switching back. Two things are bugging me:

• I have (many) feeds organized in various hierarchical folders and I routinely switch between the Expanded and List View during each session, depending on how feed items are unread. When doing a “bulk-catch-up” of all the items from several feeds in a folder I find it incredibly difficult to quickly scan over the chronologically ordered list of items. Does anybody else find context switching from feed to feed while scanning the item titles mentally taxing? I’d love an option to sort controls in the list table header, then I could do “”Sort by feed, then chronologically” and relax my brain a little. I know can get individual lists by jumping from feed to feed but I want to have my cake (one big flat list) AND eat it (scan item titles without incessant key pressing/clicking).
• The List View paging implementation is a bit slow isn’t it? Sometimes I want to skip over a whole bunch of items but I get stuck waiting a few seconds for the “Loading the next 20 items…” AJAX request to be completed. How about prefetching the next 20-40? Meanwhile my list scrollbar is always visually the the wrong size and in the wrong location. Invariably, I am not at the end of a short list as it usually indicates. In fact, I generally do not know if I have scanned over the complete set of entries without checking to see if it trying to “Load the next 20 items…” again. And what is it doing pinging all of those feed URLs while loading? I would have thought the great Google “sharks with frickin’ laser beams” back end could easily cache and supply the feed entry titles, and descriptions, maybe sending off AJAX requests to the original feed whenever I move my mouse over/near a list entry (if it needs to get enclosures etc.)

Anyhoo, rant over, if anyone has any tips, I’d be more than appreciative…

aehso google, opml, rss