No API, no cries

Nowadays, a good product can't really exists without a strong API.

For The-Data-Box, I had some hard choices to make because the API is the most exposed part to the community.

We could nearly summup like this :

• bad API = imminent death
• good API = involved community

But, what is a good API ?

I've been googling around to study some example of some popular API, like DropBox, Google Drive, GitHub, Stripes, FaceBook... and many others.

And I've found that API are mostly organized around REST, but they don't all respect the REST specifications.

Some of them simply don't use correctly the HTTP verbs (GET / POST / PUT / DELETE).
Some others don't follow the directive to *not* include the method in the URL, like "read" or "update" (because the command is supposed to be implicitly given by the HTTP verb).

Despite that, they are still good API, so, the strict respect of REST recommandations is not the only criteria to define what is a good API.

On top of this, note that the most popular API are not necessary the simplest to use... If you search for the keywords API + HEADACHE, you'll find this kind of interesting links :
http://blog.programmableweb.com/2011/08/11/survey-says-facebook-api-has-most-headaches-and-horror-stories/

From my point of view, the good API is the one that needs less time diving into the documentation's API, because people (mostly) don't like to read docs.

That's why I've decided to build a very "expressive" API, by *explicitely* telling what we are doing in the URL structure.

For exemple, following the REST recommandations, I should have used the same routes for POST / DELETE operations, like this :

POST :  https://api.the-data-box.com/v1/{SPACE_ID}/box-setups/{BOXSETUP_ID}

to update a box setup, and :

DELETE : https://api.the-data-box.com/v1/{SPACE_ID}/box-setups/{BOXSETUP_ID}

to delete a box setup.

Instead, I've chosen the longer and more explicit URLs, telling both *the context* and the *operation* :

POST : https://api.the-data-box.com/v1/{SPACE_ID}/setup/boxes/{BOXSETUP_ID}/update

DELETE : https://api.the-data-box.com/v1/{SPACE_ID}/setup/boxes/{BOXSETUP_ID}/delete

In the end, nothing is hidden by the protocol.
And that sounds better to me.
Of course, the API can evolve, this is not a big deal, and I could also build a version called "v1-strict", that would strictly follow the REST recommandations.

Only the future knows about that :-)

Versatile !

Some people asked me if "big products" like Dropbox or Google documents - and all the other ones that can handle documents in a very simple and intuitive manner - would not be difficult to "beat" when it comes to files and documents management.

But this is not really a question as The-Data-Box is not addressing the same needs.

On one side, we have the "big products" that are file-oriented, and they are very good at it.
On the other side, we have The-Data-Box, which is data-oriented.

With The-Data-Box, you don't handle files, but you handle "data".
Data "can" be files if required, but it's mostly a structure of informations.

From the beginning, I wanted to have a flexible data structure in order to address the simplests needs for small to medium business companies. This particuliar  flexibility of The-Data-Box allows the users to imagine their own solution, depending on the data they need to store and process.

Do they need a specifc structure to store their bills ?
Is it only for future searching ?
Is it to validate it through a workflow ?
Is it to share it with other people ?
Is it to make stats about the bills, consolidated by year and by month ?
...

With The-Data-Box, the response to this kind of questions will define the "Box" used to store the bills. In this case, a "bill container".

In short, they just have to decide the structure of the Box (more or less, form fields), and which standard features they want to activate for this box : workflow, versionning, sharing, linking, discussion... 

In the end, the right word for a Box is versatile.

On top of this, The-Data-Box allows the users to handle their data in very soft and friendly manner, with no technical skills required because everything is setup with detailed and easy wizards, and no code at all.

From the start, I've really wanted that the work left to the users is as small as possible, and I've brought the wizards at the heart of the product... The-Data-Box is a "w w w product" :
Wizard, Wizard, Wizard !

Honestly, I think I'm now close to the goal... Ok, I still have to enhance some details, but, hey, it's still in beta...

Below, the Box versatility illustrated :

Back from Nepal !

Gosh !

When you travel around the world, you realize quickly that humans live in separated dimensions...
What's important for you is a distant concept for others.

European crisis ? Make me laugh ! This guy has a ton of metal dishes on his shoulders and he's trying to make his way down the mountain to reach the next village... and earn 2 euros.

We focus on our beliefs as if they were the only reality.
This is definitely not wise.

Crisis ? What crisis ?

Simple dashboard draft

Introspection

The brain is a piece of hardware that implements a bayesian network.
Everything we discover about the world is a new introspection step.
Each discovery gives a new information about the observer itself, and not about the world.

A bit of IT

Here starts the blog of this brand new project.

Since about 15 years, I'm working on software development for local customers at a very very modest scale.

My products generally give satisfaction despite I am each time convinced that I would have done better with more time and money (but few customers have time or money, and no customers have both...).

From the symbolic year 2000, I've been working with Document Management systems and Workflow systems, and I've seen the best and the worst part of the job, dealing with various solutions, more or less adapted.

From this year 2000, I've also started to build components that would be reusable, in order to save time (and money) when the customers' needs would be "common". As I've only used my "packaged products" for my own business, my products are diluated in my projects, and their footprint is close to absolute zero !

BUT...

From generations to generations, the spirit of all the ECM and/or DMS and/or Workflow solutions I've built kept about the same, just getting simpler and simpler, clearer and clearer, and more and more polished too.

In mid-2012, I've decided to throw all the old stuff and rebuild something that would reflect the clean & pure & simple system I've always dreamt about to fit the major needs of mid-size companies in term of Data Organisation, Validation, Publication and Sharing.

I would call this Data Efficiency.

Now, I'm on the way, but I've just realized how the task is huge and not compatible with a family life and forest promenade. So ? I've decided to boost the project with the little help of the Internet Community.

And if you don't know yet what I'm talking about, just know there is more to come...

At the very beginning...

Your Mind is a Data-Box.
Your Skull is a Data-Box.
Your Body is a Data-Box.
Your House is a Data-Box.
Your City is a Data-Box.
Your Country is a Data-Box.
Your Planet is a Data-Box.
Your Solar System is a Data-Box.
Your Galaxy is a Data-Box.
The Whole Universe itself is a Data-Box.

From an outer point-of-view, we live in a Data-Box and Everything IS the data.

But for now, let's talk about The-Data-Box.
A data-oriented product in our data-oriented universe.
If you have some data to store and to process : think The-Data-Box !