I, Nitro

Ruby Apps Nitro
1

I am super happy to announce that thanks to George I am now a
professional (as in cold hard cash, baby) Nitro developer! From now
on I will be heading up Nitro development along with George. My goal
is to push Nitro into a high quality 1.0 release as quickly as
possible. My priorities are:

(1) Uber User Friendly.

Basically I want to do something like:

 $ gem install nitro
 $ ntiro demo helloworld

and

 $ gem install nitro
 $ nitro create ~/mynitroprojects/foofish
 $ nitro start ~/mynitroprojects/foofish

Without one single hickup.

(2) “Like-Butter” Development

I would like to get a central repo up. And create some firm standards
for branching and tagging.
Also, I want to improve the development toolset to make standard tasks
very simple, get the repo in such nice-and-neat order it’s freaky, and
eventually have some automated tools that keep us all well informed on
a regular basis.

(3) Doc Wizard

I want to find someone who’s willing to contribute considerable effort
to working on Nitro docs once we get passed the 0.50 release. I will
help on this of course, but it would be best to find someone who can
focus almost exclusively on this aspect of Nitro --this includes PR.
We’re looking at the Oxy, API Wiki, RDocs, the Website(s) and
hopefully in the end the first published book. (Did you catch that, a
BOOK! My job isn’t complete until there’s a BOOK.)

(4) Ruby 1.9/JRuby support

Around the end of the year I will start focusing on getting Nitro
running smoothly on Ruby 1.9 and JRuby, we will also have a try at
other VMs. YARV, Rubinius, IronRuby, etc.

(5) Support George

George is always pushing forward, so I’m going to bridge the gap
between him and a stable Nitro framework. While I also help him with
his more pressing needs, such as a new formhelper, admin part, etc.

As always, please provide all and any suggestions you have to offer,
and if you have time to put in some elbow greese, please let me know,
and I will hook you up.

In closing let me say, A VERY BIG THANKS TO GEORGE who has made this
opportunity possible!

T.

2

I want to help with number 3. I should have more time post Dec 1st.

Chris

3

I am super happy to announce that thanks to George I am now a
…
In closing let me say, A VERY BIG THANKS TO GEORGE who has made this
opportunity possible!

Let me just add that I am thrilled to have Tom more active in this
project.
I really hope that community/organization relation things will be
improved
now.

Hopefully, more people on this list how would like to use Nitro/Og for
commercial purposes
would think about supporting some nitro hackers with free time and the
will
(and capability) to work on improving
the platform.

regards,
George.

4

On 11/2/07, Trans [email protected] wrote:

I am super happy to announce that thanks to George I am now a
professional (as in cold hard cash, baby) Nitro developer! From now
on I will be heading up Nitro development along with George. My goal
is to push Nitro into a high quality 1.0 release as quickly as
possible. My priorities are:

Great news.
All of the following plans sound great too.
One question: About the plans re: Og?
There was mention that disentangling it from Nitro would encourage
people to use it in other contexts. Vote +1
I can confirm I’ve just had an exchange where the barrier was:
“From what I understood Og and Nitro are pretty much inseparable.”

Cheers
Mark

5

And we will make that very clear in coming weeks/months. Hell, lets be
clear now :wink: Nitro, is a whole web-framework stack that includes/uses
Og. Og does not include/use Nitro. Og can just as easily be used by
any other application independent of Nitro.

:))

6

On Nov 1, 6:30 pm, “Mark Van De Vyver” [email protected] wrote:

One question: About the plans re: Og?
There was mention that disentangling it from Nitro would encourage
people to use it in other contexts. Vote +1
I can confirm I’ve just had an exchange where the barrier was:
“From what I understood Og and Nitro are pretty much inseparable.”

And we will make that very clear in coming weeks/months. Hell, lets be
clear now :wink: Nitro, is a whole web-framework stack that includes/uses
Og. Og does not include/use Nitro. Og can just as easily be used by
any other application independent of Nitro.

T.

7

Trans wrote:

 $ nitro create ~/mynitroprojects/foofish
 $ nitro start ~/mynitroprojects/foofish

Without one single hickup.

The hiccup that makes me embarrassed to ask friends to try Nitro is that
request[] doesn’t work in OgAdminController#save. The scaffold makes
learning Nitro/Og a piece of cake – instant usefulness before getting
into hand-coding form.

Unfortunately:

