Forum: Nitro Nitro + Facets 2.0

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 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.

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

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 <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/

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?

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.

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.

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 11/1/07, Trans <transfire@gmail.com> 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