It’s a long weekend this week in the UK. I wanted to learn a bit more Ruby, so I decided to use the time to start writing a client library for CouchDB. Basically my day job at Cloudant, but in Ruby.

I first used Ruby back in about 2005, and this site was powered by a couple of Ruby incarnations: first a Ruby on Rails app for a time; then a fairly hokey static site generator. I think that lasted until around 2009 when I learned Python and switched to Google AppEngine. Even with this experience, I don’t know Ruby particularly well – I have never used it full time – but I think the library has come out okay so far.

If you use Cloudant’s dashboard to generate API keys and assign permissions, you’d be forgiven for thinking that an API key can only be used for one database. However, that’s just an unfortunate implication of the UI. In fact, you can give an API key permission to read or write any number of databases – even ones on different Cloudant accounts.

The key to doing this is to use Cloudant’s HTTP API rather than the dashboard. Here’s how.

One feature I value in an editor is allowing different languages to have different settings. Like the way the Javascript community has settled on using two spaces for indenting, whereas Python uses four. This feature is built-in to Sublime Text. The lack of the feature is one reason I gave up on the Atom editor.

While less convoluted than the read and write behaviour in a cluster, the behaviour of indexing in a clustered CouchDB or Cloudant environment merits a discussion. Understanding how indexing and querying works in a cluster will help avoid confusing situations where queries to a view index on Cloudant will produce different results because the indexes contain different data.

tl;dr: Writing indexing functions (map/reduce in views, index for search indexes and so on) which can return different values for the same input document will cause the indexes on shard replicas to differ, meaning they could return different values for the same query even when data doesn’t change. It’s the developer’s responsibility to write their indexing functions such that they always emit the same values for indexing for the same JSON input.

I should have made the point in my Technical Debt post that making compromises in order to hit business needs is emphatically something that needs to happen. And not just occasionally, but with regularity.

Indeed, I’d be surprised to work on any non-trivial project without making compromises. This very website is full of compromises to meet the business needs of (a) my becoming quickly bored with writing frontend code and (b) of knowing that tweaking code no-one will ever see is less fraught with worry – and therefore easier – than actually writing this stuff that you are reading. The need is for writing, the site is small: many shortcuts can be taken. If I ever have a million hits, the site will most assuredly collapse.

But I still don’t like the phrase. So what would I replace technical debt with, as a concept? I’d instead invite stakeholders to consider a restaurant that is just starting out.