Month: August 2012

BazQux Reader – RSS reader that supports comments

One of the first start-ups that I participated in was an effort to create a better RSS reader.  It way back a few years, before Google Reader was even launched, and the best option you had was Bloglines, which in itself was horrible at the time.  One of the things that we were implementing was the support for comments in the blog posts and articles.  Even back then many blogging engines and content management systems (CMS) supported comment feeds.  Too bad the whole thing failed.

But even with quite a few upgrades to Bloglines, and launch and redesign of Google Reader, and, in fact, launch and development of many other RSS readers, support for comments is still a rare feature to see.  Recently, I came across a web-based RSS reader that promoted comments as one of its primary features –  BazQux Reader.

I tried it and it seems to work fine.  However, it’s still too fresh for me to move all my RSS subscriptions over there.  Especially considering the fact that you can only have 15 RSS feeds in the free demo.  A full featured yearly subscription is about 25 Euro.  I don’t mind paying that for a tool that I use many hours a day.  But after using BazQux Reader for a bit, I don’t think it’s quite ready yet.  Maybe one day.

P.S.: Oh, and if you were wondering what kind of a name is BazQux – it’s a combination of two metasyntactic variables “baz” and “qux“.  Sort of like “foo” and “bar“.  You probably won’t get it unless you are software developer of some kind.

10up – web development & strategy for WordPress

10up – web development & strategy for WordPress

There are so many cool companies around WordPress and love each and every one of them.  They push the boundaries of web development, expand the community, contribute back to WordPress, and simply inspire.  Have a look at 10up, for example.

We imagine, create, and grow amazing web experiences with WordPress.

Make sure to check their WordPress plug-ins page.

Tropic Thunder Promo

[youtube=http://www.youtube.com/watch?v=1czvD3aVk8Y]

This is old, but good.  Just in case you missed it when it originally came, watch it now.  Not only does it promote the “Tropic Thunder” movie, but it provides a valuable introspective into social media and the younger generation.  Lots of laughs too.

On using third-party APIs

In the few jobs I had, I was responsible for creating a new system and integrating it with some other systems.   The variety of the systems is pretty much irrelevant – anything from back office systems and CRMs to trading platforms and CMSs.  The common factor between them is the integration is often done through some form of the API.

The most important lesson I’ve learned while working with third-party APIs is this:

Never ever use a third-party API directly from your application.  Instead, create an abstraction layer between your application and third-party API.

This might seem like a bit of extra work, but, trust me, it’s not.  It will save you plenty of time and frustration.  Here are my reasons:

  1. Your own abstraction layer will help smooth out API’s edges.  If you are using third-party API, chances are, it feels weird at times.  It doesn’t matter what sets you off – function names, or required obvious parameters, or maybe the logic or order of calls that you have to make.  Instead of getting annoyed every time, you can abstract all that weirdness into a separate layer, which will probably not change all too often.  And your application coding will be more fun.
  2. Easier maintenance.  Even the best APIs change.  And when it happens, you don’t really want to go through all of your application and change all calls to the old version of the API.  Especially, if the updated version is not fully backward compatible.  Instead, you’d just rather update your API abstraction layer and be done with it.  And if you do, like you should, have unit tests covering your API abstraction layer, it will be trivial for you to see if you broke anything or not.
  3. Easier reuse and more control.  One of the biggest problems with third-party APIs is that you don’t control them.  Third-party introduces features, bugfixes, upgrades, and maintenance down-times whenever THEY want.  You rarely have much say in it.  When you have a layer in between the third-party API and your application, you have more control as to how all those things affect your application.
  4. Easier migration to another third-party API.  And you know that these things do happen.  You’ve been using one provider of the service, and now there is a better one.  If you were using first provider’s API directly from your application, you are pretty much in trouble now.  Going through the whole application replacing calls to the new API, with different set of parameters, data types, and return values, is a huge undertaking.  If only you had an abstraction layer, all you’d have to do now would be to change that instead. Sure, you might need to extend it a bit, or introduce changes to the currently used functionality.  But, from my experience, such changes would be much smaller and simpler (since you are working with your code on both ends).