Perhaps folks here could add comments to answer some of the questions
and concerns raised in the posts, specifically about automatic code
reloading, and the claimed lack of anything like Rails’ migrations.
Perhaps folks here could add comments to answer some of the questions
and concerns raised in the posts, specifically about automatic code
reloading, and the claimed lack of anything like Rails’ migrations.
thanks for bringing this to my attention…
I have replied to the post.
Perhaps folks here could add comments to answer some of the questions
and concerns raised in the posts, specifically about automatic code
reloading, and the claimed lack of anything like Rails’ migrations.
To be honest. At this point, I don’t think Nitro is ever going to make
it beyond niche use. I’ve been following Nitro for a long time now,
and while it certainly has improved a lot, there are no signs that it
will ever move past the “some day” state it is in right now. Just look
at the evidence:
A webpage that is never finished
Documentation that is never written
An API that is never quite stable
A revolving door of developers
George has been talking about the release of 0.50 for around a year,
but it doesn’t seem to be any closer today then it was back then. I’ve
talked to him about some of the stuff and he seems receptive, but then
nothing ever happens. I guess he’s too busy and that’s understandable,
but that doesn’t change the facts.
Today we have a number of new, strong web frameworks coming on the
scene, such as Merb and Sinatra. Nitro is getting squeezed out. Unless
things turn around and soon, I fear it’s just going to fade. I think ruby-doc.org has been the biggest boon at keeping Nitro relevant, but
I’m not sure that will last either. ruby-doc.org is getting it’s own
new competition, such as http://www.noobkit.com/.
I don’t mean to be a nay-sayer. I’m just calling it like I see it.
Maybe you don’t agree with me (and actually I hope you don’t!), but
it’s something to consider in any case.
It might be worth putting a 0.49 release out there now. I’m afraid
that as Nitro gets more attention the 0.41 release give an unfavorable
impression of the system’s quality.
I’m still working through it as a newbie, and the only major problem
I’ve had with stability is the admin part. Once that’s resolved I’d
feel confident recommending Nitro to friends who are decent programmers
with real projects.
Zed seems to like it and has mentioned it on the Mongrel list.
I can quite see the point, and I am personally a bit sad that the
framework
itself is not available now.
There are simple things (project management) things that need to be
done. I
sent a list out earlier to George regarding what is needed to be
production
ready.
My perspective as “audience” is that it is too hot for people to just
let
BE. This is not a wise attitude. Sooner of later there as to be “ready
enough” to say let go – Freeze it as stable.
It is easy, it takes under 5 seconds to make a decision.
Everything else is discussion. Action follows decisions.
Personally (again) I believe Nitro is the best concept I’ve seen in
computer
deplpoyment management for 20 years.
The risk with these frameworks is of becomeing bloated. So locking down
a
release now is advised. The next release can cull bloat. One has to
provide migration pathways for real-life projects. And one needs
documentation.
You can say, a project gets the following its documenters earn for it.
Think about that.
And set some action plans …
(keep up the good work)
Aloha,
Will
George has been talking about the release of 0.50 for around a year,
but it doesn’t seem to be any closer today then it was back then. I’ve
talked to him about some of the stuff and he seems receptive, but then
nothing ever happens. I guess he’s too busy and that’s understandable,
but that doesn’t change the facts.
I think this is the reason that Ramaze came into being. It’s also the
reason I’m keen for Og to be it’s own project, because I think Og is
still
pretty special.
I’d love to see the site code so I can learn yet more about Nitro.
I’d be happy to move cheatsheets over to nitroproject.org, and certainly
seeing how George and others code in Nitro will give me more stuff to
fold into the cheatsheet docs. It’d also be a great way for users on
this list to learn each others idioms. Best techniques for using
Nitro, based on experience, would soon follow.
This framework is just too wonderful to let wither.
I have answered privately to tom, but here are the main points:
tom’s email motivated me to take some extra time to integrate the repo
version with facets 2.0, make sure the example runs and release it as
0.50(even w/o docs/tests).
I send to Tom the full source code of the nitroproject.org web site.
If
everyone wants to work on this (fix bugs, add more content or graphics
or
whatever) please ask him (or me) for the source code.
please understand that I am doing the best I can. This may be not
enough,
but I think more contribution and less remarks would be more helpful.
Part of what I’m playing around with is documenation format – it’s
supposed to be a rapid, simple tutorial and a quick ref – I don’t want
cheatsheets to acquire the completeness ( and information overload ) of
a book nor of a complete reference. Though I could imagine making it
dynamic, with user comments as php.net or the postgres documentation.
The really hard part of cheatsheets is gathering, verifying, and
organizing the content. Especially keeping it neat and simple enough
to be scanned and understood quickly, be quick as a quick ref, and yet
no so dumbed down as to be useless after the first scan.
The quantity of content, if and when they’re finished, will be small
enough that cconverting to this or that markup should only take a few
hours to a day. I found that agonizing over choice of markup was
preventing me from actually getting started. I think too that having
some actual content makes the choice and implementation of markup much
simpler.
That said, they can live in any markup form. I’ve thought about
docbook, since that makes them easier to organize, and from docbook one
could generate markup, html, or whatever.
I think cheatsheet content could be distributed among source code files
– and indeed it is, as some is lifted directly from George’s
comments. But the limitation of, say, RDoc, is that it would not be
possible to achieve the right flow for a quick-scan tutorial and
centralized quickref.
I see cheatsheets as necessarily being less comprehensive than the
RDocs.
How about a system like the one used by the Django framework? They
have all the necessary user documentation as text files in the
repository. It seems quite reasonable to have the documentation in
the source code repository and using a markup language like Markdown
or Textile would make it easy to read the docu as plain text and as
HTML (I personally prefer Markdown with extras - see http:// maruku.rubyforge.org). This would be usage documentation in contrast
to the API documentation provided by the RDocs.
An additional wiki where users could post documentation, tips and
tricks wouldn’t be bad either, perhaps integrate oxywtf better into
the documentation effort.
Just some thoughts because I currently don’t have time to provide
anything else.
please understand that I am doing the best I can. This may be not enough,
but I think more contribution and less remarks would be more helpful.
Well this is what I propose, and if you agree I will do most of it
myself:
Make Nitro a pure meta-project. Is should not contain any libs
itself. What’s in Nitro now likely belongs to Raw, but maybe Glue.
Then the Nitro repository would house well separated sub-projects,
Og and Raw, plus the Nitro meta-project. The Examples can be placed in
with their respective projects. We’d then have a clean project/
subproject repository:
nitro/
nitro/ (or call meta/ ?)
og/
raw/
glue/
We can leave in glue for now. And we can consider adding blow (http:// blow.rubyforge.org) to the collection.
Rather the working solely on a patch by patch basis, having a
central repo trusted devs can push to would be more helpful. But who
can host that?
Move the nitroproject.org site into the repository, preferably
under the nitro metaproject directory, so we developers can contribute
to it.
Give each sub-project it’s own mini-website too under their
respective sub-project directories. When published these subproject
sites will tie into the main site.
Make OxyLiquit the offical FAQ system. Link it and nitropoject.org
together better; blend the sites look and feel better, etc.
Since nitroproject.org runs on an old version of Nitro, we will
need to update it to use the new verion, but not until 0.50 has a
release candidate out. (I will probably need some help on this step.)
Add a documentation wiki to the main site --use docbook or whatever
format you want.
I emailed the source code to you. It would be great if you could clean
up
this stuff and prepare a nice .zip file for other people to use as
reference.
If you could integrate your cheatsheets it would be great as well.
I can host a repository for the Nitro team if you all would like.
I have a DreamHost account that I can set up and maintain a Trac and
SVN space if desired.
Whatever I can do to help this project, let me know.
On Oct 26, 2007, at 11:18 AM, Trans wrote:
Rather the working solely on a patch by patch basis, having a
central repo trusted devs can push to would be more helpful. But who
can host that?
–
Cortland K. [email protected] +1 408 506 9791
Student, Business Management
San José State University
Campus Village B 336D (formerly 337B)
375 S. 9th St. #5180 (formerly #2028), San Jose, CA, 95112
Operations and Technology, Entrepreneurial Society
<[email protected]
