[Neo] Suggestions for a "Design with Neo" Guide

Björn Granvik bjorn.granvik at jayway.se
Wed Aug 8 22:39:45 CEST 2007


Hi guys,

It took me a while, but here are a few thoughts.

>> However, it still feels like a jump to for instance "How to create a
>> Neo independent API".
>
> I hear you. We've also talked about making an equivalent of the Java
> EE blueprints, not in terms of a reimplementation of a store to sell
> cat nodes but in terms of a real, full-scale big example which would
> showcase a lot of Neo best practices. We don't quite have the cycles
> to pull through that at the moment. But would that cover the void that
> you see?

It's an excellent example and will be needed,  
but            ...there's always a but :-)
A blueprint is often for those who already have decided that they  
_will_ use Neo.

But first programmers will be looking for information on "what it is  
Neo" and whether they or not they will use it.
A 10 minute guide will not enable me to _choose Neo_. This is  
probably a lot tougher for this type of solution since it deals with  
data. Replacing sql is a hard sell.

He/she will probably be more attracted by:
"Neo in action"	Practical guide on how to use, good examples,  
extracted info from Neo blueprint
"Neo cookbok"	Recipy based, easy to lookup "solutions" (short and not  
so formal as design patterns)
"Neo Primer"		Even shorter guide, not an article - rather small book.

Don't get me wrong, these names are just here to illustrate my point.  
They might be a tad unimaginative.

Did I make any sense?


>>
>> Btw, I'll try the getting-started guides when I get a chance.
>> Do we have a one-liner to go as well?
>
> We're fresh out of those! Any suggestions?

Well, there just suggestions so consider them food for thought.

"It's a netbase."
This is might not be a very good one-liner, but will give you a  
chance to explain what it is in more words.

"An agile database to go"
Meaning this database will actually grow with your project and not  
hinder you as an SQL-based one does after 1.0.

"Dynamic persistent information"
Meaning semistructured, rigidless (no alter table commands and fixes)

Trying to find one-liners is a bit like trying to find the single  
words that actually describes the goal/intent of Neo. These value  
added words are quite important because I believe they will guide  
such things api-construction, architecture and so on.

So if "dynamic" is important; how does that relate to an getAttribute  
that throws an exception if that attribute is missing. (This is an  
old discussion that Emil and I held some time ago. Emil I actually  
have another thought on that, but let's do that another time:-)

/Björn




More information about the User mailing list