Rails - Feb 2006 - ActiveRbac 0.3 release - We''re now on Engines

Hi

I have just released the 0.3 revision of ActiveRecord - make sure to  
get the fresh, hot packages from

   https://activerbac.turingstudio.com/releases


What is ActiveRBAC?
-------------------

ActiveRBAC is a Ruby on Rails library that provides a full stack RBAC  
(Role Based Authorization) system with user, group, role and  
permission management. It provides models and controllers to edit  
those models (obviously it should also provide views which it does ;))

Useful URLS:

   https://activerbac.turingstudio.com           - the project''s page
   https://activerbac.turingstudio.com/api/      - API documentation
   https://activerbac.turingstudio.com/releases/ - download it here
   https://activerbac.turingstudio.com/source/   - our SVN repository  
is here

If you have any questions or suggestions for us, contact us via our  
mailing list (or contact me directly if you prefer that):

   rbac-dev@lists.cloudcore.com

You can sign up here:

  https://lists.cloudcore.com/mailman/listinfo/rbac-dev


Changelog
---------

active_rbac

* Moving configuration into the "ActiveRbac" module as is normal for  
engines.
* Controllers have been moved into a subdirectory "active_rbac" so  
they can be in the namespace "ActiveRbac"
* The structure of ActiveRBAC has been changed to the of an engine.

rbac_demo

