NoSQL

I had the luck (and I say this considering the number of talented engineers within Shine) of attending AWS re:Invent in Las Vegas recently. For those who don't know, re:Invent is an annual conference held by AWS. It's a chance for customers, vendors and AWS staff...

cloud-db.jpg With the current move to cloud computing, the need to scale applications presents itself as a challenge for storing data. If you are using a traditional relational database you may find yourself working on a complex policy for distributing your database load across multiple database instances. This solution will often present a lot of problems and probably won’t be great at elastically scaling. As an alternative you could consider a cloud-based NoSQL database.  Over the past few weeks I have been analysing a few such offerings, each of which promises to scale as your application grows, without requiring you to think about how you might distribute the data and load.
YOW Conference 2013
4 Shiners attended YOW Melbourne last week, which is a technology conference held yearly and brings high-profile and savvy presenters to talk on new and current trends in IT. I'll start with an overview of the venue, crowd and the sponsors that had stalls in the common area, then dive into a tech report.

Nodejs

Node.js has impressed me several times with high performance right out of the box. In my last Node.js project it was the same: we beat the given performance targets without having to tweak the application at all. I never really experienced this in Java EE projects. Granted the project was perfectly suited for Node.js: a small project centered around fetching JSON documents from CouchDB. Still I wanted to know: how would Java EE compare to Node.js in this particular case? 

ren_and_stimpy_by_buttercupnergal

“In our (admittedly limited) experience, Redis is so fast that the slowest part of a cache lookup is the time spent reading and writing bytes to the network” - stackoverflow.com

Can Databases Be Exciting To Work With?

It’s very rare that a project can cause an engineer to get excited about the prospect of working with a database they've never worked with previously, especially when it’s a relational one. That mainly boils down to the fact that the majority of them are clunky monstrosities that are painfully slow and cause us to grimace at the thought of having to integrate them into our applications, not to mention having to piece together gnarly and over engineered SQL statements.

Cliffano Subagio from Shine Technologies presented together with Carl Husselbee from Sensis "JavaScript from Nose to Tail" at the August MelbJS Meetup. The slides and the video of the presentation are now online....

We have been using Apache CouchDB at one of our clients project, and despite how well CouchDB worked, we learnt that there was still no easy way to find certain documents without resorting to writing map reduce functions either via a temporary view or a design document. This was an issue in particular for our testers and others who were not exactly familiar with CouchDB. We needed an easier to use alternative, and that was the main reason why I wrote Couchtato.
You've probably heard it somewhere already: NoSQL is the new hotness. There are a growing number of weirdly named storage engines out there purporting to be part of the NoSQL movement. This post is the first of a small series about some recent work we've been doing with CouchDB. The project is still ongoing, but now seems like an appropriate time to cover what I've learned so far. If I've made any newbie mistakes, please feel free to flame me in the comments. Anyway, let's get on with it then. In this post, I'll talk a little about the bits of CouchDB that have instantly appealed to me. The good bits.