ERROR: Error while handling OgAdminController#save()
ERROR: undefined method `[]’ for nil:NilClass

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/raw/lib/raw/context/request.rb:304:in
`[]’

/Users/rmela/nitro/repo.nitroproject.org/script/lib/…/…/nitro/lib/nitro/part/admin/og/controller.rb:93:in
`save’

Oddly enough, request[] works everywhere else. Maybe that will by my
puzzle for the week.

8

On Nov 1, 10:52 pm, Robert M. [email protected] wrote:

counterintuitive? I think it’s reasonable to think of headers and
params as collections, and for a programmer to expect them to expose the
same syntax.

Is there a reason for these to maintain order?

T.

9

Problem found. The correct fix for OgAdminController#save is not in
OgAdminController. It’s in Cgi#parse_params

Before a fix can be implemented there should be a decision as to whether
post and get params should be hash or dictionary.

Plain old POST request bodies are parsed using Cgi#parse_query_string (
sic ) and that returns a Dictonary:

context.post_params = parse_query_string(data)

Multipart form data is parsed using Cgi#parse_multipart, which returns a
Hash

context.post_params = parse_multipart(context, boundary)

… and which also conveniently contains the comment

#–

TODO: RECODE THIS CRAP!

#++

If a decision is reached that Dictionary is to be used for form data
then the following initializations in Context#initialize would need to
be changed:

@post_params = {}
@get_params = {}

So, having no shame, I’ll ask a stupid question: Why Dictionary for
request params? Also, does using Dictionary for some collection (
post/get params ) and Hash for others ( headers) risk being
counterintuitive? I think it’s reasonable to think of headers and
params as collections, and for a programmer to expect them to expose the
same syntax.

10

The hiccup that makes me embarrassed to ask friends to try Nitro is that

I will fix this.

-g.

11

Yeap,

I think it is needed for making this work:

def my_action(param1, param2)
end

I am not sure though…

-g.

12

I would hereby like to announce my candidacy for the position of Nitro
Doc Wizard.

Thanks Arne,

as I have already told you when we met, it is possible that I may be
able to
(financially) support more Nitro hackers in the near future.
but I would like to see some contribution first (that was the case with
Tom)
not just complaints.
hopefully, more people on this list could step in and support nitro
hackers.

regards,
George.

13

A very big congratulations to you for this certainly unique opportunity!

And also a big thank you to George for all the past effort and for
making this happen!

I would hereby like to announce my candidacy for the position of Nitro
Doc Wizard.

Regards,
(ab)

Trans schreef:

 $ gem install nitro

(2) “Like-Butter” Development
I want to find someone who’s willing to contribute considerable effort
running smoothly on Ruby 1.9 and JRuby, we will also have a try at
and I will hook you up.

–
Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]

14

Thanks, Arne.

I can offer about two hours per week – enough for a small section or to
review & test drive whats been written.

15

I’m really excited about this. There is already a buzz inside
ThoughtWorks
about this announcement. It would be great to see a genuine viable
alternative to the rails / active record world.

I see nitro having two significant advantages over rails:

  • It is just so easy to use. I really do struggle to get my head around
    rails. There is a surprising amount of hidden “tacit” knowledge required
    to
    become effective with rails, given that it is supposed to be entirely
    convention based. I describe it as the difference between struts and
    webwork
    (for anyone from a Java background). Struts was ok, and was the
    framework
    that made java a viable web technology, but webwork just feels nicer.
    (Ironically, “struts 2” is actually webwork 2 - so they eventually
    worked
    that out for themselves).

  • I can write a web app that talks to a legacy database. Og gives me a
    full
    ORM rather than requiring that I own the database. That opens up a whole
    class of web apps that are simply not available to a stack constrained
    to an
    active record pattern.

For my money (about $0.02), this would be my priority for getting nitro
“out
there”:

  • Documentation, documentation, documentation. It doesn’t have to be
    clever
    or comprehensive. Just a solid walk-through of creating an application.
    The
    answers are mostly there amongst the original videos, the cheat sheets
    and
    the tutorials. It just needs shaking down and presenting in a clear and
    consistent way. I would choose some “typical” users and target them.
    Initially target an experienced ruby programmer writing their first web
    app
    in nitro. Then something like a “nitro for rails developers” track.

  • Stability. (Funny enough, less important to me than being able to
    write an
    app in the first place.) I don’t mind if it has rough edges as long as
    the
    core stuff mostly works, and the mailing list is responsive to my
    stupidity.
    It’s pre-1.0 after all.

Cheers,
Dan

16

On Fri, 2007-11-02 at 10:33 -0400, Robert M. wrote:

I can offer about two hours per week – enough for a small section or
to
review & test drive whats been written.

i’d be willing to review and test drive also.

17

The Og/Legacy DB question offers a good use-case scenario for the
documentation process. It was next on my list for cheatsheets, so I’m
already willing to generate something.

So the use case is this – how do I generate that entry such that Arne
can easily integrate it into what he’s doing? Or should I just write a
cheatsheet now, and Arne or whoever can use it as input for their own
version of docs?

One scenario I envision is that Arne is Documentation Tsar. Generating
documentation himself, but also farming work out to other volunteers.
I’m willing to write submissions as they occur to me, write submissions
as per DocTsar requests, or do legwork and research, legwork, code
reading, and experimentation for things anyone else is thinking about
writing about.

So, let’s take Og and Legacy Databases as a use case scenario for a
documentation process and me as an example volunteer. How might a
process work?

18

On Nov 2, 2007, at 5:25 AM, Dan N. wrote:

  • Documentation, documentation, documentation. It doesn’t have to
    be clever or comprehensive. Just a solid walk-through of creating
    an application. The answers are mostly there amongst the original
    videos, the cheat sheets and the tutorials. It just needs shaking
    down and presenting in a clear and consistent way. I would choose
    some “typical” users and target them. Initially target an
    experienced ruby programmer writing their first web app in nitro.
    Then something like a “nitro for rails developers” track.

The documentation is the common thread, and the cure is twofold:

  • Yeah, write some cool new tutorial documentation. Something a
    person could do in a couple of hours that’s more than stupid-simple.
  • Find all the outdated documentation and encourage everyone who owns
    it to update it to current tools/standards

I keep looking at Nitro and Og and saying, “I want to do my next app
using Nitro and Og,” but they don’t sit still long enough for me to
build up any muscle memory. If a reasonably stable release appeared
and everyone went into “no new features, no api changes, no tool
changes” mode for a month or so, I believe it would help people who
now feel the Nitro/Og ecosystem is a bit slippery right now.

The other common thread is identifying the competition: Is it Rails?
Is it Merb or PLONE? Perhaps a more interesting thing to look at are
these questions:

  • What does do well?
  • What pisses people off about ?
  • Why could Nitro/Og do these things better?

I’ll get the ball rolling on this last bit.

  • Rails does greenfield apps incredibly well
  • Rails pisses off people who use FK constraints in their databases
  • Rails has nice generators and rake tasks
  • Rails routing pisses off people who have better things to debug
    that their routes
  • Rails has good hooks for alternative template languages
  • It would really piss me off not to have Haml and Sass
  • Rails is dirt simple to deploy with Capistrano
  • Buying extra memory for my server to run my keen new rails apps
    pisses me off
  • Rails makes testing a snap (and includes some support in generators
    and rake tasks)
  • Support of only Test::Unit pisses me off. I use rSpec.

I don’t know enough about Merb or PLONE to comment on them, but I’ll
betcha there are some things that people will swear are great and
others that expert users get pissed off over each time they bump into
them.

I’m sorry if this seems rambling, but what brought me to Rails was
that there were homegrown tutorials out there that worked. You could
gem install rails and there were no gem version conflicts. You could
rails foo and you got a foo app. You could script/generate scaffold
bar and you got a bar thingie. Migrations only made that better. Og
should be even more capable than that. The point is, everything
worked. And reliably. And in pre 1.0 versions. Nitro/Og’s friction
has been the “one thing broken” problem that stands in the way of
going straight through that AHA! tutorial experience.

–s

19

A B S O L U T E L Y !!

It is good to see firm structure and a sincere push to keep user level
documentation viable.

I love it!!

:slight_smile:

20

Hi gang

Personally speaking

i agree there must be a [START HERE] document like and induction set.

Secondly I prefer a cook book approach to the second level USER
documentation.

BOTH these would be backed by solid PROGRAMMER level documentation.

Cook books and the [START HERE] model can both work on useful use cases.

For example :: I made a web page with html from a book, now I want to
make a
site based on my ideas – How do I transfer my existing web to Nitro?
Some
of the suff oyx does :slight_smile:

I trust you find that useful.