* minor template tweakings
* Adding a protected page
* Uprading some script/* files
* ActiveRBAC is not imported as a component any more. It is used as  
an engine now.

minicms

* minicms_permissions_only works now with the ActiveRbac engine
* removing railsfix plugin - that''s now in the ActiveRbac engine
* removing protect_rbac plugin - that''s also now in the ActiveRbac  
engine

generators

* removing rbac_railfix since this is now in the engine



Regards,

Manuel Holtgrewe

Sorry... I''ve got to say it... "oh no... another security/login
system for rails...." :-/

b

PS: nothing negative intended towards your plugin though... it''s
probably the best...
other than EZ''s of course cuz he just rocks.

Manuel Holtgrewe wrote:
> Hi
> 
> I have just released the 0.3 revision of ActiveRecord - make sure to  
> get the fresh, hot packages from
> 
>   https://activerbac.turingstudio.com/releases
> 
> 
> What is ActiveRBAC?
> -------------------
> 
> ActiveRBAC is a Ruby on Rails library that provides a full stack RBAC  
> (Role Based Authorization) system with user, group, role and  permission 
> management. It provides models and controllers to edit  those models 
> (obviously it should also provide views which it does ;))
> 
> Useful URLS:
> 
>   https://activerbac.turingstudio.com           - the project''s
page
>   https://activerbac.turingstudio.com/api/      - API documentation
>   https://activerbac.turingstudio.com/releases/ - download it here
>   https://activerbac.turingstudio.com/source/   - our SVN repository  is 
> here
> 
> If you have any questions or suggestions for us, contact us via our  
> mailing list (or contact me directly if you prefer that):
> 
>   rbac-dev@lists.cloudcore.com
> 
> You can sign up here:
> 
>  https://lists.cloudcore.com/mailman/listinfo/rbac-dev
> 
> 
> Changelog
> ---------
> 
> active_rbac
> 
> * Moving configuration into the "ActiveRbac" module as is normal
for
> engines.
> * Controllers have been moved into a subdirectory "active_rbac"
so  they
> can be in the namespace "ActiveRbac"
> * The structure of ActiveRBAC has been changed to the of an engine.
> 
> rbac_demo
> 
> * minor template tweakings
> * Adding a protected page
> * Uprading some script/* files
> * ActiveRBAC is not imported as a component any more. It is used as  an 
> engine now.
> 
> minicms
> 
> * minicms_permissions_only works now with the ActiveRbac engine
> * removing railsfix plugin - that''s now in the ActiveRbac engine
> * removing protect_rbac plugin - that''s also now in the ActiveRbac
engine
> 
> generators
> 
> * removing rbac_railfix since this is now in the engine
> 
> 
> 
> Regards,
> 
> Manuel Holtgrewe
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Am 24.02.2006 um 05:41 schrieb Ben Munat:
> Sorry... I''ve got to say it... "oh no... another
security/login
> system for rails...." :-/
Wait, it''s the security system to end all security systems :P - just  
kidding. You''re free to ignore it, of course.
> PS: nothing negative intended towards your plugin though... it''s  
> probably the best... other than EZ''s of course cuz he just rocks.
Who is EZ?

Regards,

Manuel

Check out the splat..

http://brainspl.at/articles/2006/02/20/new-plugin-acl_system

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Nathaniel S. H. Brown                           http://nshb.net 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
> -----Original Message-----
> From: rails-bounces@lists.rubyonrails.org 
> [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of 
> Manuel Holtgrewe
> Sent: February 24, 2006 1:25 AM
> To: rails@lists.rubyonrails.org
> Subject: Re: [Rails] [ANN] ActiveRbac 0.3 release - We''re now 
> on Engines
> 
> 
> Am 24.02.2006 um 05:41 schrieb Ben Munat:
> 
> > Sorry... I''ve got to say it... "oh no... another 
> security/login system 
> > for rails...." :-/
> 
> Wait, it''s the security system to end all security systems :P 
> - just kidding. You''re free to ignore it, of course.
> 
> > PS: nothing negative intended towards your plugin though...
it''s
> > probably the best... other than EZ''s of course cuz he just
rocks.
> 
> Who is EZ?
> 
> Regards,
> 
> Manuel
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

>>-----Original Message-----
>>Am 24.02.2006 um 05:41 schrieb Ben Munat:
>>>Sorry... I''ve got to say it... "oh no... another 
>>>security/login system or rails...." :-/
>>
>>Wait, it''s the security system to end all security systems :P 
>>- just kidding. You''re free to ignore it, of course.
>>
>>
>>>PS: nothing negative intended towards your plugin though...
it''s
>>>probably the best... other than EZ''s of course cuz he just
rocks.
>>
>>Who is EZ?
>>
>>Regards,
>>
>>Manuel
Nathaniel S. H. Brown wrote:
 > Check out the splat..
 >
 > http://brainspl.at/articles/2006/02/20/new-plugin-acl_system

Yep... that''s EZ.

And, Manuel, just wanted to stress again that I''m not saying
there''s anything wrong with
you creating another security system for rails.

However, at some point it would be good if all these systems could join up and
consolidate
into one or two (maybe just basic login vs. RBAC) systems. I think another
security system
writer on the list was proposing at least a naming convention.

b

I think that FAR greater than the need to consolidate into one system
(watch DHH break out in hives at the phrase ''The One True
Authentication System'') is

         *Crystal-Clear Documentation*

....from the overview level down to the API, about how these each system works.

Then we''ll start boiling stuff down to patterns, discovering
similarities AND disparities, and where if possible and/or desirable
things can be merged or made consistent. That was the essence, as I
took it, of Ezra''s recent post[1]. Developers should then be able to
easily recognise whether or not they can use a particular
''pre-packaged'' login (or whatever) system, or alternatively
take use
the patterns described to wrangle their own (if they prefer
Frontierland to the Magic Kingdom).

I''m chastising myself more than anyone - my documentation certainly
needs to be whipped into shape. But isn''t the point of open source so
that I can get *you* people to do *my* work? ;-)

- james

[1] Although it shouldn''t be taken that he''s defined the
''One True
RBAC Pattern'' either. The space is wide open, and there''s
absolutely
nothing wrong with striking out on your own, should you perceive the
need. That''s the nature of progress, after all.

On 2/24/06, Ben Munat <bent@munat.com> wrote:
> >>-----Original Message-----
> >>Am 24.02.2006 um 05:41 schrieb Ben Munat:
> >>>Sorry... I''ve got to say it... "oh no... another
> >>>security/login system or rails...." :-/
> >>
> >>Wait, it''s the security system to end all security systems
:P
> >>- just kidding. You''re free to ignore it, of course.
> >>
> >>
> >>>PS: nothing negative intended towards your plugin though...
it''s
> >>>probably the best... other than EZ''s of course cuz he
just rocks.
> >>
> >>Who is EZ?
> >>
> >>Regards,
> >>
> >>Manuel
>
> Nathaniel S. H. Brown wrote:
>  > Check out the splat..
>  >
>  > http://brainspl.at/articles/2006/02/20/new-plugin-acl_system
>
> Yep... that''s EZ.
>
> And, Manuel, just wanted to stress again that I''m not saying
there''s anything wrong with
> you creating another security system for rails.
>
> However, at some point it would be good if all these systems could join up
and consolidate
> into one or two (maybe just basic login vs. RBAC) systems. I think another
security system
> writer on the list was proposing at least a naming convention.
>
> b
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
* J *
  ~

James is right. I just think its important to recognize patterns  
that keep emerging in these types of systems and try to consolidate  
them a bit. The implementation is left up to the user, they could  
pick which backend or plugin they like the best. I just wanted a  
little discussion of what people think would be the easiest to use  
declarative syntax for protecting controllers and models. then its up  
to others to either use my implementation or another one.  
Documentation is always a good thing.

	I have used ActiveRbac in a project and it served me very well and  
is a great system. My current plugin, acl_system, is an extraction  
from a real application where I had to solve this problem. And the  
best frameworks come from extractions. I just needed something simple  
and lightweight yet flexible in the syntax used to control which  
roles have access and which don''t. I will be adding more to the  
plugin as far as protecting models soon after I get some more  
feedback as to what people think is a nice syntax. Or after I  
implement it in my app and extract that to share with others.

	There is no one true login system. But by defining a few patterns I  
have recognized, i have been able to make an authorization(not  
authentication) plugin that will sit on top of any login system that  
implements two certain things, which most of the currently available  
options already do have. This way it is decoupled from any one login  
system to avoid the "One true system" because that is a pipe dream.  
But I do see a lot of rails appsw and code these days and the things  
that I end up repeating in more then one app are worth extracting if  
it makes sense to do so. And the rails community has been so nice to  
me when I was getting started that its only fair I give back when I  
come up with something that solves a problem I think other rails devs  
will come across.

	Other then that, please do check out all the option before you  
choose one or you may want to write you own. But it doesn''t hurt to  
unify patterns that i see emerge more then once and offer them up for  
discussion.

	I hope I never do see the One True login system ;)

Cheers-
-Ezra
On Feb 24, 2006, at 8:50 AM, James Adam wrote:
> I think that FAR greater than the need to consolidate into one system
> (watch DHH break out in hives at the phrase ''The One True
> Authentication System'') is
>
>          *Crystal-Clear Documentation*
>
> ....from the overview level down to the API, about how these each  
> system works.
>
> Then we''ll start boiling stuff down to patterns, discovering
> similarities AND disparities, and where if possible and/or desirable
> things can be merged or made consistent. That was the essence, as I
> took it, of Ezra''s recent post[1]. Developers should then be able
to
> easily recognise whether or not they can use a particular
> ''pre-packaged'' login (or whatever) system, or
alternatively take use
> the patterns described to wrangle their own (if they prefer
> Frontierland to the Magic Kingdom).
>
> I''m chastising myself more than anyone - my documentation
certainly
> needs to be whipped into shape. But isn''t the point of open source
so
> that I can get *you* people to do *my* work? ;-)
>
> - james
>
> [1] Although it shouldn''t be taken that he''s defined the
''One True
> RBAC Pattern'' either. The space is wide open, and there''s
absolutely
> nothing wrong with striking out on your own, should you perceive the
> need. That''s the nature of progress, after all.
>
> On 2/24/06, Ben Munat <bent@munat.com> wrote:
>>>> -----Original Message-----
>>>> Am 24.02.2006 um 05:41 schrieb Ben Munat:
>>>>> Sorry... I''ve got to say it... "oh no...
another
>>>>> security/login system or rails...." :-/
>>>>
>>>> Wait, it''s the security system to end all security
systems :P
>>>> - just kidding. You''re free to ignore it, of course.
>>>>
>>>>
>>>>> PS: nothing negative intended towards your plugin though...
it''s
>>>>> probably the best... other than EZ''s of course cuz
he just rocks.
>>>>
>>>> Who is EZ?
>>>>
>>>> Regards,
>>>>
>>>> Manuel
>>
>> Nathaniel S. H. Brown wrote:
>>> Check out the splat..
>>>
>>> http://brainspl.at/articles/2006/02/20/new-plugin-acl_system
>>
>> Yep... that''s EZ.
>>
>> And, Manuel, just wanted to stress again that I''m not saying  
>> there''s anything wrong with
>> you creating another security system for rails.
>>
>> However, at some point it would be good if all these systems could  
>> join up and consolidate
>> into one or two (maybe just basic login vs. RBAC) systems. I think  
>> another security system
>> writer on the list was proposing at least a naming convention.
>>
>> b
>>
>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
>
> --
>
> * J *
>   ~
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

I almost responded to echo James, but figured the key point he made
would stand on its own.  EZ''s sort-of-agreement with him (while
wrenching the conversation back to design patterns :-) makes me think
that James''s point deserves to be emphasized more explicitly.

EZ wrote:
>> Documentation is always a good thing.  
Absolutely. Documentation isn''t just a /good/ thing, it''s an
/essential/
thing if someone less-skilled than the creator is going to try to use
the product. Where would Rails be without the Agile book?   

I would argue that the real obstacle to convergence on a few optimal
RBAC implementations isn''t agreement on a design pattern, as good an
idea as that may be. Instead, the lack of convergence is because /users/
(I mean user-developers, not end-users), and especially newbies (the
people most likely to need a plug-in authorization system), find all the
available options equally impenetrable, so they scatter among them. The
best available authorization-system options make at least some attempt
at a tutorial, but none is particularly impressive; most just settle for
a couple of code-snippets and assume you know enough about Rails to
figure it out.  Nobody has yet bothered to document any one of them to a
level that would allow a newbie to pick it up, plug it in, fire it up,
and make it work.

The thing is, even a small difference in initial documentation quality
can provoke substantial convergence in an audience of learners.  And
once users start converging, whatever system has the small initial
advantage will get more attention and gain still further advantage. The
race is going to go to the first developer who figures out how to
attract the users -- and the best way to do that is by improving your
documentation.

Personally, I bet that Chad Fowler''s Rails Recipe (from the new beta
book) becomes the de facto RBAC standard within months after its
print-publication.  It''s not that his is necessarily better than anyone
else''s; it''s that there''s nothing like solid,
step-by-step tutorial
documentation to attract the attention of someone who''s already
overloaded by learning a new framework and (probably) a new language.
And if everyone''s using Chad''s, who cares how good the others
are?

In sum: Convergence is primarily a market phenomenon, not a design or
technology phenomenon (anyone still got a Betamax?).  As programmers
offering design services in a marketplace, we forget that at our peril.

--Chris


-----Original Message-----
From: Ezra Zygmuntowicz [mailto:ezra@yakima-herald.com] 
Sent: Friday, February 24, 2006 3:00 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] [ANN] ActiveRbac 0.3 release - We''re now on
Engines



	James is right. I just think its important to recognize patterns
that keep emerging in these types of systems and try to consolidate them
a bit. The implementation is left up to the user, they could pick which
backend or plugin they like the best. I just wanted a little discussion
of what people think would be the easiest to use declarative syntax for
protecting controllers and models. then its up to others to either use
my implementation or another one.  
Documentation is always a good thing.

	I have used ActiveRbac in a project and it served me very well
and is a great system. My current plugin, acl_system, is an extraction
from a real application where I had to solve this problem. And the best
frameworks come from extractions. I just needed something simple and
lightweight yet flexible in the syntax used to control which roles have
access and which don''t. I will be adding more to the plugin as far as
protecting models soon after I get some more feedback as to what people
think is a nice syntax. Or after I implement it in my app and extract
that to share with others.

	There is no one true login system. But by defining a few
patterns I have recognized, i have been able to make an
authorization(not
authentication) plugin that will sit on top of any login system that
implements two certain things, which most of the currently available
options already do have. This way it is decoupled from any one login
system to avoid the "One true system" because that is a pipe dream.  
But I do see a lot of rails appsw and code these days and the things
that I end up repeating in more then one app are worth extracting if it
makes sense to do so. And the rails community has been so nice to me
when I was getting started that its only fair I give back when I come up
with something that solves a problem I think other rails devs will come
across.

	Other then that, please do check out all the option before you
choose one or you may want to write you own. But it doesn''t hurt to
unify patterns that i see emerge more then once and offer them up for
discussion.

	I hope I never do see the One True login system ;)

Cheers-
-Ezra
On Feb 24, 2006, at 8:50 AM, James Adam wrote:
> I think that FAR greater than the need to consolidate into one system 
> (watch DHH break out in hives at the phrase ''The One True 
> Authentication System'') is
>
>          *Crystal-Clear Documentation*
>
> ....from the overview level down to the API, about how these each 
> system works.
>
> Then we''ll start boiling stuff down to patterns, discovering 
> similarities AND disparities, and where if possible and/or desirable 
> things can be merged or made consistent. That was the essence, as I 
> took it, of Ezra''s recent post[1]. Developers should then be able
to
> easily recognise whether or not they can use a particular 
> ''pre-packaged'' login (or whatever) system, or
alternatively take use
> the patterns described to wrangle their own (if they prefer 
> Frontierland to the Magic Kingdom).
>
> I''m chastising myself more than anyone - my documentation
certainly
> needs to be whipped into shape. But isn''t the point of open source
so
> that I can get *you* people to do *my* work? ;-)
>
> - james
>
> [1] Although it shouldn''t be taken that he''s defined the
''One True
> RBAC Pattern'' either. The space is wide open, and there''s
absolutely
> nothing wrong with striking out on your own, should you perceive the 
> need. That''s the nature of progress, after all.
>
> On 2/24/06, Ben Munat <bent@munat.com> wrote:
>>>> -----Original Message-----
>>>> Am 24.02.2006 um 05:41 schrieb Ben Munat:
>>>>> Sorry... I''ve got to say it... "oh no...
another security/login
>>>>> system or rails...." :-/
>>>>
>>>> Wait, it''s the security system to end all security
systems :P
>>>> - just kidding. You''re free to ignore it, of course.
>>>>
>>>>
>>>>> PS: nothing negative intended towards your plugin though...
it''s
>>>>> probably the best... other than EZ''s of course cuz
he just rocks.
>>>>
>>>> Who is EZ?
>>>>
>>>> Regards,
>>>>
>>>> Manuel
>>
>> Nathaniel S. H. Brown wrote:
>>> Check out the splat..
>>>
>>> http://brainspl.at/articles/2006/02/20/new-plugin-acl_system
>>
>> Yep... that''s EZ.
>>
>> And, Manuel, just wanted to stress again that I''m not saying
there''s
>> anything wrong with you creating another security system for rails.
>>
>> However, at some point it would be good if all these systems could 
>> join up and consolidate into one or two (maybe just basic login vs. 
>> RBAC) systems. I think another security system writer on the list was
>> proposing at least a naming convention.
>>
>> b
>>
>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
>
> --
>
> * J *
>   ~
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com

> Nathaniel S. H. Brown wrote:
> > Check out the splat..
> >
> > http://brainspl.at/articles/2006/02/20/new-plugin-acl_system
>
> Yep... that''s EZ.
>
> And, Manuel, just wanted to stress again that I''m not saying  
> there''s anything wrong with you creating another security system  
> for rails.
I did not take any offense, I was just amused a bit :)

Am 24.02.2006 um 17:50 schrieb James Adam:
> I think that FAR greater than the need to consolidate into one system
> (watch DHH break out in hives at the phrase ''The One True
> Authentication System'') is
Watch me break out in hives when reading some parts of David''s  
ramblings :) (I hope nobody takes offense). Different people have  
different requirements and different opinions. This is what freedom  
of thought and speech is about :)
>          *Crystal-Clear Documentation*
Yes, this is essential and lacking for so many commercial and open  
source applications. With open source, you can look at the code to  
figure things out for yourselve if everything else fails.

<snip>
> I''m chastising myself more than anyone - my documentation
certainly
> needs to be whipped into shape. But isn''t the point of open source
so
> that I can get *you* people to do *my* work? ;-)
Back when working on binarycloud (http://www.binarycloud.com), we  
hoped for the same thing. In the end it were the same three people  
doing the work. With rails it seems to be reversed: So many patches  
in the tracker and no developer to incorporate them (even if they fix  
bugs). ;)
> [1] Although it shouldn''t be taken that he''s defined the
''One True
> RBAC Pattern'' either. The space is wide open, and there''s
absolutely
> nothing wrong with striking out on your own, should you perceive the
> need. That''s the nature of progress, after all.
Yerp, I hope we will never see software/trivial patents in Europe and  
cease them to exist in the US.

On 2/24/06, James Adam <james.adam@gmail.com>
wrote:
>  (if they prefer Frontierland to the Magic Kingdom).
s/Magic Kingdom/Tomorrowland/

D''oh - Frontierland is *in* the Magic Kingdom. It''s clearly
been far
too long since I''ve been to Disneyland :)

--
* J *
  ~

Manuel Holtgrewe wrote:
    >>          *Crystal-Clear Documentation*
    > Yes, this is essential and lacking for so many commercial and open
    > source applications. With open source, you can look at the code to
    > figure things out for yourselve if everything else fails.



Being free is not an excuse for poor/absent/less-than terrific 
documentation.

Poor documentation is an insult to the community.
It means "After spending days or weeks on writing the code, I
don''t want
to spend an hour or two or three writing a good doc so that thousands of 
people will just have to spend 5-10 minutes to figure out if my tool is 
right for their  needs. Instead, they just have to download, install, 
create a fake project, test, read code, digg, and spend hours/days on 
it. And who cares if they hit a wall later in their project, that you 
just find out when you''re an advanced user."

Multiply that by 10 (approx. number of available login 
frameworks/solution)...

Alain

Alain Ravet wrote:
> Being free is not an excuse for poor/absent/less-than terrific 
> documentation.
> 
> Poor documentation is an insult to the community.
> It means "After spending days or weeks on writing the code, I
don''t want
> to spend an hour or two or three writing a good doc 
And therein lies the rub...  It takes more than an hour or two to write 
good documentation.  Good documentation must be consistent, readable, 
and most importantly correct and up to date.  A documentation bug can be 
much more pernicious than a code bug - apart from anything else, it''s 
impossible to test.  There''s a reason good technical writers are paid 
well.  The skill-set just doesn''t intersect that well with coding.
> so that thousands of 
> people will just have to spend 5-10 minutes to figure out if my tool is 
> right for their  needs. Instead, they just have to download, install, 
> create a fake project, test, read code, digg, and spend hours/days on 
> it. And who cares if they hit a wall later in their project, that you 
> just find out when you''re an advanced user."
So, does becoming an advanced user and not contributing doc patches also 
constitute an insult to the community?

-- 
Alex

On 2/25/06, Alex Young <alex@blackkettle.org>
wrote:
>
> Alain Ravet wrote:
> > Being free is not an excuse for poor/absent/less-than terrific
> > documentation.
> >
> > Poor documentation is an insult to the community.
> > It means "After spending days or weeks on writing the code, I
don''t want
> > to spend an hour or two or three writing a good doc
> And therein lies the rub...  It takes more than an hour or two to write
> good documentation.  Good documentation must be consistent, readable,
> and most importantly correct and up to date.  A documentation bug can be
> much more pernicious than a code bug - apart from anything else,
it''s
> impossible to test.  There''s a reason good technical writers are
paid
> well.  The skill-set just doesn''t intersect that well with coding.

  I agree with Alex.  I recommend them to be included in all my projects.
-Larry
> so that thousands of
> > people will just have to spend 5-10 minutes to figure out if my tool
is
> > right for their  needs. Instead, they just have to download, install,
> > create a fake project, test, read code, digg, and spend hours/days on
> > it. And who cares if they hit a wall later in their project, that you
> > just find out when you''re an advanced user."
> So, does becoming an advanced user and not contributing doc patches also
> constitute an insult to the community?
>
> --
> Alex
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
Best Regards,
-Larry
"Work, work, work...there is no satisfactory alternative."
            --- E.Taft Benson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060226/7ebe666c/attachment-0001.html

One way to make documentation easier is to start working on a reasonable
DSL, document its use first, see how an implementation works in the real
world, then iterate. For my part, I posted a first pass at an authorization
DSL that sits on top of an authentication system that meets a few
requirements. I''ve also released a plugin that implements most of the
ideas.
(http://www.billkatz.com/authorization)

Both Ezra and I have similar ideas, so we''re going to collaborate and
hopefully smooth away the rough edges. Once we have a workable authorization
DSL, we''ll definitely come up with a tutorial, but it''ll help
us if we get
input and feedback now.

I don''t think one way of authorization will rule them all and create
consolidation. It''s possible, though, that one authorization system
hits the
sweet spot of many Rail developers. I just want to get something that works
well for the web apps I''m developing, and I hope it works well for Ezra
and
whoever else finds it useful. An authorization system that is both simple
and meets my needs probably will not be useful to someone with very complex
authorization requirements. And that''s fine. Once we get to the stage
James
describes, it''ll be clear what each of the different systems provide
and if
there''s a clear path (or desire) for merging.
-Bill

On 2/26/06, Larry Kelly <larry@tellinkltd.com> wrote:
> On 2/25/06, Alex Young <alex@blackkettle.org> wrote:
> >
> > Alain Ravet wrote:
> > > Being free is not an excuse for poor/absent/less-than terrific
> > > documentation.
> > >
> > > Poor documentation is an insult to the community.
> > > It means "After spending days or weeks on writing the code,
I don''t
> > want
> > > to spend an hour or two or three writing a good doc
> > And therein lies the rub...  It takes more than an hour or two to
write
> > good documentation.  Good documentation must be consistent, readable,
> > and most importantly correct and up to date.  A documentation bug can
be
> >
> > much more pernicious than a code bug - apart from anything else,
it''s
> > impossible to test.  There''s a reason good technical writers
are paid
> > well.  The skill-set just doesn''t intersect that well with
coding.
>
>
>   I agree with Alex.  I recommend them to be included in all my projects.
> -Larry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060226/b0a06896/attachment.html

> EZ wrote:
> >> Documentation is always a good thing.
>
> Absolutely. Documentation isn''t just a /good/ thing, it''s
an /essential/
> thing if someone less-skilled than the creator is going to try to use
> the product.
Well, documentation is good, but I think good code is ultimately
better. Essential might be going too far.

As far as projects I''ve worked on, the more essential
documentation''s
been, the crappier the project''s been. Better projects have good
documentation you can skim.
> Where would Rails be without the Agile book?
Well, before the Agile book, Rails already had huge momentum.

On the other hand, I have to admit I have it, and I''ve read it, and
I''ve read bits twice. Documentation is definitely a good thing.
> Personally, I bet that Chad Fowler''s Rails Recipe (from the new
beta
> book) becomes the de facto RBAC standard within months after its
> print-publication.  It''s not that his is necessarily better than
anyone
> else''s; it''s that there''s nothing like solid,
step-by-step tutorial
> documentation to attract the attention of someone who''s already
> overloaded by learning a new framework and (probably) a new language.
> And if everyone''s using Chad''s, who cares how good the
others are?
I could totally see that happening, but I totally hope it doesn''t!

I have Chad Fowler''s "India" book, it''s absolutely
great, but maybe
this is the downside of having a ton of buzz. Copying stuff from
tutorials is pretty lame, and it does happen a lot.

Whether copying stuff from tutorials becomes the de facto standard
really depends on the Rails community, and the extent to which it
leans on tutorials vs. actually learning how to use the framework and
the language. Seems to be a pretty healthy culture, so hopefully it
can avoid that outcome.

Anyway -- responding to a different message -- on the idea of bad
documentation being an insult to the community, if you don''t like the
documentation, can''t you just fix it? Isn''t that the whole
point of
open source?

--
Giles Goat Boy

http://gilesmakesmusic.blogspot.com
http://gileswritescode.blogspot.com

Hi, has this been added to the gem repository?

Thanks in advance,

-Conrad

On 2/26/06, Giles Bowkett <gilesb@gmail.com>
wrote:
> > EZ wrote:
> > >> Documentation is always a good thing.
> >
> > Absolutely. Documentation isn''t just a /good/ thing,
it''s an /essential/
> > thing if someone less-skilled than the creator is going to try to use
> > the product.
>
> Well, documentation is good, but I think good code is ultimately
> better. Essential might be going too far.
>
> As far as projects I''ve worked on, the more essential
documentation''s
> been, the crappier the project''s been. Better projects have good
> documentation you can skim.
>
> > Where would Rails be without the Agile book?
>
> Well, before the Agile book, Rails already had huge momentum.
>
> On the other hand, I have to admit I have it, and I''ve read it,
and
> I''ve read bits twice. Documentation is definitely a good thing.
>
> > Personally, I bet that Chad Fowler''s Rails Recipe (from the
new beta
> > book) becomes the de facto RBAC standard within months after its
> > print-publication.  It''s not that his is necessarily better
than anyone
> > else''s; it''s that there''s nothing like
solid, step-by-step tutorial
> > documentation to attract the attention of someone who''s
already
> > overloaded by learning a new framework and (probably) a new language.
> > And if everyone''s using Chad''s, who cares how good
the others are?
>
> I could totally see that happening, but I totally hope it doesn''t!
>
> I have Chad Fowler''s "India" book, it''s
absolutely great, but maybe
> this is the downside of having a ton of buzz. Copying stuff from
> tutorials is pretty lame, and it does happen a lot.
>
> Whether copying stuff from tutorials becomes the de facto standard
> really depends on the Rails community, and the extent to which it
> leans on tutorials vs. actually learning how to use the framework and
> the language. Seems to be a pretty healthy culture, so hopefully it
> can avoid that outcome.
>
> Anyway -- responding to a different message -- on the idea of bad
> documentation being an insult to the community, if you don''t like
the
> documentation, can''t you just fix it? Isn''t that the
whole point of
> open source?
>
> --
> Giles Goat Boy
>
> http://gilesmakesmusic.blogspot.com
> http://gileswritescode.blogspot.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Am 28.02.2006 um 21:12 schrieb Conrad Taylor:
> Hi, has this been added to the gem repository?
ActiveRBAC is a Rails Engine (and thus a rails plugin). You can  
easily install it (to /vendor/plugins) using:

   ./script/plugin discover
   ./script/plugin install active_rbac

in a Rails >= 1.0 project.


*m

Hi, it be possible to install this using the following:

sudo gem install active_rbac

?

If not, then what directory does one execute the below named commands?

Thanks in advance

On 2/28/06, Manuel Holtgrewe <purestorm@ggnore.net>
wrote:
>
>
> Am 28.02.2006 um 21:12 schrieb Conrad Taylor:
>
> > Hi, has this been added to the gem repository?
>
> ActiveRBAC is a Rails Engine (and thus a rails plugin). You can
> easily install it (to /vendor/plugins) using:
>
>    ./script/plugin discover
>    ./script/plugin install active_rbac
>
> in a Rails >= 1.0 project.
>
>
> *m
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060301/2bf35e7b/attachment.html

Am 01.03.2006 um 05:15 schrieb Conrad Taylor:
> Hi, it be possible to install this using the following:
>
> sudo gem install active_rbac
>
> ?
>
> If not, then what directory does one execute the below named commands?
You have to execute this in your rails project directory:

   rails my_project
   cd my_project
   ./script/plugin discover (or ruby script/plugin discover on Windows)
   ./script/plugin install engines (or ruby script/plugin... on Win)
   ./script/plugin install active_rbac (or ruby script/plugin... on Win)

ActiveRBAC will then be installed in vendor/plugins of your Rails  
project. You will have a resulting directory structure like:

   my_project
     app/        \
     config/      | as in all rails
     public/      | projects
     ...         /
     vendor/
       plugins/
         engines/      ActiveRBAC depends on the engines plugin.
         active_rbac/  ActiveRBAC itself.


You can also find these steps in the tutorial available at:

   https://activerbac.turingstudio.com/releases/ActiveRbacManual.pdf

Our mailing list could also help you:

   https://lists.cloudcore.com/mailman/listinfo/rbac-dev

Regards,

*m

Hello everyone,
newbie question concerning the installation of activeRbac on rails 1.1.1 
(ruby 1.8.4) MS xp.

The ActiveRbacManual says in section 1.2.1 (installation):
"As of Rails 1.0 we can use Rail?s built in plugin manager. First, we 
have to get
alistofallpluginsavailablethroughthepluginmanager. Enter./script/plugin
discover at your shell in your Rails project?s directory. Then, you can 
install
Rails Engines by typing ./script/plugin install engines."

which works fine. But then it says:
"After you have installed the engines plugin, you can go ahead and 
install
ActiveRBAC. The easiest way is - again - to use Rails?s plugin manager. 
Type
./script/plugin install active_rbac at your shell and ActiveRBAC will be 
installed in vendor/plugins ."

when I enter "ruby script/plugin install active_rbac" I get 
"Plugin not
found: active_rbac"
Do I have to store the activeRbac tar ball anywhere specific, to execute 
the command?
any clues?

many thanks,
Kleas

-- 
Posted via http://www.ruby-forum.com/.