From william.full.moon at gmail.com  Thu Nov  1 10:08:01 2007
From: william.full.moon at gmail.com (* William)
Date: Fri, 2 Nov 2007 01:08:01 +1100
Subject: [Nitro] Nitro + Facets 2.0
In-Reply-To: <4728B1DE.5040906@robmela.com>
References: <afd80b540710310747p4cc4f3bco29af78bef96edb6d@mail.gmail.com>
	<4728B1DE.5040906@robmela.com>
Message-ID: <9e03c3c60711010708k1bf52bbxef894da0e3848fd3@mail.gmail.com>

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 01/11/2007, Robert Mela <rob at 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/8d682539/attachment-0001.html 

From rob at robmela.com  Thu Nov  1 11:37:53 2007
From: rob at robmela.com (Robert Mela)
Date: Thu, 01 Nov 2007 11:37:53 -0400
Subject: [Nitro] Plone
In-Reply-To: <9e03c3c60711010708k1bf52bbxef894da0e3848fd3@mail.gmail.com>
References: <afd80b540710310747p4cc4f3bco29af78bef96edb6d@mail.gmail.com>	<4728B1DE.5040906@robmela.com>
	<9e03c3c60711010708k1bf52bbxef894da0e3848fd3@mail.gmail.com>
Message-ID: <4729F2D1.9070008@robmela.com>

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.





* William wrote:
> 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 01/11/2007, *Robert Mela* <rob at robmela.com 
> <mailto:rob at 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?
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071101/fb5e3ec8/attachment.vcf 

From transfire at gmail.com  Thu Nov  1 12:40:46 2007
From: transfire at gmail.com (Trans)
Date: Thu, 01 Nov 2007 16:40:46 -0000
Subject: [Nitro] Plone
In-Reply-To: <4729F2D1.9070008@robmela.com>
References: <afd80b540710310747p4cc4f3bco29af78bef96edb6d@mail.gmail.com>
	<4728B1DE.5040906@robmela.com>
	<9e03c3c60711010708k1bf52bbxef894da0e3848fd3@mail.gmail.com>
	<4729F2D1.9070008@robmela.com>
Message-ID: <1193935246.921383.100270@19g2000hsx.googlegroups.com>

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


From transfire at gmail.com  Thu Nov  1 13:18:28 2007
From: transfire at gmail.com (Trans)
Date: Thu, 01 Nov 2007 17:18:28 -0000
Subject: [Nitro] I, Nitro
Message-ID: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>

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.


From wyhaines at gmail.com  Thu Nov  1 13:43:46 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Thu, 1 Nov 2007 10:43:46 -0700
Subject: [Nitro] Plone
In-Reply-To: <1193935246.921383.100270@19g2000hsx.googlegroups.com>
References: <afd80b540710310747p4cc4f3bco29af78bef96edb6d@mail.gmail.com>
	<4728B1DE.5040906@robmela.com>
	<9e03c3c60711010708k1bf52bbxef894da0e3848fd3@mail.gmail.com>
	<4729F2D1.9070008@robmela.com>
	<1193935246.921383.100270@19g2000hsx.googlegroups.com>
Message-ID: <f4cd26df0711011043w260e3c4eq21d6c92291bc3e33@mail.gmail.com>

On 11/1/07, Trans <transfire at 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

From prpht9 at gmail.com  Thu Nov  1 14:05:06 2007
From: prpht9 at gmail.com (chris)
Date: Thu, 1 Nov 2007 14:05:06 -0400
Subject: [Nitro] I, Nitro
In-Reply-To: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
Message-ID: <c66aa6700711011105s66ce9f3ew96165145c65f758e@mail.gmail.com>

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

Chris

On 11/1/07, Trans <transfire at gmail.com> 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:
>
> (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.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071101/3db59d9e/attachment.html 

From george.moschovitis at gmail.com  Thu Nov  1 14:54:30 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Thu, 1 Nov 2007 20:54:30 +0200
Subject: [Nitro] I, Nitro
In-Reply-To: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
Message-ID: <afd80b540711011154p2eebc14ek194026c01430e558@mail.gmail.com>

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

-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071101/8e43a5d2/attachment.html 

From mvyver at gmail.com  Thu Nov  1 18:30:50 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 2 Nov 2007 09:30:50 +1100
Subject: [Nitro] I, Nitro
In-Reply-To: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
Message-ID: <389c43e40711011530o1cdc1809n585753a2ae0d8174@mail.gmail.com>

On 11/2/07, Trans <transfire at gmail.com> 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

> (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.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From mvyver at gmail.com  Thu Nov  1 18:46:51 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 2 Nov 2007 09:46:51 +1100
Subject: [Nitro] [Og] Og with Sequel
Message-ID: <389c43e40711011546x1f5c59a1jea91fc4c224a5d28@mail.gmail.com>

Hi,
I'm still in the process of working on a DBI adapter.
One thing I'm currently working on is trying to leverage off Sequel's
"non-Model" code.
Primarily to get to the Sequel::Dataset functionality and any other
useful features I come across along the way.
I've contact Sharon Rosen and she seemed more than happy to have
Sequel used in more contexts.

I'm working my way through trying to get Sequel specs working, and
well as trying to implement  some of the other changes/issues
discussed on this list (mainly the lower level method naming - which
turns out to be fortuitous because otherwise there would have been
some name clashes with Sequel).
I'm making notes and would hope to get to a point where the relevant
sequel modules/classes can be dropped into Og with as little effort as
possible.

At the moment I'm keeping as much of the changes in the
"./adapter/dbi" area as possible.
Naturally some things are starting to 'leak' out, mainly related to
options handling and this I had to do to be able to write some focused
specs.

Anyway, I suppose I'm asking for some feedback on:
Does this idea (Og+ Sequel) resonate with the community?

Cheers
Mark

From transfire at gmail.com  Thu Nov  1 20:25:31 2007
From: transfire at gmail.com (Trans)
Date: Fri, 02 Nov 2007 00:25:31 -0000
Subject: [Nitro] I, Nitro
In-Reply-To: <389c43e40711011530o1cdc1809n585753a2ae0d8174@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<389c43e40711011530o1cdc1809n585753a2ae0d8174@mail.gmail.com>
Message-ID: <1193963131.839522.57650@y42g2000hsy.googlegroups.com>



On Nov 1, 6:30 pm, "Mark Van De Vyver" <mvy... at gmail.com> wrote:
> On 11/2/07, Trans <transf... at gmail.com> 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."

And we will make that very clear in coming weeks/months. Hell, lets be
clear now ;) 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.


From mvyver at gmail.com  Thu Nov  1 21:26:40 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Fri, 2 Nov 2007 12:26:40 +1100
Subject: [Nitro] I, Nitro
In-Reply-To: <1193963131.839522.57650@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<389c43e40711011530o1cdc1809n585753a2ae0d8174@mail.gmail.com>
	<1193963131.839522.57650@y42g2000hsy.googlegroups.com>
Message-ID: <389c43e40711011826u39174950j23d43f0463c35cd9@mail.gmail.com>

> And we will make that very clear in coming weeks/months. Hell, lets be
> clear now ;) 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.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From rob at robmela.com  Thu Nov  1 21:58:10 2007
From: rob at robmela.com (Robert Mela)
Date: Thu, 01 Nov 2007 21:58:10 -0400
Subject: [Nitro] I, Nitro
In-Reply-To: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
Message-ID: <472A8432.7000904@robmela.com>

Trans wrote:
> (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.
>   

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071101/6c956d91/attachment.vcf 

From rob at robmela.com  Thu Nov  1 22:52:30 2007
From: rob at robmela.com (Robert Mela)
Date: Thu, 01 Nov 2007 22:52:30 -0400
Subject: [Nitro] Solved: OgAdminController#save is not the problem....
In-Reply-To: <472A8432.7000904@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472A8432.7000904@robmela.com>
Message-ID: <472A90EE.1020303@robmela.com>

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071101/194fe6b0/attachment.vcf 

From transfire at gmail.com  Thu Nov  1 23:45:57 2007
From: transfire at gmail.com (Trans)
Date: Fri, 02 Nov 2007 03:45:57 -0000
Subject: [Nitro] Solved: OgAdminController#save is not the problem....
In-Reply-To: <472A90EE.1020303@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472A8432.7000904@robmela.com> <472A90EE.1020303@robmela.com>
Message-ID: <1193975157.994036.154610@o80g2000hse.googlegroups.com>



On Nov 1, 10:52 pm, Robert Mela <r... at robmela.com> wrote:
> 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.

Is there a reason for these to maintain order?

T.


From george.moschovitis at gmail.com  Fri Nov  2 02:14:31 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 2 Nov 2007 08:14:31 +0200
Subject: [Nitro] I, Nitro
In-Reply-To: <472A8432.7000904@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472A8432.7000904@robmela.com>
Message-ID: <afd80b540711012314s57cc1b99y84ddc8b383f63e3e@mail.gmail.com>

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

I will fix this.

-g.


-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/2b50db49/attachment.html 

From george.moschovitis at gmail.com  Fri Nov  2 02:16:38 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 2 Nov 2007 08:16:38 +0200
Subject: [Nitro] Solved: OgAdminController#save is not the problem....
In-Reply-To: <1193975157.994036.154610@o80g2000hse.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472A8432.7000904@robmela.com> <472A90EE.1020303@robmela.com>
	<1193975157.994036.154610@o80g2000hse.googlegroups.com>
Message-ID: <afd80b540711012316g2f45fc78naa1201c1fa74e2a0@mail.gmail.com>

Yeap,

I think it is needed for making this work:

def my_action(param1, param2)
end

I am not sure though...

-g.


On Nov 2, 2007 5:45 AM, Trans <transfire at gmail.com> wrote:

>
>
> On Nov 1, 10:52 pm, Robert Mela <r... at robmela.com> wrote:
> > 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.
>
> Is there a reason for these to maintain order?
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/830ba6d4/attachment.html 

From arne at arnebrasseur.net  Fri Nov  2 05:09:04 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Fri, 02 Nov 2007 17:09:04 +0800
Subject: [Nitro] I, Nitro
In-Reply-To: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
Message-ID: <472AE930.1030509@arnebrasseur.net>

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:
> 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.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>   


-- 
Arne Brasseur
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
arne at arnebrasseur.net


From george.moschovitis at gmail.com  Fri Nov  2 06:38:16 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Fri, 2 Nov 2007 12:38:16 +0200
Subject: [Nitro] I, Nitro
In-Reply-To: <472AE930.1030509@arnebrasseur.net>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
Message-ID: <afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>

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


-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/6cc4c53c/attachment.html 

From tastapod at gmail.com  Fri Nov  2 08:25:16 2007
From: tastapod at gmail.com (Dan North)
Date: Fri, 2 Nov 2007 12:25:16 +0000
Subject: [Nitro] I, Nitro
In-Reply-To: <afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
Message-ID: <d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>

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


On 11/2/07, George Moschovitis <george.moschovitis at gmail.com> wrote:
>
> 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.
>
>
> --
> http://me.gr
> http://joy.gr
> http://cull.gr
> http://nitroproject.org
> http://phidz.com
> http://joyerz.com
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/591d1758/attachment.html 

From rob at robmela.com  Fri Nov  2 10:33:49 2007
From: rob at robmela.com (Robert Mela)
Date: Fri, 02 Nov 2007 10:33:49 -0400
Subject: [Nitro] Doc Wizard
In-Reply-To: <472AE930.1030509@arnebrasseur.net>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
Message-ID: <472B354D.6000509@robmela.com>

Thanks, Arne.

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

Arne Brasseur wrote:
> 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:
>   
>> 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.
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>>
>>   
>>     
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071102/fc2bcf43/attachment.vcf 

From Reid.Thompson at ateb.com  Fri Nov  2 10:45:54 2007
From: Reid.Thompson at ateb.com (Reid Thompson)
Date: Fri, 02 Nov 2007 10:45:54 -0400
Subject: [Nitro] Doc Wizard
In-Reply-To: <472B354D.6000509@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>  <472B354D.6000509@robmela.com>
Message-ID: <1194014754.3941.25.camel@raker.ateb.com>


On Fri, 2007-11-02 at 10:33 -0400, Robert Mela 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.  

From rob at robmela.com  Fri Nov  2 12:07:11 2007
From: rob at robmela.com (Robert Mela)
Date: Fri, 02 Nov 2007 12:07:11 -0400
Subject: [Nitro] Documentation Documentation
In-Reply-To: <d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
Message-ID: <472B4B2F.9010709@robmela.com>

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?

Dan North wrote:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071102/b50683a5/attachment.vcf 

From mvyver at gmail.com  Fri Nov  2 15:26:11 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 3 Nov 2007 06:26:11 +1100
Subject: [Nitro] [OG] RFC uri structure
Message-ID: <389c43e40711021226o25ed3d43gd5103bd78bb1b15e@mail.gmail.com>

Hi Devs,
The Sequel/Datasets thread was ominously silent - nonetheless pushing ahead.

If you were able to start Og in the following way:
Og(uri)

What would be the preferred uri format:
a) "dbi-<vendor>://user:pass at localhost:9876/dbname#<vendor>driveroptions"
b) "dbi:<vendor>://user:pass at localhost:9876/dbname#<vendor>driveroptions"
c) both
d) neither (please tell/suggest)

Some notes:
- "DBI" and <vendor> would be case insensitive.
- Not all arguments are 'required'.  The following would work (assuming (a)),
"DBI-mysql:///testdb"
and even
"dbi:///testdb"
In that missing arguments would employ the defaults as specific by the
settings in og.rb.

Regards
Mark

From transfire at gmail.com  Fri Nov  2 18:11:19 2007
From: transfire at gmail.com (Trans)
Date: Fri, 02 Nov 2007 22:11:19 -0000
Subject: [Nitro] [Og] Og with Sequel
In-Reply-To: <389c43e40711011546x1f5c59a1jea91fc4c224a5d28@mail.gmail.com>
References: <389c43e40711011546x1f5c59a1jea91fc4c224a5d28@mail.gmail.com>
Message-ID: <1194041479.267358.208620@z9g2000hsf.googlegroups.com>



On Nov 1, 6:46 pm, "Mark Van De Vyver" <mvy... at gmail.com> wrote:
> Hi,
> I'm still in the process of working on a DBI adapter.
> One thing I'm currently working on is trying to leverage off Sequel's
> "non-Model" code.
> Primarily to get to the Sequel::Dataset functionality and any other
> useful features I come across along the way.
> I've contact Sharon Rosen and she seemed more than happy to have
> Sequel used in more contexts.
>
> I'm working my way through trying to get Sequel specs working, and
> well as trying to implement  some of the other changes/issues
> discussed on this list (mainly the lower level method naming - which
> turns out to be fortuitous because otherwise there would have been
> some name clashes with Sequel).
> I'm making notes and would hope to get to a point where the relevant
> sequel modules/classes can be dropped into Og with as little effort as
> possible.
>
> At the moment I'm keeping as much of the changes in the
> "./adapter/dbi" area as possible.
> Naturally some things are starting to 'leak' out, mainly related to
> options handling and this I had to do to be able to write some focused
> specs.
>
> Anyway, I suppose I'm asking for some feedback on:
> Does this idea (Og+ Sequel) resonate with the community?

I'm not sure I understand. But I may misunderstand Sequel. Aren't
Sequel and Og two different approaches to the same task? How can they
work together? If you are creating a DBI adapter, what does Sequel
have to do with that?

T.


From mvyver at gmail.com  Fri Nov  2 18:56:53 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 3 Nov 2007 09:56:53 +1100
Subject: [Nitro] [Og] Og with Sequel
In-Reply-To: <1194041479.267358.208620@z9g2000hsf.googlegroups.com>
References: <389c43e40711011546x1f5c59a1jea91fc4c224a5d28@mail.gmail.com>
	<1194041479.267358.208620@z9g2000hsf.googlegroups.com>
Message-ID: <389c43e40711021556k28265230s1abd90634360d203@mail.gmail.com>

On Nov 3, 2007 9:11 AM, Trans <transfire at gmail.com> wrote:
>
>
>
> On Nov 1, 6:46 pm, "Mark Van De Vyver" <mvy... at gmail.com> wrote:
> > Hi,
> > I'm still in the process of working on a DBI adapter.
> > One thing I'm currently working on is trying to leverage off Sequel's
> > "non-Model" code.
> > Primarily to get to the Sequel::Dataset functionality and any other
> > useful features I come across along the way.
> > I've contact Sharon Rosen and she seemed more than happy to have
> > Sequel used in more contexts.
> >
> > I'm working my way through trying to get Sequel specs working, and
> > well as trying to implement  some of the other changes/issues
> > discussed on this list (mainly the lower level method naming - which
> > turns out to be fortuitous because otherwise there would have been
> > some name clashes with Sequel).
> > I'm making notes and would hope to get to a point where the relevant
> > sequel modules/classes can be dropped into Og with as little effort as
> > possible.
> >
> > At the moment I'm keeping as much of the changes in the
> > "./adapter/dbi" area as possible.
> > Naturally some things are starting to 'leak' out, mainly related to
> > options handling and this I had to do to be able to write some focused
> > specs.
> >
> > Anyway, I suppose I'm asking for some feedback on:
> > Does this idea (Og+ Sequel) resonate with the community?
>
> I'm not sure I understand. But I may misunderstand Sequel. Aren't
> Sequel and Og two different approaches to the same task? How can they
> work together? If you are creating a DBI adapter, what does Sequel
> have to do with that?

They really differ on their approach to *::Model.
It is possible to share much of the SQL adapter code (in Sequel this
is Sequel::Database), SQL generation (Sequel seems ahead here).

I'm most interested in 'piggy-backing' on the Sequel::Dataset, which
Og does not have as advanced.  There is ready built/tested
Sequel::Dataset functionality that seems fine to me, and it seems to
make sense to try and share these semantics (Og::Dataset) - both
projects can feedback to each other on this.

Given that Dataset is what I'd like to have in common, I'm trying at
the moment to share some of the low level DbiAdapter/Database methods
(e.g it seems to have better pooling/threading management).  This is
mostly below the user level, but it seems it can be done.

It is early days yet but it looks promising.

So this is more about trying to share the Dataset interface, and
trying to implement what it takes to get that done.

Hope that is clearer?

Mark

> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From cwdinfo at gmail.com  Fri Nov  2 20:23:10 2007
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 2 Nov 2007 17:23:10 -0700
Subject: [Nitro] I, Nitro
In-Reply-To: <d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
Message-ID: <50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>

On Nov 2, 2007, at 5:25 AM, Dan North 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 <insert framework name here> do well?
- What pisses people off about <insert framework name here>?
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071102/1ec79709/attachment.html 

From transfire at gmail.com  Fri Nov  2 21:29:39 2007
From: transfire at gmail.com (Trans)
Date: Sat, 03 Nov 2007 01:29:39 -0000
Subject: [Nitro] Documentation Documentation
In-Reply-To: <472B4B2F.9010709@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<472B4B2F.9010709@robmela.com>
Message-ID: <1194053379.425543.87550@v3g2000hsg.googlegroups.com>



On Nov 2, 12:07 pm, Robert Mela <r... at robmela.com> wrote:
> 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?

That's a good question.

First let me say though that I am pleased to see so much interest in
this thread, and especially volunteers for writing documentation.
Clearly there remains real interest in Nitro as an alternative to
Rails and other LAMP frameworks.

Before we can really start digging our heals in with docs though, we
need to get 0.50 out. 0.50 will serve as our first weigh station for a
stable API. At that time I will workout a more specific documentation
strategy. In the mean time, it would be useful to discuss the general
ideas of how a good doc process would work. And I think your question
goes directly to the heart of the matter.

I would say the first thing to do is check with community and head
developers to see if such a documentation case is already out there or
in the works. If it is, it may be better to help improve that, rather
then start another. But lets say there isn't and the community
feedback is positive. Then the next thing to do is sketch a tutorial,
be sure to work through it a few times to polish it up, and the post
that to Oxy. Now that may be as far as it goes, which is fine --the
tutorial has contributed to the Nitro knowledgebase. However,
depending on the case, the tutorial might be able to go further and
turn into a section of The Book.

Of course, maybe you don't want to do a tutorial and just want to make
a cheatsheet. Thats cool too. I think maybe adding a cheatsheet
section to Oxy would be a good idea. It would be interesting to see
how much we could turn something like this into an assembly processes.
Could one person create a text-based cheatsheet and another turn that
into a really snazzy graphical cheatsheet, or a screencast?

At the same time, the Doc lead(s) might read this material and use
some information in it to "back-improve" RDocs (which are docs for
programmers) or the API wiki (low-level docs for end users). They
would also be responsible for seeing that information on Oxy stays up-
to-date, well formatted, etc.

Ok. That's just my first rough thoughts, on the matter. Yours?

T.


From william.full.moon at gmail.com  Fri Nov  2 21:34:56 2007
From: william.full.moon at gmail.com (* William)
Date: Sat, 3 Nov 2007 12:34:56 +1100
Subject: [Nitro] I, Nitro
In-Reply-To: <472AE930.1030509@arnebrasseur.net>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
Message-ID: <9e03c3c60711021834v7649c322h2059692cc0344b4a@mail.gmail.com>

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

:-)

On 02/11/2007, Arne Brasseur <arne at arnebrasseur.net> wrote:
>
> 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/976078e3/attachment.html 

From william.full.moon at gmail.com  Fri Nov  2 21:40:41 2007
From: william.full.moon at gmail.com (* William)
Date: Sat, 3 Nov 2007 12:40:41 +1100
Subject: [Nitro] I, Nitro
In-Reply-To: <50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
Message-ID: <9e03c3c60711021840i1be4c187saadac94158003db2@mail.gmail.com>

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 :-)

I trust you find that useful.


On 03/11/2007, s.ross <cwdinfo at gmail.com> wrote:
>
> On Nov 2, 2007, at 5:25 AM, Dan North 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/2f433989/attachment.html 

From mvyver at gmail.com  Sat Nov  3 02:51:16 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 3 Nov 2007 17:51:16 +1100
Subject: [Nitro] Documentation Documentation
In-Reply-To: <1194053379.425543.87550@v3g2000hsg.googlegroups.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<472B4B2F.9010709@robmela.com>
	<1194053379.425543.87550@v3g2000hsg.googlegroups.com>
Message-ID: <389c43e40711022351t77514ea3ldd9a10ffc358423b@mail.gmail.com>

A couple of thoughts

On Nov 3, 2007 12:29 PM, Trans <transfire at gmail.com> wrote:
>
>
> On Nov 2, 12:07 pm, Robert Mela <r... at robmela.com> wrote:
> > 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*.
> >

<snip>

> > 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?
>
> That's a good question.
>
> First let me say though that I am pleased to see so much interest in
> this thread, and especially volunteers for writing documentation.
> Clearly there remains real interest in Nitro as an alternative to
> Rails and other LAMP frameworks.
>
> Before we can really start digging our heals in with docs though, we
> need to get 0.50 out. 0.50 will serve as our first weigh station for a
> stable API. At that time I will workout a more specific documentation

Possibly off topic, maybe of interest, but worth stating explicitly -
I won't have the DBI adapter ready for the 0.50 release.

> strategy. In the mean time, it would be useful to discuss the general
> ideas of how a good doc process would work. And I think your question
> goes directly to the heart of the matter.
>
> I would say the first thing to do is check with community and head
> developers to see if such a documentation case is already out there or
> in the works. If it is, it may be better to help improve that, rather
> then start another. But lets say there isn't and the community
> feedback is positive. Then the next thing to do is sketch a tutorial,
> be sure to work through it a few times to polish it up, and the post
> that to Oxy. Now that may be as far as it goes, which is fine --the
> tutorial has contributed to the Nitro knowledgebase. However,
> depending on the case, the tutorial might be able to go further and
> turn into a section of The Book.
>
> Of course, maybe you don't want to do a tutorial and just want to make
> a cheatsheet. Thats cool too. I think maybe adding a cheatsheet
> section to Oxy would be a good idea. It would be interesting to see

I think a cheat-sheet should be reasonable prominent, if it is task
oriented. Examples I like are the Sequel cheat sheet on their wiki
http://code.google.com/p/ruby-sequel/wiki/CheatSheet
and
the layout of the flexmock readme (early example and then cheat sheet)
http://onestepback.org/software/flexmock/

IMHO the Sequel style cheat sheet could fill in the place of the flex
mock 'Quick Reference'.
It can be :include: <common_cheatsheet.file>.
This would mean every copy of the Nitro/Og would have a local copy?
I think it is worth some thought/effort to keep the RDoc and 'other'
versions of this section common.

> how much we could turn something like this into an assembly processes.
> Could one person create a text-based

(or one in the RDoc readme?)

> cheatsheet and another turn that
> into a really snazzy graphical cheatsheet, or a screencast?
>
> At the same time, the Doc lead(s) might read this material and use

the cheat sheet directly, and use

> some information in it to "back-improve" RDocs (which are docs for
> programmers) or the API wiki (low-level docs for end users). They
> would also be responsible for seeing that information on Oxy stays up-
> to-date, well formatted, etc.

It'd be great to try and find some way of keeping the docs as common
as possible, but apart from :include: in RDoc I'm not sure what else
can be done.

I'm not very familiar with AR so do not know of a 'well/widely-know'
cheat sheet.  If there is one, mimicking it sturcture (assuming it is
good/reasonable), would be a natural way of indirectly comparing AR to
Og?

HTH
Mark

> Ok. That's just my first rough thoughts, on the matter. Yours?
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From mvyver at gmail.com  Sat Nov  3 03:10:13 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 3 Nov 2007 18:10:13 +1100
Subject: [Nitro] Nitro/Og cheat sheet styles/ideas/levels....
Message-ID: <389c43e40711030010u313b8c98qa553ced7e8fcaabb@mail.gmail.com>

Hi Devs,
One issues the following examples raise is what is the level the cheat
sheet is aimed at? 'Beginner howto cheat sheet' vs 'Reference cheat
sheet'
Even if there is initially only be one, later there will liley be
more, so it seems worth thinking about nomenclature.
kicking this off with Og since that seems to be the first to be tackled:
Cheat sheets:
 - Og-howto
 - Og-reference

Question:
 Which of these cheat sheets are we starting on?

Existing examples/ideas
Some information packed (reference) cheat sheet examples (for ideas):
http://www.ilovejackdaniels.com/cheat-sheets/ruby-on-rails-cheat-sheet/

Some more 'graphical' ones (beginner/explaining ideas)
http://www.ahoyhere.com/cheats/activerecord_cheatsheet.pdf
http://www.ahoyhere.com/cheats/rails_files_cheatsheet.pdf

From mvyver at gmail.com  Sat Nov  3 03:17:40 2007
From: mvyver at gmail.com (Mark Van De Vyver)
Date: Sat, 3 Nov 2007 18:17:40 +1100
Subject: [Nitro] I, Nitro
In-Reply-To: <9e03c3c60711021840i1be4c187saadac94158003db2@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
	<9e03c3c60711021840i1be4c187saadac94158003db2@mail.gmail.com>
Message-ID: <389c43e40711030017w9167d41kcca65679184f66bc@mail.gmail.com>

On Nov 3, 2007 12:40 PM, * William <william.full.moon at gmail.com> wrote:
> Hi gang
>
> Personally speaking
>
> i agree there must be a [START HERE] document like and induction set.

agreed and at the risk of repeating myself ;) I think this
'introduction level information' is best done in the readme file,
which can be duplicated elsewhere, but the readme version should be
the reference point?
More extensive introductory material/howto can be refereed to.

> Secondly I prefer a cook book approach to the second level USER
> documentation.
>
> BOTH these would be backed by solid PROGRAMMER level documentation.

