That URL should also show you the latest history of changes.
e-mail me if you want commit access. The basic tutorial will broadly
follow the outline from the Ramaze tutorial : http://ramaze.rubyforge.org/tutorial/todolist.html
Small example apps are also welcome.
All content can be freely copied and adapted, e.g. to the Nitro repo, to
Oxyliquit, to Nitro RDoc, blogs, wikis, etc.
I suppose I should merge the newly expanded http://robmela.com/cheatsheets into this… or copy stuff from this into
cheatsheets… working through og relations today…
I’m a little bashful because they do need more work, and I’m sure the
core developers see plenty of shortcomings.
For future distribution I think we should integrate some of the content
into the upcoming Rdocs documentation project. I’d like to structure
the Rdocs such that they can generate HTML pages like these in a format
that’s really accessible to newbies and to people looking for
information in a hurry.
Sounds like there’s a consensus. I’ll start reading up on RDocs.
It might also make sense to coordinate on separate aspects of Nitro for
the first pass. I’m finding that learning Nitro and Og while
documenting the experience leaves coverage thin and incomplete. With
what little time I have it would take a to really learn and document
Nitro.
It also makes it easier for each of us to take the role of newbie and
step through each others’ documentation, encountering the errors or
missing pieces just as a new user would.
I personally also think the primary documentation should be the RDocs.
Every module/class should have a toplevel RDoc section which explains
its purpose and typical usage. Public methods should be fully
documented.
As far as external documentation goes I am (as I said before) a big big
fan of wikis. However this would partly overlap with Oxywtf, so we don’t
need it right away. Better to not split community stuff over too many
different locations. So if you feel like contributing stuff, head over
to http://www.Oxywtf.de (insert catchy tune).
The main virtue of the tutorial repo I see is that it can contain a lot
of code examples along with their tutorials. However it might disappear
again in the future as it’s contents are merged into the main
repo/rdoc/oxywtf. Should it get to contain more example apps then can be
reasonbly shipped with the main distribution then it might become a
package in its own right (e.g. nitro-examples). This will depend on
community input.
(ab)
Robert M. schreef:
cheatsheets... working through og relations today...
> keep up the great work.
>>
>> Oxyliquit, to Nitro RDoc, blogs, wikis, etc.
>> Nitro-general mailing list
_______________________________________________
Nitro-general mailing list
[email protected] <mailto:[email protected]>
http://rubyforge.org/mailman/listinfo/nitro-general
Sounds like there’s a consensus. I’ll start reading up on RDocs.
It might also make sense to coordinate on separate aspects of Nitro for
the first pass. I’m finding that learning Nitro and Og while
documenting the experience leaves coverage thin and incomplete. With
what little time I have it would take a to really learn and document Nitro.
It also makes it easier for each of us to take the role of newbie and
step through each others’ documentation, encountering the errors or
missing pieces just as a new user would.
Actually I would argue against RDocs as the primary documentation.
RDocs have some issues. The most overarching one is the need to write
code to fit docs rather than the other way around. RDocs are really
“programmer docs” not “user docs”.
I’m preparing to put together a Wiki for Facets Documentation (thanks
to these Nitro tutorials btw, I can finally see how to proceed!).
However, rather then use a simple flat-file system, I’m going to use a
DB and index the documentation by class/module, method, arity, and
more. This DB will be the official user documentation (and the RDocs
will just be for the programmer’s). It will be interesting to see how
that builds up over time, and what can be done with the DB, say to
generate a reference manual.
Perhaps we can work together to create a system we can all use, Nitro,
Facets or any other project too.
T.
P.S. Isn’t require ‘nitro_and_og’ redundant now? Shouldn’t it become:
