[Nitro] Some suggestions for 0.31.0 (gems)

Michael Fellinger m.fellinger at gmail.com
Fri Jun 16 22:44:48 EDT 2006

Hey Nitroists :)

This is not the usual - I-want-this-feature email

I've had some encounters with newcomers to nitro on IRC and there were
some things that annoyed almost everybody that would be easy to fix.

This is talking about the distribution of nitro/og and the examples,
hoping that it will give you some ideas of what will definitly help
people to pick up nitro with less pain (yes, there still is some to go
through until you can have your first hello-world)

First: >> nitro/ProjectInfo:  - [ RedCloth, '= 3.1.3' ] <<
Can we somehow get rid of that dependency?
Lots of people use BlueCloth instead and as far as i've seen it's only
used in Flare/Spark - which are not installed with the gems and in
Glue, as a kind of convinience that is not really documented but i
guess it's being used for {{...}} or {|...|}
i've not heard about both until looking into that file to find out why
i have to install redcloth over and over again with nitro.

Nowadays the 0.30.0 nitro-gem is unusable for usual users since
redcloth 3.1.4 is out and we have an explicit dependency on 3.1.3... i
only thought wtf?

So, there are two ways to resolve this issue, first: use of >= 3.1.4
or second (and more favored by me) dropping the dependency if we
continue not having a specific example of how to use it.
not even spark/flare use the markup-method, so why should we use them?
and glue is being droppend anyway so what better time is there to get
rid of it :)

Second: >> specific-version-dependencies a la = 3.1.3 <<
this is especially for the ruby-breakpoint and daemons dependency, it
certainly won't hurt to make this a bit more relaxed and allow newer
versions - these gems are known to provide the same API over quite
some time already and are less likely to change without notice since
lots of programs build on them.
my proposal is - use of >= here as well. for the reasons i mentioned earlier.

Third: >> facets <<
I know the issues with facets, as their code is weaved closely with
nitro/og, but i have to say that i'm using still the code of 0.29.0
with the current facets and have no broken functionality.
This may serve as both an compliment and an reminder to both the
community and especially to trans and george, since they work closely
But it's a reminder that nitro _is_ becoming more mature and we should
reflect that, if possible in the dependencies of the next gems to come
Another thing is that the rdoc of facets doesn't seem to be on the
latest level on facets.rubyforge.org - it would be nice to have an
up2date documentation since i regulary search this page for
functionality i need and maybe have close at hand without knowing it.

All of these changes would make it much smoother for newbies to get
up'n'running with nitro without too much effort from our side, but
there is more - taking a bit more effort :)

gemifying examples/spark/flare

This is something i would _love_ to see and that would make a great
point of entry for newcomers who just want to setup a wiki/blog within
5 minutes or check out what all the fuss is about.
I have little to no experience with creating gems and i'm not sure if
we should make examples to a gem - but at least providing a direct
link from both the homepage and the starting-page of a new
nitro-application would help in the long term.

however, i would love to see flare/spark neatly packaged up, with some
small tutorial on how to get up and running with them (which might
take as little as a 2-page-tutorial on oxywtf)

I know that george once had the plan to gemify them and to make them
run nicely (as much as possible) with kirbybase so the users don't
have to install any database and just can get work done.
If we ever get that far, no doubt - we will be flooded with new users.
There is a large-scale-curiosity out there about what nitro/og is and
what it is capable of - almost everybody has heard about it (even
pythonistas) but consider it as immature because of documentation.

So, since we already love to let code speak for us, getting these two
applications on the street would serve as a real beacon and might as
well lead to more questions on oxywtf and great new minds to share
their thoughts with.

If you guys are happy with distributing flare/spark on this way, i
will do my best to create gems for them ( though the help of anybody
on that point would be greatly appreciated, since i currently have no
experience with that stuff ) and also to clean up the code that is in
there, which is in some parts incomplete or unneccesary or a bit hard
to understand.
Also we could bring in some new features from our latest developments
like the feedgenerator or cleaning up of the model-code. as well as
better use of elements.
at the time when the new part/admin of hits the street and the other
stores work with the new Og, i would be happy to have finished the
work on these issues and hit the gas-pedal on our nitro-driven car a
bit harder to reach further than ever a framework before.

Ok, thanks for reading that far, as always i appreciate every feedback
i can get.
Hit your Reply-button: NOW ;)

Also keep in mind, we can pick only one or two points from what i've
said and already improve the whole community - if we would pick all
points and work on them that would be too nice to be true :)


More information about the Nitro-general mailing list