Agreed.  In fact since I always have the pickaxe book and the Ruby
cookbook on my desk I'd say that, for me, the best documentation
(book) would be the Ruby cookbook with the pickaxe appendices.
Is this a longer term target/structure worth setting and aiming for?
It would kill the two birds with one document/book.

HTH
Mark
>
> 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 :-)
>
> I trust you find that useful.
>
>
>
>
> On 03/11/2007, s.ross <cwdinfo at gmail.com> wrote:
> >
> >
> >
> > On Nov 2, 2007, at 5:25 AM, Dan North 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
> >
> >
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>

From rob at robmela.com  Sat Nov  3 10:48:09 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 10:48:09 -0400
Subject: [Nitro] I, Nitro
In-Reply-To: <389c43e40711030017w9167d41kcca65679184f66bc@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>	<9e03c3c60711021840i1be4c187saadac94158003db2@mail.gmail.com>
	<389c43e40711030017w9167d41kcca65679184f66bc@mail.gmail.com>
Message-ID: <472C8A29.4010803@robmela.com>

We need to draw up a list of *what* formats we want to target.

A (START HERE) at the README RDoc level is a great idea.  A README.intro 
alongside the current README.og and README.raw.

What are the goals?

 -- install Nitro
 -- verify that it works
 -- proove:  useful common things are really simple in Nitro

If those are the goals, does this achieve them:


Intro I ( README.intro )
 - single-file app ( with Controller and Dispatcher )
 - starting and stopping
- canonical hello world app
   . nitro --create
   . a template
   . a controller
   . an element

Intro II ( Og ) ( README.intro2 )
  - Library example ( Book and Author ), using admin part
   ( or something similarly simple but more exciting )

Intro III (? or maybe this belongs in a tutorial )
   - Add a simple form to Intro II

At this point it's pushing the limits to becoming a tutorial...






Mark Van De Vyver wrote:
> On Nov 3, 2007 12:40 PM, * William <william.full.moon at gmail.com> wrote:
>   
>> Hi gang
>>
>> Personally speaking
>>
>> i agree there must be a [START HERE] document like and induction set.
>>     
>
> agreed and at the risk of repeating myself ;) I think this
> 'introduction level information' is best done in the readme file,
> which can be duplicated elsewhere, but the readme version should be
> the reference point?
> More extensive introductory material/howto can be refereed to.
>
>   
>> Secondly I prefer a cook book approach to the second level USER
>> documentation.
>>
>> BOTH these would be backed by solid PROGRAMMER level documentation.
>>     
>
> Agreed.  In fact since I always have the pickaxe book and the Ruby
> cookbook on my desk I'd say that, for me, the best documentation
> (book) would be the Ruby cookbook with the pickaxe appendices.
> Is this a longer term target/structure worth setting and aiming for?
> It would kill the two birds with one document/book.
>
> HTH
> Mark
>   
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/04fcb98a/attachment.vcf 

From rob at robmela.com  Sat Nov  3 10:56:10 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 10:56:10 -0400
Subject: [Nitro] I, Nitro
In-Reply-To: <50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
Message-ID: <472C8C0A.4020008@robmela.com>

What's a "greenfield" app?

Also -- not sure I'd want to enter competition with Rails and risk flame 
wars and all.... is it possible to talk about what Nitro does, with 
examples, and leave it at that?

s.ross wrote:
>
>
> 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 <insert framework name here> do well?
> - What pisses people off about <insert framework name here>?
> - Why could Nitro/Og do these things better?
>
> I'll get the ball rolling on this last bit.
>
> - Rails does greenfield apps incredibly well

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/9f6649ac/attachment.vcf 

From rob at robmela.com  Sat Nov  3 12:10:38 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 12:10:38 -0400
Subject: [Nitro] Nitro/Og cheat sheet styles/ideas/levels....
In-Reply-To: <389c43e40711030010u313b8c98qa553ced7e8fcaabb@mail.gmail.com>
References: <389c43e40711030010u313b8c98qa553ced7e8fcaabb@mail.gmail.com>
Message-ID: <472C9D7E.3090106@robmela.com>

I would first ask what is it we want to produce.  In other words:

1) What topics need to be covered
3) A list of use cases and the format that serves each


#1 would require input from George and Tom -- it would leverage their 
time really well.   This could start before documentation does.  

Reflexively, based on past experience, I see these three formats.  It 
should be reexamined with use cases:

1) Tutorial
2) Reference ( Quick vs Complete )
3) Book

My fault as an engineer is prematurely jumping to nuts-and-bolts 
"How".    This is a tangent -- but I'd love to see a design for reusable 
components that each format can built itself from -- e.g., a Topic 
class, with CodeExample, Synopsis, RelatedTopics.

Finally, it makes sense in all of this to see what's been done 
elsewhere, and for people like me to spend more time reading through Oxy 
and look at other docs we like.

Mark's suggested these, and I think Tom's suggested others (so much 
going on here -- time to collate the major points on a wiki ?

http://www.ilovejackdaniels.com/cheat-sheets/ruby-on-rails-cheat-sheet/
http://www.ahoyhere.com/cheats/activerecord_cheatsheet.pdf
http://www.ahoyhere.com/cheats/rails_files_cheatsheet.pdf



Mark Van De Vyver wrote:
> Hi Devs,
> One issues the following examples raise is what is the level the cheat
> sheet is aimed at? 'Beginner howto cheat sheet' vs 'Reference cheat
> sheet'
> Even if there is initially only be one, later there will liley be
> more, so it seems worth thinking about nomenclature.
> kicking this off with Og since that seems to be the first to be tackled:
> Cheat sheets:
>  - Og-howto
>  - Og-reference
>
> Question:
>  Which of these cheat sheets are we starting on?
>
> Existing examples/ideas
> Some information packed (reference) cheat sheet examples (for ideas):
> http://www.ilovejackdaniels.com/cheat-sheets/ruby-on-rails-cheat-sheet/
>
> Some more 'graphical' ones (beginner/explaining ideas)
> http://www.ahoyhere.com/cheats/activerecord_cheatsheet.pdf
> http://www.ahoyhere.com/cheats/rails_files_cheatsheet.pdf
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/152464e1/attachment.vcf 

From rob at robmela.com  Sat Nov  3 12:11:40 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 12:11:40 -0400
Subject: [Nitro] Sorry -- scracth that first sentence
In-Reply-To: <472C8A29.4010803@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>	<9e03c3c60711021840i1be4c187saadac94158003db2@mail.gmail.com>	<389c43e40711030017w9167d41kcca65679184f66bc@mail.gmail.com>
	<472C8A29.4010803@robmela.com>
Message-ID: <472C9DBC.308@robmela.com>

Forgot to delete the first spurious sentence -- writing this while 
serving part-time as climbing structure for a three year old.
Robert Mela wrote:
> We need to draw up a list of *what* formats we want to target.
>
> A (START HERE) at the README RDoc level is a great idea.  A 
> README.intro alongside the current README.og and README.raw.
>
> What are the goals?
>
> -- install Nitro
> -- verify that it works
> -- proove:  useful common things are really simple in Nitro
>
> If those are the goals, does this achieve them:
>
>
> Intro I ( README.intro )
> - single-file app ( with Controller and Dispatcher )
> - starting and stopping
> - canonical hello world app
>   . nitro --create
>   . a template
>   . a controller
>   . an element
>
> Intro II ( Og ) ( README.intro2 )
>  - Library example ( Book and Author ), using admin part
>   ( or something similarly simple but more exciting )
>
> Intro III (? or maybe this belongs in a tutorial )
>   - Add a simple form to Intro II
>
> At this point it's pushing the limits to becoming a tutorial...
>
>
>
>
>
>
> Mark Van De Vyver wrote:
>> On Nov 3, 2007 12:40 PM, * William <william.full.moon at gmail.com> wrote:
>>  
>>> Hi gang
>>>
>>> Personally speaking
>>>
>>> i agree there must be a [START HERE] document like and induction set.
>>>     
>>
>> agreed and at the risk of repeating myself ;) I think this
>> 'introduction level information' is best done in the readme file,
>> which can be duplicated elsewhere, but the readme version should be
>> the reference point?
>> More extensive introductory material/howto can be refereed to.
>>
>>  
>>> Secondly I prefer a cook book approach to the second level USER
>>> documentation.
>>>
>>> BOTH these would be backed by solid PROGRAMMER level documentation.
>>>     
>>
>> Agreed.  In fact since I always have the pickaxe book and the Ruby
>> cookbook on my desk I'd say that, for me, the best documentation
>> (book) would be the Ruby cookbook with the pickaxe appendices.
>> Is this a longer term target/structure worth setting and aiming for?
>> It would kill the two birds with one document/book.
>>
>> HTH
>> Mark
>>  
>>
>>   
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/ab627477/attachment.vcf 

From cwdinfo at gmail.com  Sat Nov  3 13:06:08 2007
From: cwdinfo at gmail.com (s.ross)
Date: Sat, 3 Nov 2007 10:06:08 -0700
Subject: [Nitro] I, Nitro
In-Reply-To: <472C8C0A.4020008@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<50C5CD31-4D2B-43FE-9968-8810A4CAB10C@gmail.com>
	<472C8C0A.4020008@robmela.com>
Message-ID: <7E8C4A3D-ACB7-41DD-8FFD-7B52127361DC@gmail.com>

On Nov 3, 2007, at 7:56 AM, Robert Mela wrote:

