Define thoroughly the iai goals

[lorenzogrv]

TODO

• [ ] Refactor this issue summary to something like the #1 summary
• [ ] Goals document should precede the Design Principles document on the Life Cycle.
• [ ] Goals is missing a "Productivity Goals" section, values related to time measures, effectivenesses to reduce time requeriments.
• [ ] Review the "agile" goal, the argument is: Agile has been demostrated to be... by the software industr.... blabla Methodology driven + agile is the same, refactor that
  • http://www.mountaingoatsoftware.com/agile/user-stories
  • http://www.mountaingoatsoftware.com/agile/planning-poker
• [x] Currently, the readme file on the 1.0.0-alpha branch mixes the goals with some principles, with stuff that seems more likely a feature list. This must be splited accordingly, cleaned up (removing things that do not belong there if need), and documented on the wiki

It seems that the "goals" document should be not aka. requeriments. requeriments seems a thing more specific while goals should be wider.

(laconbass @ January 2015)

[lorenzogrv]

Coming from a markdown file on the old doc folder:

The intends of the iai api is maximizing the reusability of every project's code while minimizing the impact of any change on any application component.

The api must produce scalable applications consisting in a set of easy redistributable components.

Obviously this is a really bad definition, I'm posting it here only to delete that file :laughing: and preserve the idea as it comes from a far past.

[lorenzogrv]

While writing the Goals document, the following content from the old readme file does not make sense in it:

Asynchronous batch processing

Forget the sync code logic. Each action is an async task. Each task is a function. Each function is pushed to a heap and is called as soon as is posible on the next loop around the event loop (aka. process.nextTick), once the previous task has been completed (aka. "first in, first out").

This does not have sense. both sync and async flows exist, and are strategies to solve problems. That said, the heap thing is another valid strategy to manage sequences of asynchronous tasks. Any way it does not belong to the goals, it's more a like a Dessign Pattern / Object Type

[lorenzogrv]

iai must produce scalable applications consisting in a set of easy redistributable components.

That seems a pretty good definition, but sounds more like a requeriment?

[lorenzogrv]

More thoughts on the goals document.

Maybe the above sentence could be rewritten to reflect the fact that iai should work with this kind of applications an components, whose arrangement and distribution is unsure.

This seems like a good start point for #4, working with the unknown.

[lorenzogrv]

Pretty happy with the current Goals document. Let's conclude aside on an Overall Analysis #4 .

[lorenzogrv]

After reviewing the document again I decided to improve specially the code conventions section and slighly the *life cycle" section.

[lorenzogrv]

EASE DEBUGGING!!!!

Amazing post about node-inspector by the nodejitsu team.

http://docs.nodejitsu.com/articles/getting-started/how-to-debug-nodejs-applications

[lorenzogrv]

So the whole thing is a big goal: maintain the attitude, that connects the idea and philosophy with the goals document. The goals document should explain how it's supossed the program will help on maintaning the attitude.