http://www.urubatan.info/2007/10/ruby-out-of-the-r... 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. -- James Britt www.ruby-doc.org - Ruby Help & Documentation www.risingtidesoftware.com - Wicked Cool Coding www.rubystuff.com - The Ruby Store for Ruby Stuff www.jamesbritt.com - Playing with Better Toys
on 2007-10-26 07:25
on 2007-10-26 15:51
On Oct 26, 1:25 am, James Britt <james.br...@gmail.com> wrote: > http://www.urubatan.info/2007/10/ruby-out-of-the-r... > > 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. T.
on 2007-10-26 16:09
> > 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. -g.
on 2007-10-26 16:10
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.
on 2007-10-26 16:14
Hey Gang ...
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
on 2007-10-26 16:15
> 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. Aidan
on 2007-10-26 16:39
Dear all, 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. thanks, George.
on 2007-10-26 17:50
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.
on 2007-10-26 17:59
What I meant was collaboration on nitroproject.org (not cheatsheets) would be a great way to learn each others Nitro idioms.... Anyhow, as for a possible nitroproject.org/cheatsheets.... 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.
on 2007-10-26 18:08
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. Thomas
on 2007-10-26 18:43
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.
on 2007-10-26 19:38
Rob, 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. -g.
on 2007-10-26 20:22
On Oct 26, 10:37 am, "George Moschovitis" <george.moschovi...@gmail.com> wrote: > > 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: 1. 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. 2. 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. 3. 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? 4. Move the nitroproject.org site into the repository, preferably under the nitro metaproject directory, so we developers can contribute to it. 5. 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. 6. Make OxyLiquit the offical FAQ system. Link it and nitropoject.org together better; blend the sites look and feel better, etc. 7. 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.) 8. Add a documentation wiki to the main site --use docbook or whatever format you want. T.
on 2007-10-26 22:10
Ok, Let's start by making the repo version compatible with facets 2.0. I will work on this tomorrow. Be warned, I will probably need your help though. When this is done, you can work on ponits 1-2. Please also include blow as you describe. -g.
on 2007-11-01 00:46
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: > 3. 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 Klein <cklein1@email.sjsu.edu> +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 <cortland@e-society.org > http://e-society.org/ <me@pixelcort.com> http://pixelcort.com/
Enable email notification
Enable multi-page view