> What's a "greenfield" app?

 From scratch: http://en.wikipedia.org/wiki/Greenfield_project.

> Also -- not sure I'd want to enter competition with Rails and risk  
> flame wars and all.... is it possible to talk about what Nitro  
> does, with examples, and leave it at that?

Don't get me wrong. I love Rails. It's all I use now. But the risk of  
not acknowledging history for new endeavors is that you will repeat  
it. No flame wars intended, but there are places where even Rails  
doesn't fit well.

> s.ross wrote:
>>
>>
>> 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 <insert framework name here> do well?
>> - What pisses people off about <insert framework name here>?
>> - Why could Nitro/Og do these things better?
>>
>> I'll get the ball rolling on this last bit.
>>
>> - Rails does greenfield apps incredibly well
>
> <rob.vcf>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general


From cwdinfo at gmail.com  Sat Nov  3 13:07:41 2007
From: cwdinfo at gmail.com (s.ross)
Date: Sat, 3 Nov 2007 10:07:41 -0700
Subject: [Nitro] Documentation Documentation
In-Reply-To: <389c43e40711022351t77514ea3ldd9a10ffc358423b@mail.gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<472B4B2F.9010709@robmela.com>
	<1194053379.425543.87550@v3g2000hsg.googlegroups.com>
	<389c43e40711022351t77514ea3ldd9a10ffc358423b@mail.gmail.com>
Message-ID: <36CEAEC3-2D34-4E77-A738-A80849291517@gmail.com>

One nice "up and running" tutorial for Rails is this:

http://rails.homelinux.org/

It's a bit dated by now, but covered out-of-the-box Rails experience.

Hope this helps.

From george.moschovitis at gmail.com  Sat Nov  3 13:22:02 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 3 Nov 2007 19:22:02 +0200
Subject: [Nitro] [OG] RFC uri structure
In-Reply-To: <389c43e40711021226o25ed3d43gd5103bd78bb1b15e@mail.gmail.com>
References: <389c43e40711021226o25ed3d43gd5103bd78bb1b15e@mail.gmail.com>
Message-ID: <afd80b540711031022y593b5895v680e094b849c197c@mail.gmail.com>

I would say

dbi-vendor...

-g.

On Nov 2, 2007 9:26 PM, Mark Van De Vyver <mvyver at gmail.com> wrote:

> Hi Devs,
> The Sequel/Datasets thread was ominously silent - nonetheless pushing
> ahead.
>
> If you were able to start Og in the following way:
> Og(uri)
>
> What would be the preferred uri format:
> a) "dbi-<vendor>://user:pass at localhost:9876/dbname#<vendor>driveroptions"
> b) "dbi:<vendor>://user:pass at localhost:9876/dbname#<vendor>driveroptions"
> c) both
> d) neither (please tell/suggest)
>
> Some notes:
> - "DBI" and <vendor> would be case insensitive.
> - Not all arguments are 'required'.  The following would work (assuming
> (a)),
> "DBI-mysql:///testdb"
> and even
> "dbi:///testdb"
> In that missing arguments would employ the defaults as specific by the
> settings in og.rb.
>
> Regards
> Mark
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/68df5042/attachment.html 

From george.moschovitis at gmail.com  Sat Nov  3 13:41:46 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 3 Nov 2007 19:41:46 +0200
Subject: [Nitro] Nitro + Facets 2.0.3
Message-ID: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>

Dear devs,

the branch version (http://repo.nitroproject.org/branch) works with Facets
2.0.3

please download it and test :)

-g.

PS: kudos to Tom for this one...

-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/d604d711/attachment.html 

From rob at robmela.com  Sat Nov  3 15:25:27 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 15:25:27 -0400
Subject: [Nitro] Nitro + Facets 2.0.3
In-Reply-To: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
Message-ID: <472CCB27.9000906@robmela.com>

There's a million gems on RubyForge that could match this -- so I'll 
just ask -- what gem am I missing?

   Console::Command::Options

Gemspec dependencies need updating ( just from eyeballing the files ).   
At various points I recall installing
 
  - xml-simple ( ? )
  - uuidtools
  - sources ?
  - facets 1.8.54 and now 2.0.2

Not sure if mongrel is a dependency or not -- I should try removing it 
and running with the webrick adapter.



/Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application/args.rb:7: 
uninitialized constant Console::Command::Options (NameError)
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require'
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from 
/Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application.rb:3
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require'
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from 
/Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro.rb:90
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require'
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from 
/Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro_and_og.rb:1
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require'
        from 
/opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
        from app.rb:7


*** LOCAL GEMS ***

blow (0.3.0)
    Block+Web = Blow

BlueCloth (1.0.0)
    BlueCloth is a Ruby implementation of Markdown, a text-to-HTML
    conversion tool for web writers. Markdown allows you to write using
    an easy-to-read, easy-to-write plain text format, then convert it to
    structurally valid XHTML (or HTML).

capistrano (2.0.0)
    Capistrano is a utility and framework for executing commands in
    parallel on multiple remote machines, via SSH.

capistrano-ext (1.2.0)
    Capistrano Extensions is a set of useful task libraries and methods
    that     other developers may reference in their own recipe files.

cgi_multipart_eof_fix (2.3)
    Fix an exploitable bug in CGI multipart parsing.

daemons (1.0.8)
    A toolkit to create and control daemons in different ways

english (0.1)
    English Code Kit

facets (2.0.2, 1.8.54)
    Premium Core Extensions and Standard Additions

fastthread (1.0)
    Optimized replacement for thread.rb primitives

gem_plugin (0.2.2)
    A plugin system based only on rubygems that uses dependencies only

highline (1.4.0)
    HighLine is a high-level command-line IO library.

mongrel (1.0.1)
    A small fast HTTP library and server that runs Rails, Camping, Nitro
    and Iowa apps.

mongrel_cluster (1.0.2)
    Mongrel plugin that provides commands and Capistrano tasks for
    managing multiple Mongrel processes.

needle (1.3.0)
    Needle is a Dependency Injection/Inversion of Control container for
    Ruby. It supports both type-2 (setter) and type-3 (constructor)
    injection. It takes advantage of the dynamic nature of Ruby to
    provide a rich and flexible approach to injecting dependencies.

net-sftp (1.1.0)
    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.


net-ssh (1.1.2)
    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.

palmtree (0.0.6)
    Collection of Capistrano recipes

rake (0.7.3)
    Ruby based make-like utility.

RedCloth (3.0.4)
    RedCloth is a module for using Textile and Markdown in Ruby. Textile
    and Markdown are text formats.  A very simple text format. Another
    stab at making readable text that can be converted to HTML.

ruby-debug (0.9.3)
    Command line interface (CLI) for ruby-debug-base

ruby-debug-base (0.9.3)
    Fast Ruby debugger

sources (0.0.1)
    This package provides download sources for remote gem installation

sqlite3-ruby (1.2.1)
    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
    SQLite3 database.

uuidtools (1.0.1)
    Generation of UUIDs.

xml-simple (1.0.11)
    A very simple API for XML processing.

George Moschovitis wrote:
> Dear devs,
>
> the branch version (http://repo.nitroproject.org/branch) works with 
> Facets 2.0.3
>
> please download it and test :)
>
> -g.
>
> PS: kudos to Tom for this one...
>
> -- 
> http://me.gr
> http://joy.gr
> http://cull.gr
> http://nitroproject.org
> http://phidz.com
> http://joyerz.com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/a0a38427/attachment.vcf 

From george.moschovitis at gmail.com  Sat Nov  3 15:30:58 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 3 Nov 2007 21:30:58 +0200
Subject: [Nitro] Nitro + Facets 2.0.3
In-Reply-To: <472CCB27.9000906@robmela.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
	<472CCB27.9000906@robmela.com>
Message-ID: <afd80b540711031230l4aaeec32tb3205c9874120e73@mail.gmail.com>

You needs Facets 2.0.*3*


not 2.0.2

-g.


On Nov 3, 2007 9:25 PM, Robert Mela <rob at robmela.com> wrote:

