Calagator first impressions
Robert Kieffer
I just installed Calagator on my local box as part of a [very brief]
evaluation for possible use for Central Oregon's tech community.
We're getting to where we have enough groups doing stuff that calendar
aggregation is getting to be an issue.
I wanted to share a few of my first impressions. Hopefully you'll find
them useful. And I'll apologize if there's anywhere i should have
done a better job reading the instructions or learning more about the
product. But... I've got a 10-month old (which is now my standard
excuse for *everything* I should be doing better.) Anyhow, here ya
go ...
----
- Pulling the source was easy.
- Installation was "mostly" easy. I already had solr and sqlite
installed, so no issues there. But I stumbled with the gems a bit.
The db:migrate command listed a bunch of gems that were required and
my first instinct was to install them manually. This worked for most,
but for others, like "will_paginate" and "has_many_polymorphs", it
didn't. I eventually found the "rake gems:install" command, but only
after a bit of googling around for error messages. You might want to
make that rake command as an explicit step in the INSTALL
instructions.
- "gems:install" should also install "sqlite3-ruby". 'had to do that
manually.
Other than that, getting it up and running was a breeze, so thank
you. Even with the gem issues, 'only took 20-30 minutes.
As for the functionality, I have a few comments. This is a cool
tool. The functionality and ease of use are very attractive, and well
suited to our purposes. But there are a few things that I think are
missing... or at least noteworthy.
On spam prevention:
- Have you had any issues with spam on calagator.org?
- The use of rel="nofollow" to discourage SEO hacking is a good idea,
but it needs to be applied to *everything*.
- The keyword blacklist feels like a red herring instead of a spam
solution. I would be much more comfortable if there were Akismet or
TypePad AntiSpam integration.
On access control:
- It's intriguing that there's no access control. I hate to say it,
but it's almost cute, charming even, that I can go to calagator.org
and delete events at will, without even having to login anywhere. Is
this part of the spam solution? Your audience just deletes any spammy
events for you? (If so, then this is kind of a showstopper for us.
We simply can't rely on having a big enough audience for that to
work.)
On theming:
- The theming system is basic, but works well enough. And once I
figure out how to configure it to use the "bend" theme directory I
created instead of the "default" one, I'll have more feedback for you.
That's it for now. Thanks for creating such a cool tool and open-
sourcing it. We're probably still a ways from actually setting up a
production system, but it's definitely on our radar.
Cheers,
- rwk
Audrey Eschright
Thanks for giving Calagator a try! When you have a public URL, I'll
add it to the wiki: http://code.google.com/p/calagator/wiki/CalagatorInTheWild
My comments are below, but the other developers may want to chime in
on a few things too.
On Feb 5, 2010, at 6:24 AM, Robert Kieffer wrote:
> On spam prevention:
> - Have you had any issues with spam on calagator.org?
> - The use of rel="nofollow" to discourage SEO hacking is a good idea,
> but it needs to be applied to *everything*.
> - The keyword blacklist feels like a red herring instead of a spam
> solution. I would be much more comfortable if there were Akismet or
> TypePad AntiSpam integration.
We do get occasional spam, but the keyword blacklist is surprisingly
effective. We also have an anti-bot field in the event and venue forms
that prevents most automated submissions. The most common thing we get
is two or three hand-entered spam events or venues, and they happen
infrequently enough to be manually deleted.
> On access control:
> - It's intriguing that there's no access control. I hate to say it,
> but it's almost cute, charming even, that I can go to calagator.org
> and delete events at will, without even having to login anywhere. Is
> this part of the spam solution? Your audience just deletes any spammy
> events for you? (If so, then this is kind of a showstopper for us.
> We simply can't rely on having a big enough audience for that to
> work.)
Calagator has a recent changes page (and RSS feed) at /recent_changes
that tracks all added, edited, and deleted items. Igal, Reid, and I
monitor this feed for spam, malicious edits, and so on. It's a pretty
easy task to keep up on if you have a couple people watching it. All
changes (including deletes) can be rolled back, so there's minimal
risk in allowing open access to change things.
It may help to think of Calagator as an events wiki rather than a
calendar service. It's really meant to be used as a community tool,
with multiple people adding, editing, and monitoring content. Don't
wait for those people to walk in on their own! Recruit from event
organizers, user group leaders, and other people you've worked with in
your community. We have people here in Portland who go out of their
way to make sure all events they're attending, not just organizing,
make it onto Calagator, and it's this sort of participation that keeps
the site thriving.
> That's it for now. Thanks for creating such a cool tool and open-
> sourcing it. We're probably still a ways from actually setting up a
> production system, but it's definitely on our radar.
Thanks, and please let us know how it's going as you get things up and
running. Would it be useful to have a Calagator Admin HOWTO page on
the wiki that talks about monitoring recent changes, duplicate content
squashing, and so on?
Audrey
Robert Kieffer
Yeah, I think an "Admin HOWTO" would be useful. Actually, there are several documents I'd like to see. An admin FAQ, for admins who need to make a decision about whether or not to use/try Calagator. An admin HOWTO for admins that need to manage Calagator. And a top-down design document might be useful too, for new developers/contributers. Something that gives a brief overview of the stack (RoR, SQLite, Solr) and the DB schema.
I really like the idea that anyone can enter an event - not just the event organizers. That solves a problem I haven't had a good answer to, which is how to convince the event organizers to use the system. Your answer, which I love, is, "you don't. but it doesn't matter 'cause somebody else will.")
I'm still not 100% sold on the anti-spam story. There is an implicit assumption that you have a large audience of people who are interested/willing to monitor activity. For people like me, who are just want to start out small and see how things go that's not really an option.
Anyhow, I'll keep you posted. Thanks!
--
You received this message because you are subscribed to the Google Groups "PDX Tech Calendar" group.
To post to this group, send email to pdx-tech...@googlegroups.com.
To unsubscribe from this group, send email to pdx-tech-calen...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdx-tech-calendar?hl=en.
Igal Koshevoy
> I'm still not 100% sold on the anti-spam story. There is an implicit
> assumption that you have a large audience of people who are
> interested/willing to monitor activity. For people like me, who are
> just want to start out small and see how things go that's not really
> an option.
recent changes feed. I've subscribed to this feed using an ATOM/RSS
reader that alerts me of new changes. It usually takes me less than 5
minutes to review the changes each day, so it's easy to stay on top of this.
What really takes time though is asking people to add events and helping
revise entries and suggest the improvements upstream so that these get
made next time by those closest to the event.
-igal
PS: Thanks for the detailed feedback, I'd like to incorporate the things
you suggested and pointed out. If you or someone can submit patches,
even to the documentation, that'd be a great way to help ensure that
this gets into the code. Else file some tickets with these items so we
make sure to resolve these issues.
Ryan Aslett
Igal Koshevoy
Almost all the spam that we have to deal with is added by humans. After their spammy event gets deleted a few times, they tend to give up.
-igal
Ryan Aslett
revise entries and suggest the improvements upstream so that these get
made next time by those closest to the event.
I have an application for the Knight News Challenge to develop a 'legacy web calendar' scraping tool to facilitate in the harvesting of events based data from semantically poor event resources. I'd really appreciate any feedback, ideas, comments y'all might have. (I mentioned calagator.org in my application).
Please have a look:
http://tr.im/MkRo
Thanks,
Ryan