Sixty Second Tech is a (relatively) new podcast by prominent Zender Cal Evans that promises to be the “Cure to BSS”

Sixty Second Tech is the only known cure for “Blank Stare Syndrome” (BSS). BSS happens when one of your technical friends starts talking to you and unconsciously slips into geek speak. They don’t realize they’ve triggered BSS until long after your eyes glaze over. BSS is an embarrassing condition but a curable one, just spend one minute a week listening to Sixty Second Tech.

While I am definitely on the side of the “technical friends”, the short podcasts — almost exactly 1 minute each, quite impressive — are a great way to provoke thought about aspects of technology that may not otherwise have been brought to the fore, but probably should be; such as Wordpress as a CMS, OpenID and Google Alerts But, my favourite is pointing anyone who speaks to me about “SEO” to the episode “Go Relevant or Go Home!”; which sums up very succinctly the folly of the whole practice.

His name is Cal Evans, and he is my sixty second tech.

Well, I finally bought myself a domain. You can now find me at my new home on the web: blog.tekerson.com (Not that you get a choice in the matter, the old domain redirects). To go along with it, I’ve got a new design (for those of you that actually come back). I think it’s better suited than the old one. That is all!

Since I was first introduced to CouchDB late last year when Jan Lehnardt discussed it on the PHP Abstract Podcast my interest was piqued. I have since read as much as I can about it, which doesn’t actually amount to a great deal unfortunately. However, I think the idea has merit as an alternative to relational databases in various scenarios.

I have been using memcached to store aggregated objects and it often seems pointless to break them into disparate parts to fit into a relational schema. While I realise CouchDB is not an object cache, being able to store data “as is”, in a form (JSON) that is directly malleable by many languages makes a lot of sense.

The “views”, used to retrieve data, select the documents to return by passing them through user defined JavaScript filter functions, instead of querying using SQL as in most relational databases; providing near infinite flexibility for data retrieval.

The major concern that I haven’t seen adequately addressed is performance, especially given larger datasets. With the unstructured nature of the data and the flexibility of the view functions, it seems performance could be a challenge. Though given Erlang’s ground up concurrency and some of the algorithmic genius they have apparently borrowed from Google’s MapReduce — datasets don’t get much larger than that — I might yet be proved wrong. I hope I am.