> There's a million gems on RubyForge that could match this -- so I'll
> just ask -- what gem am I missing?
>
>   Console::Command::Options
>
> Gemspec dependencies need updating ( just from eyeballing the files ).
> At various points I recall installing
>
>  - xml-simple ( ? )
>  - uuidtools
>  - sources ?
>  - facets 1.8.54 and now 2.0.2
>
> Not sure if mongrel is a dependency or not -- I should try removing it
> and running with the webrick adapter.
>
>
>
>
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application/args.rb:7:
> uninitialized constant Console::Command::Options (NameError)
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
>        from
>
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application.rb:3
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
>        from
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro.rb:90
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
>        from
>
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro_and_og.rb:1
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require'
>        from
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
>        from app.rb:7
>
>
> *** LOCAL GEMS ***
>
> blow (0.3.0)
>    Block+Web = Blow
>
> BlueCloth (1.0.0)
>    BlueCloth is a Ruby implementation of Markdown, a text-to-HTML
>    conversion tool for web writers. Markdown allows you to write using
>    an easy-to-read, easy-to-write plain text format, then convert it to
>    structurally valid XHTML (or HTML).
>
> capistrano (2.0.0)
>    Capistrano is a utility and framework for executing commands in
>    parallel on multiple remote machines, via SSH.
>
> capistrano-ext (1.2.0)
>    Capistrano Extensions is a set of useful task libraries and methods
>    that     other developers may reference in their own recipe files.
>
> cgi_multipart_eof_fix (2.3)
>    Fix an exploitable bug in CGI multipart parsing.
>
> daemons (1.0.8)
>    A toolkit to create and control daemons in different ways
>
> english (0.1)
>    English Code Kit
>
> facets (2.0.2, 1.8.54)
>    Premium Core Extensions and Standard Additions
>
> fastthread (1.0)
>    Optimized replacement for thread.rb primitives
>
> gem_plugin (0.2.2)
>    A plugin system based only on rubygems that uses dependencies only
>
> highline (1.4.0)
>    HighLine is a high-level command-line IO library.
>
> mongrel (1.0.1)
>    A small fast HTTP library and server that runs Rails, Camping, Nitro
>    and Iowa apps.
>
> mongrel_cluster (1.0.2)
>    Mongrel plugin that provides commands and Capistrano tasks for
>    managing multiple Mongrel processes.
>
> needle (1.3.0)
>    Needle is a Dependency Injection/Inversion of Control container for
>    Ruby. It supports both type-2 (setter) and type-3 (constructor)
>    injection. It takes advantage of the dynamic nature of Ruby to
>    provide a rich and flexible approach to injecting dependencies.
>
> net-sftp (1.1.0)
>    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.
>
>
> net-ssh (1.1.2)
>    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.
>
> palmtree (0.0.6)
>    Collection of Capistrano recipes
>
> rake (0.7.3)
>    Ruby based make-like utility.
>
> RedCloth (3.0.4)
>    RedCloth is a module for using Textile and Markdown in Ruby. Textile
>    and Markdown are text formats.  A very simple text format. Another
>    stab at making readable text that can be converted to HTML.
>
> ruby-debug (0.9.3)
>    Command line interface (CLI) for ruby-debug-base
>
> ruby-debug-base (0.9.3)
>    Fast Ruby debugger
>
> sources (0.0.1)
>    This package provides download sources for remote gem installation
>
> sqlite3-ruby (1.2.1)
>    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
>    SQLite3 database.
>
> uuidtools (1.0.1)
>    Generation of UUIDs.
>
> xml-simple (1.0.11)
>    A very simple API for XML processing.
>
> George Moschovitis wrote:
> > Dear devs,
> >
> > the branch version (http://repo.nitroproject.org/branch) works with
> > Facets 2.0.3
> >
> > please download it and test :)
> >
> > -g.
> >
> > PS: kudos to Tom for this one...
> >
> > --
> > http://me.gr
> > http://joy.gr
> > http://cull.gr
> > http://nitroproject.org
> > http://phidz.com
> > http://joyerz.com
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/5637d639/attachment-0001.html 

From rob at robmela.com  Sat Nov  3 15:35:17 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 15:35:17 -0400
Subject: [Nitro] Nitro + Facets 2.0.3
In-Reply-To: <472CCB27.9000906@robmela.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
	<472CCB27.9000906@robmela.com>
Message-ID: <472CCD75.9070901@robmela.com>

Forgot to mention -- you'll need english and blow ( blow was mentioned 
as replacing... um... I can't remember... glue? )

Robert Mela wrote:
> There's a million gems on RubyForge that could match this -- so I'll 
> just ask -- what gem am I missing?
>
>   Console::Command::Options
>
> Gemspec dependencies need updating ( just from eyeballing the files 
> ).   At various points I recall installing
>
>  - xml-simple ( ? )
>  - uuidtools
>  - sources ?
>  - facets 1.8.54 and now 2.0.2
>
> Not sure if mongrel is a dependency or not -- I should try removing it 
> and running with the webrick adapter.
>
>
>
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application/args.rb:7: 
> uninitialized constant Console::Command::Options (NameError)
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `gem_original_require'
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `require'
>        from 
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/application.rb:3 
>
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `gem_original_require'
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `require'
>        from 
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro.rb:90
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `gem_original_require'
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `require'
>        from 
> /Users/rmela/nitro/branch/script/lib/../../nitro/lib/nitro/nitro_and_og.rb:1 
>
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `gem_original_require'
>        from 
> /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
> `require'
>        from app.rb:7
>
>
> *** LOCAL GEMS ***
>
> blow (0.3.0)
>    Block+Web = Blow
>
> BlueCloth (1.0.0)
>    BlueCloth is a Ruby implementation of Markdown, a text-to-HTML
>    conversion tool for web writers. Markdown allows you to write using
>    an easy-to-read, easy-to-write plain text format, then convert it to
>    structurally valid XHTML (or HTML).
>
> capistrano (2.0.0)
>    Capistrano is a utility and framework for executing commands in
>    parallel on multiple remote machines, via SSH.
>
> capistrano-ext (1.2.0)
>    Capistrano Extensions is a set of useful task libraries and methods
>    that     other developers may reference in their own recipe files.
>
> cgi_multipart_eof_fix (2.3)
>    Fix an exploitable bug in CGI multipart parsing.
>
> daemons (1.0.8)
>    A toolkit to create and control daemons in different ways
>
> english (0.1)
>    English Code Kit
>
> facets (2.0.2, 1.8.54)
>    Premium Core Extensions and Standard Additions
>
> fastthread (1.0)
>    Optimized replacement for thread.rb primitives
>
> gem_plugin (0.2.2)
>    A plugin system based only on rubygems that uses dependencies only
>
> highline (1.4.0)
>    HighLine is a high-level command-line IO library.
>
> mongrel (1.0.1)
>    A small fast HTTP library and server that runs Rails, Camping, Nitro
>    and Iowa apps.
>
> mongrel_cluster (1.0.2)
>    Mongrel plugin that provides commands and Capistrano tasks for
>    managing multiple Mongrel processes.
>
> needle (1.3.0)
>    Needle is a Dependency Injection/Inversion of Control container for
>    Ruby. It supports both type-2 (setter) and type-3 (constructor)
>    injection. It takes advantage of the dynamic nature of Ruby to
>    provide a rich and flexible approach to injecting dependencies.
>
> net-sftp (1.1.0)
>    Net::SFTP is a pure-Ruby implementation of the SFTP client protocol.
>
>
> net-ssh (1.1.2)
>    Net::SSH is a pure-Ruby implementation of the SSH2 client protocol.
>
> palmtree (0.0.6)
>    Collection of Capistrano recipes
>
> rake (0.7.3)
>    Ruby based make-like utility.
>
> RedCloth (3.0.4)
>    RedCloth is a module for using Textile and Markdown in Ruby. Textile
>    and Markdown are text formats.  A very simple text format. Another
>    stab at making readable text that can be converted to HTML.
>
> ruby-debug (0.9.3)
>    Command line interface (CLI) for ruby-debug-base
>
> ruby-debug-base (0.9.3)
>    Fast Ruby debugger
>
> sources (0.0.1)
>    This package provides download sources for remote gem installation
>
> sqlite3-ruby (1.2.1)
>    SQLite3/Ruby is a module to allow Ruby scripts to interface with a
>    SQLite3 database.
>
> uuidtools (1.0.1)
>    Generation of UUIDs.
>
> xml-simple (1.0.11)
>    A very simple API for XML processing.
>
> George Moschovitis wrote:
>> Dear devs,
>>
>> the branch version (http://repo.nitroproject.org/branch) works with 
>> Facets 2.0.3
>>
>> please download it and test :)
>>
>> -g.
>>
>> PS: kudos to Tom for this one...
>>
>> -- 
>> http://me.gr
>> http://joy.gr
>> http://cull.gr
>> http://nitroproject.org
>> http://phidz.com
>> http://joyerz.com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/nitro-general
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/52e23467/attachment.vcf 

From transfire at gmail.com  Sat Nov  3 15:35:40 2007
From: transfire at gmail.com (Trans)
Date: Sat, 03 Nov 2007 19:35:40 -0000
Subject: [Nitro] Nitro + Facets 2.0.3
In-Reply-To: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
Message-ID: <1194118540.496161.285330@19g2000hsx.googlegroups.com>



On Nov 3, 1:41 pm, "George Moschovitis" <george.moschovi... at gmail.com>
wrote:
> Dear devs,
>
> the branch version (http://repo.nitroproject.org/branch) works with Facets
> 2.0.3
>
> please download it and test :)

NOTE: I'm not sure exactly what the status is, but I've heard the
Rubyforge gem repository is not working at the moment (can anyone
confirm?). So you might have to download the Facets 2.0.3 gem
manually.

T.


From rob at robmela.com  Sat Nov  3 15:47:36 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 15:47:36 -0400
Subject: [Nitro] Nitro + Facets 2.0.3
In-Reply-To: <1194118540.496161.285330@19g2000hsx.googlegroups.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>
	<1194118540.496161.285330@19g2000hsx.googlegroups.com>
Message-ID: <472CD058.9050108@robmela.com>

That and blow.   I'd run a gem update for facets assuming that would 
work... but it gave me 2.0.2

Next issue:

admin part require paths need to be updated.  In my app.rb I changed

   require 'nitro/part/admin'
to
   require 'part/admin'

but the admin part files themselves need the paths changed.  Should I 
fix it and send a patch, or do you guys want to handle it?

Trans wrote:
> NOTE: I'm not sure exactly what the status is, but I've heard the
> Rubyforge gem repository is not working at the moment (can anyone
> confirm?). So you might have to download the Facets 2.0.3 gem
> manually.
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/f800028c/attachment.vcf 

