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.
on 2007-10-31 15:53
on 2007-10-31 17:53
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?
on 2007-10-31 20:30
> > 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 2007-10-31 22:54
On Oct 31, 12:48 pm, Robert Mela <r...@robmela.com> 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.
on 2007-11-01 00:09
Robert Mela 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 Fowler, 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 Britt "Tear it up and start again." - Anonymous
on 2007-11-01 00:30
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 Britt 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 Klein <email@example.com> +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 <firstname.lastname@example.org > http://e-society.org/ <email@example.com> http://pixelcort.com/
on 2007-11-01 02:42
The points are 1) There are issues that trip new users up early in the process - Getting started needs to be brain-dead simple 2) The lack of differentiation from Rails So the questions to answer are: 1) What's the answer to "Why should I consider Nitro for my next project?" 2) What specifically is broken in the getting started steps?
on 2007-11-01 15:08
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.
on 2007-11-01 16:38
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 1) Solidly great design 2) Process, stability, documentation 3) Mind share & momentum 4) 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 2007-11-01 17:41
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 Fowler 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....
on 2007-11-01 18:44
On 11/1/07, Trans <firstname.lastname@example.org> wrote: > And you know, the whole thing Chad Fowler 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 Haines