What if the application you built was not made up of markup with the purpose of explicitly creating controls? What if your application instead was made up of data-islands/data-providers with meta-data instructing the browser about what kind of service and data you offer? In the case of accepting input etc, you would also be able to instruct the browser with business rules and steps to perform.
Recently I went to a Meetup organized by Neo4j. During the Meetup they provided us with a free paperback version of the book: Graph Databases by Ian Robinson, Ian Webber and Emil Eifrem. It’s a good book and I highly appreciate it while approaching the land of Graph databases. Thank you guys. And thanks Neo4j.
You to can grab it for free.
Just assembled the last piece (for now) of my new computer. First lets get one thing clear, I’m not a gamer. I really don’t care about gaming. The usage of this computer will be development, photo and some movie editing, but focus is on development. I wanted a good and performant setup for running Hyper-V on it, hosting multiple devmachines and servers. So far, it feels really good. And it’s not running on any specific server hardware.
Recently I was building a solution for managing some contents. I used a document oriented database for storing the actual contents. In this particular scenario, I used CouchDB. First a POC was built, just to get an idea of the domain and what was possible to achieve, given a fixed amount of resources. Then the actual product work began. One requirement was to be able to reuse content. The reuse strategy picked was, by faking references. So there was no duplication and embedding of data, instead, there was a referencing solution. This post is about the shortcomings that I’ve found with going that route.
If you happen to follow me on Twitter then you probably know that I’m really not happy with Garmin and their Garmin Express software right now. If you don’t know what it is, it’s the software that is supposed to sync data between e.g. your Garmin Forerunner 620 and Garmin Connect. Today I had a unpleasant experience with it and I would be more than happy to try another brand right now if they said: “Hey, we take your Garmin 620 and switch it for a something, something.”
In the family of NOSQL stores there is a particular family, focusing on storing semi-structured data as ONE unit called a document. This family is called: “document stores. It’s most often represented by a JSON-blob. When it comes to ACID-compliance, it’s “guaranteed” for ONE document. Either it accepts the blob or it doesn’t. A construct that e.g. makes it easier to scale as it reduces the time for locks etc. If scaling horizontally, it can still have conflicts as the cluster can become partitioned, but that’s out of scope of this post. This post is about…hmm…Bob and his documents. Oh, and some about the contentedness of documents; that is, its way to handle relationships.
Wait, can it?