From rob at robmela.com  Sat Nov  3 15:57:57 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 15:57:57 -0400
Subject: [Nitro] First patch for Nitro + Facets 2.0.3
In-Reply-To: <472CD058.9050108@robmela.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>	<1194118540.496161.285330@19g2000hsx.googlegroups.com>
	<472CD058.9050108@robmela.com>
Message-ID: <472CD2C5.4030505@robmela.com>

Fixes part include paths.

This puts the admin part back to where it was a few days ago -- blowing 
up because of the problem that @post_params in Context is sometimes 
Hash, sometimes Dictionary.

Robert Mela wrote:
> That and blow.   I'd run a gem update for facets assuming that would 
> work... but it gave me 2.0.2
>
> Next issue:
>
> admin part require paths need to be updated.  In my app.rb I changed
>
>   require 'nitro/part/admin'
> to
>   require 'part/admin'
>
> but the admin part files themselves need the paths changed.  Should I 
> fix it and send a patch, or do you guys want to handle it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_part_require_paths.tar.gz
Type: application/x-gzip
Size: 862 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/8210f193/attachment.gz 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/8210f193/attachment.vcf 

From rob at robmela.com  Sat Nov  3 16:18:45 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 16:18:45 -0400
Subject: [Nitro] Nitro/Facets 2.0.3: OgAdminController fails to mount
In-Reply-To: <472CD2C5.4030505@robmela.com>
References: <afd80b540711031041p38d436aud9d633568c70f208@mail.gmail.com>	<1194118540.496161.285330@19g2000hsx.googlegroups.com>	<472CD058.9050108@robmela.com>
	<472CD2C5.4030505@robmela.com>
Message-ID: <472CD7A5.9060705@robmela.com>

When I run this against Nitro trunk the OgAdminController is mounted on /admin/og.

Running against the new branch it isn't.

( note: change 'nitro/part/admin' to 'part/admin' for the newest branch code )

Example copied verbatim from bottom of http://robmela.com/cheatsheets/og_intro


---

#!/usr/bin/env ruby
 require 'sqlite3'
 require 'nitro_and_og'
 include Nitro
 require 'nitro/part/admin'

 # Og model
 class Book
   attr_accessor :title, String
   attr_accessor :author, String
 end

 # Controller
 class Foo
   def index
     redirect_to '/admin' # redirect to Nitro admin scaffold
   end
 end

 Og.create_schema = true
 Og.use_uuid_primary_keys = true
 Og.start( :name => "library", :adapter => :sqlite, :evolve_schema => :full )

 app=Application.new
 app.dispatcher.root = Foo
 app.start 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/9e3c3b0c/attachment.vcf 

From rob at robmela.com  Sat Nov  3 16:23:04 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 16:23:04 -0400
Subject: [Nitro] Nitro/Facets 2.0.3: OgAdminController fails to mount
Message-ID: <472CD8A8.9080202@robmela.com>

When I run this against Nitro trunk the OgAdminController is mounted on 
/admin/og.     Running against the new branch OgAdminController doesn't 
get mounted.  My hunch is that part code needs more updates...

Example copied verbatim from bottom of 
http://robmela.com/cheatsheets/og_intro

( note: change 'nitro/part/admin' to 'part/admin' for the newest branch 
code )


---

#!/usr/bin/env ruby
require 'sqlite3'
require 'nitro_and_og'
include Nitro
require 'nitro/part/admin'

# Og model
class Book
  attr_accessor :title, String
  attr_accessor :author, String
end

# Controller
class Foo
  def index
    redirect_to '/admin' # redirect to Nitro admin scaffold
  end
end

Og.create_schema = true
Og.use_uuid_primary_keys = true
Og.start( :name => "library", :adapter => :sqlite, :evolve_schema => 
:full )

app=Application.new
app.dispatcher.root = Foo
app.start
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/eddf499e/attachment.vcf 

From george.moschovitis at gmail.com  Sat Nov  3 16:26:22 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Sat, 3 Nov 2007 22:26:22 +0200
Subject: [Nitro] Nitro/Facets 2.0.3: OgAdminController fails to mount
In-Reply-To: <472CD8A8.9080202@robmela.com>
References: <472CD8A8.9080202@robmela.com>
Message-ID: <afd80b540711031326j6cf74c76t2c813271e5530687@mail.gmail.com>

Ok, will check all admin issues once and for all ;-) Expect a patch
tomorrow.

-g.

On Nov 3, 2007 10:23 PM, Robert Mela <rob at robmela.com> wrote:

> When I run this against Nitro trunk the OgAdminController is mounted on
> /admin/og.     Running against the new branch OgAdminController doesn't
> get mounted.  My hunch is that part code needs more updates...
>
> Example copied verbatim from bottom of
> http://robmela.com/cheatsheets/og_intro
>
> ( note: change 'nitro/part/admin' to 'part/admin' for the newest branch
> code )
>
>
> ---
>
> #!/usr/bin/env ruby
> require 'sqlite3'
> require 'nitro_and_og'
> include Nitro
> require 'nitro/part/admin'
>
> # Og model
> class Book
>  attr_accessor :title, String
>  attr_accessor :author, String
> end
>
> # Controller
> class Foo
>  def index
>    redirect_to '/admin' # redirect to Nitro admin scaffold
>  end
> end
>
> Og.create_schema = true
> Og.use_uuid_primary_keys = true
> Og.start( :name => "library", :adapter => :sqlite, :evolve_schema =>
> :full )
>
> app=Application.new
> app.dispatcher.root = Foo
> app.start
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071103/f0e76f0b/attachment.html 

From rob at robmela.com  Sat Nov  3 16:34:59 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 16:34:59 -0400
Subject: [Nitro] Nitro/Facets 2.0.3: OgAdminController fails to mount
In-Reply-To: <afd80b540711031326j6cf74c76t2c813271e5530687@mail.gmail.com>
References: <472CD8A8.9080202@robmela.com>
	<afd80b540711031326j6cf74c76t2c813271e5530687@mail.gmail.com>
Message-ID: <472CDB73.4030704@robmela.com>

Remember tho that the original admin issues are upstream in cgi.rb -- 
the dictionary vs. hash conundrum.

Facets 2.0.3 only introduced new require paths.

George Moschovitis wrote:
> Ok, will check all admin issues once and for all ;-) Expect a patch 
> tomorrow.
>
> -g.
>
> On Nov 3, 2007 10:23 PM, Robert Mela <rob at robmela.com 
> <mailto:rob at robmela.com>> wrote:
>
>     When I run this against Nitro trunk the OgAdminController is
>     mounted on
>     /admin/og.     Running against the new branch OgAdminController
>     doesn't
>     get mounted.  My hunch is that part code needs more updates...
>
>     Example copied verbatim from bottom of
>     http://robmela.com/cheatsheets/og_intro
>
>     ( note: change 'nitro/part/admin' to 'part/admin' for the newest
>     branch
>     code )
>
>
>     ---
>
>     #!/usr/bin/env ruby
>     require 'sqlite3'
>     require 'nitro_and_og'
>     include Nitro
>     require 'nitro/part/admin'
>
>     # Og model
>     class Book
>      attr_accessor :title, String
>      attr_accessor :author, String
>     end
>
>     # Controller
>     class Foo
>      def index
>        redirect_to '/admin' # redirect to Nitro admin scaffold
>      end
>     end
>
>     Og.create_schema = true
>     Og.use_uuid_primary_keys = true
>     Og.start( :name => "library", :adapter => :sqlite, :evolve_schema =>
>     :full )
>
>     app=Application.new
>     app.dispatcher.root = Foo
>     app.start
>
>     _______________________________________________
>     Nitro-general mailing list
>     Nitro-general at rubyforge.org <mailto:Nitro-general at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>
>
> -- 
> http://me.gr
> http://joy.gr
> http://cull.gr
> http://nitroproject.org
> http://phidz.com
> http://joyerz.com 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/03f4c903/attachment-0001.vcf 

From rob at robmela.com  Sat Nov  3 16:47:13 2007
From: rob at robmela.com (Robert Mela)
Date: Sat, 03 Nov 2007 16:47:13 -0400
Subject: [Nitro] Documentation Documentation
In-Reply-To: <36CEAEC3-2D34-4E77-A738-A80849291517@gmail.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>	<472AE930.1030509@arnebrasseur.net>	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>	<472B4B2F.9010709@robmela.com>	<1194053379.425543.87550@v3g2000hsg.googlegroups.com>	<389c43e40711022351t77514ea3ldd9a10ffc358423b@mail.gmail.com>
	<36CEAEC3-2D34-4E77-A738-A80849291517@gmail.com>
Message-ID: <472CDE51.1060805@robmela.com>

So is that something in between Tutorial and Book.

   1. Quickstart (README.intro )
   2. Tutorial
   3. "Four Days of Nitro"
   4. The Book

Advantage -- it appears long before "book", and makes a great warmup for 
person(s) doing Book.

Somewhere outside the progression but perhaps sharing some resources with it

    * Reference ( is this not the same as RDocs? )


s.ross wrote:
> One nice "up and running" tutorial for Rails is this:
>
> http://rails.homelinux.org/
>
> It's a bit dated by now, but covered out-of-the-box Rails experience.
>
> Hope this helps.
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20071103/0d9da405/attachment.vcf 

