RE: [ANN] ActiveRbac 0.3 release - We're now on Engines

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 :slight_smile: 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 F.'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

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

Am 28.02.2006 um 21:12 schrieb Conrad T.:

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

Hi, has this been added to the gem repository?

Thanks in advance,

-Conrad

Am 01.03.2006 um 05:15 schrieb Conrad T.:

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