FYI,
Tom, more or less completed the transition of Nitro to Facets 2.0 
When he
releases the bug-fixed 2.0.3 version I will update the repo with his
changes.
-g.
YEEHA!!!
I would love to use Nitro professionally and would like to see enough
momentum and community built up behind it to support that sort of
recommendation.
To that endâŠ
Whatâs everyone thinking regarding the âPRâ should occur surrounding the
release of 0.50? And why not call it 0.95?
Whatâs everyone thinking regarding the âPRâ should occur surrounding the
release of 0.50? And why not call it 0.95?
I am not sure about PR. Any ideas?
I like the 0.50 version thoughâŠ
-g.
On Oct 31, 12:48 pm, Robert M. [email protected] wrote:
YEEHA!!!
I would love to use Nitro professionally and would like to see enough
momentum and community built up behind it to support that sort of
recommendation.To that endâŠ
Whatâs everyone thinking regarding the âPRâ should occur surrounding the
release of 0.50? And why not call it 0.95?
0.50 is good for now. But point taken, I would like to see the next
focus move be toward reaching a high-quality 1.0 release.
T.
Robert M. wrote:
YEEHA!!!
I would love to use Nitro professionally and would like to see enough
momentum and community built up behind it to support that sort of
recommendation.To that endâŠ
Whatâs everyone thinking regarding the âPRâ should occur surrounding the
release of 0.50? And why not call it 0.95?
Nitro PR might be a hard sell.
There seems to be a perception that itâs a Rails-a-like; at MtWest
RubyConf earlier this year, Chad F., in his keynote, basically said
that people working on Nitro should just stop, because itâs the same
thing as Rails (though he approved of continued work on Iowa, because in
his view it was sufficiently different from Rails).
People whoâve spent time with both Nitro and Rails likely do not see
them as the same thing; getting people to try Nitro is perhaps the best
way to grow the community. But when folks think Nitro is âthe same
thingâ as Rails, and they already know, or know about Rails, adoption is
challenge.
Nitro is not going to suit everyone, but thatâs true of Rails as well
(witness the emergence of Camping, Merb, and Sinatra). However, people
wonât really know if its good for them or not unless they try it, so
getting up and rolling needs to be really stupid simple.
The Og/Nitro pain-points have been discussed here before, but I think
they boil down to various issues that trip people up too early in the
âtry it and seeâ process.
â
James B.
âTear it up and start again.â
- Anonymous
At this point, being a silent observer, I believe the biggest thing
needed from the Nitro project now are tutorials and sample projects
that actually work.
Currently, getting Nitro to actually work on Mac OS X is a bit of a
challenge, and spark nor flare seem to work âout of the boxâ.
I remember when I first saw nitro it was with some screen casts of it.
Once 0.50 comes out some up-to-date screencasts, text-based tutorials
and âout of the boxâ working example projects would be in order.
Also, a page on the site called âWhy Nitro is different than Railsâ is
needed.
On Oct 31, 2007, at 4:07 PM, James B. wrote:
People whoâve spent time with both Nitro and Rails likely do not see
wonât really know if its good for them or not unless they try it, so
getting up and rolling needs to be really stupid simple.The Og/Nitro pain-points have been discussed here before, but I think
they boil down to various issues that trip people up too early in the
âtry it and seeâ process.
â
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]
You canât really call it 0.95 because there hasnât been a stable
long-term
release in the wild for more than six months.
So you will want to keep some numbers for the inevitable bug fixes until
it
is stable.
You know lots of people can write software. It takes a step up to make
it
industry ready, robust and trusted. The main skills Iâve seen notices
are
- good processes,
- especially release control and integration testing
- stop adding new features.
- good solid regression testing
Thatâs the engineering. The production also requires
- Training and tutorials
- User documentation (not internals and definitely not rubyDocs)
- Solid internals documentation (which Oxy seems to have in hand)
- Robust reliable web site in the robust reliable stable version
PHP4 didnât do its website in PHP4 (they used PHP2 or maybe 3)
To be honest the competition here is not rails, its PLONE.
Which has conspired to achieve all those things and is no up to release
3 â
I runs fine and thereâs a large growing wild population in the rivers of
the
internet.
These days I don marketing because lots of people can write code as well
as
I can and better. Iâm just waped enough to have gone back to university
to
discover why GREAT products and magic technologies donât make it out in
to
the streams and rivers of the information aqua-sphere.
Yet youâll see the wackiest stuff get funding for development and a
promotions budget.
Iâll keep speaking for good engineering processes â It looks like
things
are getting better. I heartily recommend the SVN offer!!
Aloha,
Will.
The points are
-
There are issues that trip new users up early in the process
- Getting started needs to be brain-dead simple
-
The lack of differentiation from Rails
So the questions to answer are:
- Whatâs the answer to âWhy should I consider Nitro for my next
project?â - What specifically is broken in the getting started steps?
Iâve done some light investigation of Plone and am wondering why I donât
just use that.
The path to that answer leads goes through the ecodiversity of the open
source landscape, the question of sunrise and sunset technologies, and
the agony of trying to balance picking the best with picking a
popularity/mindshare winner.
It passes through the language war swamps, where the best and the good
exhaust each others energies, while the mediocre evades engagement and
is first to reach stable ground on the other side.
What I keep hoping for is from the wild fragmented experimentation of
the Open Source stacks that one thing will succesfully put these three
things in place
- Solidly great design
- Process, stability, documentation
- Mind share & momentum
- The supporting ecosystem of polished applications & components
I think these things evolve in that order, though the most successful
frameworks seem to compromise on step #1.
Only Zope/Plone seem to cover all four. Nitro and PHP occupy
non-overlapping sets â Nitroâs got #1, PHP has #2 thru #4.
On 11/1/07, Trans [email protected] wrote:
And you know, the whole thing Chad F. said is a load of crap.
Should Burger King stop making burgers b/c McDs does basically the
same thing? Diversity is important. Without it nothing advances.
I quite agree. It may be just tilting at windmills, but practical
alternatives to a juggernaut like Rails are a good thing. And I think
the environment is starting to open up again to the possibility that
non-Rails alternatives can pull in some substantial numbers of new
users, both from the new-to-ruby camps and the rails-user camps.
Kirk H.
Iâve developed on Zope before. Itâs pretty cool. And Iâm suprised it
never seemed to get the hype that Rails has â I guess programmers
just donât know what to do without Vim. 
But I agree. Thereâs a lot to like about the Python/Zope/Plone stack.
But Iâm a Ruby programmer and not a Python programmer, so I look for
Ruby-based solutions.
And you know, the whole thing Chad F. said is a load of crap.
Should Burger King stop making burgers b/c McDs does basically the
same thing? Diversity is important. Without it nothing advances.
Personally I think Nitro has more potential then Rails strictly from a
techinicaly view point. We just need to get the other things in place.
Which bring me toâŠ