DIY
Scott Woods
up, what does everyone think about ditching it in favor of our own
Ruby-on-Rails-based forum and website?
We could install Beast (http://beast.caboo.se/) for the initial forum
software on our own domain. Since it's open source Rails code, it
would provide a great basis for a website for the group (which we'll
probably want to have at some point anyway), since we could customize
it as much as we want. Something like, say, this:
We could add a home page, a calendar of events, etc. Since the site's
running on Rails, we just add whatever functionality we'd like to
have. It could be a great demonstration for new people of a real site
in Rails, and how you do development and deployment. Also, the Beast
software itself is considered to be a really good example of Rails
coding. We'd be off to a good start with near zero effort.
We could also have a subversion repository for everyone to use
(Subversion is the source code control system that most ruby/rails
developers use to track their changes and publish source code). We
could keep the code for the website itself in there, as well as any
projects that we wind up working on collaboratively. It could be
publicly accessible, so we could use it to publish open-source
software and rails plugins, but only members of the group would have
commit access. Something like this, for example:
http://svn.statecollegeruby.org/
We can put a much nicer web-based subversion browser on there, one
that lets you browse the change history and notes easily, rather than
the plain old one that you see now, by the way.
Needless to say, I guess those are rather complete examples :) We
already have the production servers here running the same software, so
it didn't take much time at all to set the site and services up. I
figured it would be easiest to just illustrate what I was talking
about so that everyone could kick the tires a little.
I figure we might as well use the tools that we're talking about, and
set up a repository that will make it easier for everyone to browse
and share code.
Let me know what you think. There's no pressure to use any of this if
you don't think it's worthwhile.
Scott
Matt Swayne
Andrew Shindyapin
Andrew Shindyapin
Scott Woods
basically the URL that will identify you. You need an OpenID provider
for this. The one that I used is http://myopenid.com and it's
completely free. They'll ask you to choose your URL when you create
your account. I picked http://scott.woods.myopenid.com.
Now whenever you go to a site, you can check to see if they support
OpenID. If they do, you can put in your OpenID URL, and then there's a
little exchange between the two servers. If it's the first time that
server has connected to the OpenID server, the OpenID server will ask
you if you want to allow connections from the other server forever or
just once. Then it should sign you in to the remote site.
When I first heard about OpenID, it took me a little while to really
understand what it was good for. The standard OpenID sites aren't very
good at explaining this. I think the best reasons to use it are:
1. Your password is stored once on the OpenID server. If you want to
update your password, you change it once there, instead of having to
change it on a million other sites (or just leaving the old bad one).
2. Password storage, encryption, and authentication is handled by the
OpenID provider, who presumably knows what they're doing. This means
that all those other sites that you visit don't handle your password,
so they can't abuse it or disclose it. This is important since almost
everyone uses the same password for many websites.
3. It's new, and everyone else seems to think it's cool, so I guess I
should too.
In my experience, it hasn't saved me entering my password. In fact, I
have to enter it a bit more frequently, since many sites store
standard password cookies for so long, I wouldn't have to re-enter my
password there for months. But at least it's always the same password,
encrypted, to the same server.
Does anyone else have a different take on it all?
Scott
On Aug 20, 8:08 am, "Andrew Shindyapin" <andrei.shindya...@gmail.com>
wrote:
> Ooh. an OpenID login is possible... anyone know how to set this up?
>
> On 8/20/07, Andrew Shindyapin <andrei.shindya...@gmail.com> wrote:
>
>
>
> > Great idea...this gets a yes vote from me :)
>
Scott Woods
the content from the google group over to the new site without any
trouble, once everyone has created their account on the new site. So
we shouldn't lose anything.
Downsides to beast vs google groups:
* no support for file uploads (yet)
* no email notifications (yet) use RSS instead
* no support for static pages (yet)
None of these things would be difficult to add to beast at all. In
fact, we could probably easily do one of them during a meeting, if
that seemed worthwhile.
Scott
On Aug 20, 4:44 am, "Matt Swayne" <matt...@gmail.com> wrote:
> That works for me.
>
Andrew Shindyapin
Scott Woods
Very true. We could certainly install a separate wiki instead,
especially if there's not much interest in modifying beast. Of course,
I thought that rolling our own would be half the fun :) Plus we'd get
integrated authentication with a custom beast (rather than separate
wiki and forum accounts).
By the way. if you're looking for a rails-based wiki engine, I'd
probably recommend instiki (http://instiki.org/) -- it's been around
forever (well, at least as long as rails has), and it's used by a few
big sites. It used to run http://wiki.rubyonrails.org, for example,
before they customized it to handle the load. MaxWiki looks like they
registered the project, but haven't released any code yet.
Anyway, I guess we'll just see how it pans out -- if for some reason
we don't modify beast, we should certainly just throw a wiki up there
so that we're not missing out on those features (thanks for the
suggestion). I suspect that it will be surprising how easy it is to
add them to beast though.
Scott
On Aug 20, 9:39 am, "Andrew Shindyapin" <andrei.shindya...@gmail.com>
wrote:
> All the downsides you mentioned can be rectified with a wiki. I found an
> open-source RoR wiki called MaxWiki. Here's the url for it:http://rubyforge.org/projects/maxwiki
>
> Is this something that would be helpful (versus rolling our own)?
>
Andrew Shindyapin
> > > > We could install Beast ( http://beast.caboo.se/) for the initial forum
Anthony Navarre
Scott Woods
On myopenid.com, all they let me specify are some fairly lame
(infrequently requested) fields, e.g. nickname, date of birth, zip
code (but no address), gender, etc. Bummer that they don't seem to
support your mailing address and your avatar. It looks like it's not
supported in the spec. Here's an example of the spec for openid simple
registration, with the supported fields near the bottom of the post:
http://www.openidenabled.com/openid/simple-registration-extension
It seems incredibly lame that they don't support things like mailing
address, phone number, mugshot, etc.
However, I've been loving gravatar for having ubiquitous avatars
(mugshots). It provides a service where sites can retrieve and display
your avatar if they know your email address. Kind of spooky when you
register for an unrelated new site, supply your name and email, and
then your photo pops up! But very useful. Beast uses it -- if you
register with http://gravatar.com, your photo will show up next to
your posts on statecollegeruby.org. We also made an embarrassingly
simple rails plugin for displaying gravatars in your own applications.
Basically you can just do "gravatar_for @user" in your views, and it
will replace it with the HTML for displaying the gravatar image:
http://gravatarplugin.rubyforge.org/
On Aug 20, 1:42 pm, Anthony Navarre <t...@navarremedia.com> wrote:
> Hey guys!
>
> If I might weigh in on this, why don't we do both? If the goal of the
> group is to challenge and educate all of the members (from "just
> interested" to "veteran" Ruby & Rails users) then I'm sure that
> everyone involved will benefit by having access to "the wiki way" as
> well as having some exposure to the "roll your own" approach.
> Besides, if you guys are like me, doing work for a variety of
> clients, you most likely find that sometimes a wiki will do just fine
> whereas other times a fully-blown custom CMS is in order.
>
> One more thing to add about the OpenID discussion: I seem to recall
> that the OpenID architecture allows for more than just a username and
> password. Doesn't it also allow for a kind of "profile?" I think if
> this isn't already available for OpenID, others have been working on
> the concept at least, thus allowing your mugshot, perhaps a shipping
> address, a nickname, and all sorts of other data to be available by
> using the single username and password. That way, you could change
> your mugshot on your OpenID and it would automatically update for all
> the sites that use it.
>
> On Aug 20, 2007, at 1:02 PM, Andrew Shindyapin wrote:
>
> > Scott,
>
> > if it's as easy to do as you say, then let's roll our own :~)
>
> > On 8/20/07, Scott Woods <scott.a.wo...@gmail.com> wrote:
>
> > Hey Andrew,
>
> > Very true. We could certainly install a separate wiki instead,
> > especially if there's not much interest in modifying beast. Of course,
> > I thought that rolling our own would be half the fun :) Plus we'd get
> > integrated authentication with a custom beast (rather than separate
> > wiki and forum accounts).
>
> > By the way. if you're looking for a rails-based wiki engine, I'd
> > probably recommend instiki (http://instiki.org/) -- it's been around
> > forever (well, at least as long as rails has), and it's used by a few
> > big sites. It used to runhttp://wiki.rubyonrails.org, for example,
> > > > > > We could install Beast (http://beast.caboo.se/) for the
Anthony Navarre
I've seen that Gravatar logo in plenty of places but never looked
into it. It's a shame the OpenID spec doesn't already get into this
and other stuff like shipping address. Could be very cool so long as
the more sensitive data (like shipping address) were protected by
some sort of privilege-based authentication (ie: username, password,
and checkbox for "allow this site to access my shipping address").
Better still would have been support to simply upload / download a
vcard from the myopenid website. I swear I've heard about the support
for these kinds of extras somewhere before, although it would be nice
if these were my own ideas, independently cooked and all.
On a somewhat related note, I've started using the hcard spec (http://
microformats.org/wiki/hcard
) for almost every project recently. Check out the contact page on
www.mtnittanywinery.com for a sample of how I've approached it ...
perhaps the group site or group members can benefit from / expand
upon what I've done with it.
Scott Woods
Nice. Now I have to put my code where my mouth is.
(I guess that's how to use that saying in this context)
On Aug 20, 1:02 pm, "Andrew Shindyapin" <andrei.shindya...@gmail.com>
wrote:
> Scott,
>
> if it's as easy to do as you say, then let's roll our own :~)
>
> On 8/20/07, Scott Woods <scott.a.wo...@gmail.com> wrote:
>
>
>
> > Hey Andrew,
>
> > Very true. We could certainly install a separate wiki instead,
> > especially if there's not much interest in modifying beast. Of course,
> > I thought that rolling our own would be half the fun :) Plus we'd get
> > integrated authentication with a custom beast (rather than separate
> > wiki and forum accounts).
>
> > By the way. if you're looking for a rails-based wiki engine, I'd
> > probably recommend instiki (http://instiki.org/) -- it's been around
> > forever (well, at least as long as rails has), and it's used by a few
> > big sites. It used to runhttp://wiki.rubyonrails.org, for example,
> > > > > > We could install Beast (http://beast.caboo.se/) for the initial