From william.full.moon at gmail.com  Sat Nov  3 22:13:34 2007
From: william.full.moon at gmail.com (* William)
Date: Sun, 4 Nov 2007 13:13:34 +1100
Subject: [Nitro] Nitro/Og cheat sheet styles/ideas/levels....
In-Reply-To: <472C9D7E.3090106@robmela.com>
References: <389c43e40711030010u313b8c98qa553ced7e8fcaabb@mail.gmail.com>
	<472C9D7E.3090106@robmela.com>
Message-ID: <9e03c3c60711031913xe3bf70bwc1bae4c973900158@mail.gmail.com>

Hi folk / Robert

On the small point of our general individual, "...fault as an engineer ...
[to] prematurely jumping to nuts-and-bolts" (when I am wear my s/w
engineer's hat) -- There are some pedagogical processes that can be
developed for these areas (wearing me adult training cap).

In the specific get me started in a new technically biased (as in lots of
technology) topic area, you begin with easily FAMILIAR subject matter and
analyse what's called the "training gap".

Software engineers can see this as a user analysis in preparation for
enumerating use cases.

Take a familar - To The User - Scenario and analyse what that person may not
possibly know.  Everything, assume nothing.

I believe the most efficient way to accomplish that task is to begin by
developing user profiles of that context and knowledge (assumed knowledge)
of each "user class".

That works.

The reason it works is because each role or user class' needs and knowledge
is written out and accounted for, they can be tracked.  When a tutorial or
training section is ready.  I can actually ask, "Did I get told in logical
order?" == Logical order, meaning each topic is presented one idea at a
time, and no new topic/idea is presented before the prerequisites are
presented.

While we may not need such detail, after all everyone knows what a database
is for don't they?  (Well actually no.  They might know what the name
means.)  It is like riding a bicycle -- Knowing the word and the machine, is
then same as riding it and "knowing it". *grin*

Profile helps others too -- at some point we'll want some marketing.
Profiles are the start of target market segmentation.  It also helps
internals and addon developers understand user requirements and design
paramerters for fixed and on-going change and development (see: "Marketing
Myopia", Levitte, 1960, Harvard Business Review).

You will find that different inductions will be needed to begin introduction
tutorials different user classes.

Give it a thought.  I believe a user profile main wiki page where people can
develop and refind each user class would be a great beginning.

Our general individual "...fault as an engineer ..[to] prematurely jumping
to nuts-and-bolts" becomes the advantage of engineering when we jump on the
"appropriate" productive "nuts-and-bolts" issues.  Here, I'm suggesting user
profiles for the new users are very useful!

cheers,
            Will.



On 04/11/2007, Robert Mela <rob at robmela.com> wrote:
>
> I would first ask what is it we want to produce.  In other words:
>
> 1) What topics need to be covered
> 3) A list of use cases and the format that serves each
>
>
> #1 would require input from George and Tom -- it would leverage their
> time really well.   This could start before documentation does.




My fault as an engineer is prematurely jumping to nuts-and-bolts
> "How".    This is a tangent -- but I'd love to see a design for reusable
> components that each format can built itself from -- e.g., a Topic
> class, with CodeExample, Synopsis, RelatedTopics.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071104/11c80c85/attachment.html 

From transfire at gmail.com  Sun Nov  4 21:17:39 2007
From: transfire at gmail.com (Trans)
Date: Mon, 05 Nov 2007 02:17:39 -0000
Subject: [Nitro] SQL anyone?
Message-ID: <1194229059.735264.210620@o38g2000hse.googlegroups.com>

My pal, Peter, put out a pretty sweet tutorial recently:

  http://www.xaop.com/articles/2007/10/07/metaprogramming

Prepare to shit your SQL pants!

T.


From arne at arnebrasseur.net  Mon Nov  5 03:08:09 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Mon, 05 Nov 2007 16:08:09 +0800
Subject: [Nitro] SQL anyone?
In-Reply-To: <1194229059.735264.210620@o38g2000hse.googlegroups.com>
References: <1194229059.735264.210620@o38g2000hse.googlegroups.com>
Message-ID: <472ECF69.4080808@arnebrasseur.net>

Very interesting, and it's from the Belgian Ruby User Group. Didn't even 
know there was one!

Are you suggesting Og could use a

result = query do ...
?

(ab)

Trans schreef:
> My pal, Peter, put out a pretty sweet tutorial recently:
>
>   http://www.xaop.com/articles/2007/10/07/metaprogramming
>
> Prepare to shit your SQL pants!
>
> T.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>   


-- 
Arne Brasseur
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
arne at arnebrasseur.net


From t_leitner at gmx.at  Mon Nov  5 03:15:58 2007
From: t_leitner at gmx.at (Thomas Leitner)
Date: Mon, 5 Nov 2007 09:15:58 +0100
Subject: [Nitro] Euruko anyone?
Message-ID: <B65493DD-D3F2-43A1-9BD3-41E7D821710D@gmx.at>

Hey,

anybody going to Euruko this weekend? I'll be there this time :)

   Thomas

From lasso at lassoweb.se  Mon Nov  5 03:38:23 2007
From: lasso at lassoweb.se (Lars Olsson)
Date: Mon, 5 Nov 2007 08:38:23 -0000 (UTC)
Subject: [Nitro] SQL anyone?
In-Reply-To: <1194229059.735264.210620@o38g2000hse.googlegroups.com>
References: <1194229059.735264.210620@o38g2000hse.googlegroups.com>
Message-ID: <44272.192.176.230.1.1194251903.squirrel@webmail.lassoweb.se>

Yes, very interesting. But don't we already have stuff like that in Og?
(the Caboose::EZ module).

/lasso



On Mon, November 5, 2007 02:17, Trans wrote:
> My pal, Peter, put out a pretty sweet tutorial recently:
>
>
> http://www.xaop.com/articles/2007/10/07/metaprogramming
>
>
> Prepare to shit your SQL pants!
>
>
> T.
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>



From tastapod at gmail.com  Mon Nov  5 05:16:08 2007
From: tastapod at gmail.com (Dan North)
Date: Mon, 5 Nov 2007 10:16:08 +0000
Subject: [Nitro] Documentation Documentation
In-Reply-To: <472B4B2F.9010709@robmela.com>
References: <1193937508.821177.26120@y42g2000hsy.googlegroups.com>
	<472AE930.1030509@arnebrasseur.net>
	<afd80b540711020338k417c6d22sae3fd1886a33c09a@mail.gmail.com>
	<d559d8430711020525y582787fn1b098903fdd25ec9@mail.gmail.com>
	<472B4B2F.9010709@robmela.com>
Message-ID: <d559d8430711050216m533ded29t85a22b39e5e398f5@mail.gmail.com>

Whilst we are on the subject of Og, here's a request that came from inside
ThoughtWorks. I'm interested in how it fits into the current model for Og:

<quote>
I want unit of work so that I don't have to manually remember to flush to
the database or remember arcane rules about persistance through reachability
for different collection mappings.

I want Hibernate-style HQL so I can perform complex reporting style queries
expressed in my domain language and so that I can map legacy schemas without
having to remember ugly table/column names.

I want several levels of caching so that I can be clever about caching data
for read-mostly applications. (And anyone telling me ActiveRecord or plugins
can already do this does not know what they're talking about.)
</quote>

Thoughts?

How much effort would it be to integrate a Unit-of-Work pattern into Og? Or
should I be thinking about a whole other ORM here? As for the HQL-style
queries, I would prefer to see an embedded DSL that supported
database-independent queries, something like LINQ meets HQL. Perhaps that's
a separate project that would play nice with Og?

Thanks,
Dan


On 11/2/07, Robert Mela <rob at robmela.com> wrote:
>
> 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?
>
> Dan North wrote:
> > 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
>
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071105/00f201a8/attachment-0001.html 

From george.moschovitis at gmail.com  Mon Nov  5 05:47:59 2007
From: george.moschovitis at gmail.com (George Moschovitis)
Date: Mon, 5 Nov 2007 12:47:59 +0200
Subject: [Nitro] Admin part.
Message-ID: <afd80b540711050247r55d02e15w743de09c8a0c9d47@mail.gmail.com>

Rob,

can you please verify that the admin part in the lates repo indeed works?
(use facets 2.0.4 please)

-g.

-- 
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20071105/f4401828/attachment.html 

From arne at arnebrasseur.net  Mon Nov  5 06:23:32 2007
From: arne at arnebrasseur.net (Arne Brasseur)
Date: Mon, 05 Nov 2007 19:23:32 +0800
Subject: [Nitro] Nitro request handling overview
Message-ID: <472EFD34.1000908@arnebrasseur.net>

I figured this would come in handy for folks trying to get what's going 
on in Nitro, including myself.



A request comes in at a certain adapter (mongrel, fcgi, ...). 
(raw/adapter/<...>.rb)

The adapter creates a new Context object and fills it with whatever is 
in the request : parameters, cookies, and the QUERY_STRING

It calls handle_context (AdapterHandlerMixin raw/adapter.rb)

This calls dispath_context (Dispatcher raw/dispatcher.rb)

The Dispatcher consults the Router, determines the controller class, the 
name of the action 'super method', any parameters and the format.

The super method is named #{action}___super, this method calls the 
method #{action} and the action view method, which is basically the 
compiled form of the template : #{action}___#{format}___view.

This all is given back to the adapter. It sets 
Thread[:CURRENT_CONTROLLER] t