We’re pleased to announce a new stable release of the Calagator platform, a well-tested version of the Calagator source code for those that want to run their own instance. Please note that this should be the final stable release of the Calagator platform based on Ruby on Rails 2.x, with future releases moving to Rails 3.x.

You can download this release from https://github.com/calagator/calagator/tree/v0.20111021 or checkout the “v0.20111021″ tag from the git repository at https://github.com/calagator/calagator

CHANGES (from https://github.com/calagator/calagator/blob/v0.20111021/CHANGES.md)

• [DEPENDENCY] Upgraded to Rails 2.3.12.
• [MIGRATION] Added venue details so organizers can specify per-event information like room number, access code, etc.
• [THEME] Added mobile CSS stylesheet for friendlier experience on smaller screens.
• Updated Upcoming importer to work around invalid UTC dates emitted by current API.
• Updated Plancast importer to use the new, official JSONP API.
• Updated Meetup importer to use the new, official API if a key is available. See instructions in `INSTALL.md` file.
• Update robot exclusion rules to allow Google Calendar to subscribe to filtered searches.
• Updated iCalendar exporter to include venue address and source URL.
• Added “opensearch” to let browsers use Calagator as a search provider.
• Added Vagrant support, allowing easy setup of a development environment. See instructions in `VAGRANT.md` file.

Participants

Roy Martin, Daniel Hedlund, Bart Massey, Selena Deckelmann, Leif Warner, William Van Hevelingen, Kirsten Comandich, Dunbar Aitkens, Mary Anne Thygesen, Reid Beels, Audrey Eschright and Igal Koshevoy.

Resolved

• Added mobile interface to improve user experience on devices with small screens. The new interface puts the most useful information at the top and makes better use of screen real estate, reflows text for graceful zooming, and hides infrequently-used features behind click-to-expand controls.
• Improved iCalendar exports and feed to include the venue’s address and Calagator source URL.
• Updated to Hpricot 0.8.4 library, which should eliminate or reduce segmentation faults, primarily encountered in tests.
• Fixed missing “bundle exec” references in documentation and webadmin service.
• Improved documentation to explain the search engine service ports used, which need to be firewalled.
• Fixed “Cinderella event” handling, so events ending at midnight aren’t shown as part of the next day’s listing.
• Added per-event venue details field, for describing the room used and other event-specific information.
• Improved Plancast importer to add machine tags to the event, so that their RSVPs and links are immediately available.
• Confirmed that all index and show actions can emit XML and JSON for those consuming our data.
• Fixed test suite to eliminate non-deterministic behavior caused by state leaking between tests.
• Fixed tests so they don’t access the network and fail.
• Refactored views that display subnav menus by extracting common logic into helpers.
• Removed custom geocoder keys in hopes of simplifying setup — only to have to revert these changes because the keys are still needed for displaying maps on anything other than “localhost”.
• Updated “Code” link in header to point to github.
• Removed unwanted files that were accidentally checked in.
• Added a custom iCalendar “prodid” value. Unfortunately, the patch to populate this with Unicode 6.0 glyphs of a crocodile, a calendar, and a happy-snowman-wearing-a-fez were rejected. This decision may need to be reconsidered in the future.

Closed completed issues

• Issue 434: Review and merge rical_remodel branch.
• Issue 443: Recent changes feed should link to both the change log entry and actual entry.
• Issue 357: Deleting sources should delete their associated events and children.
• Issue 424: Refresh version shouldn’t throw an exception.
• Issue 423: Calagator should be able to export events to Google Calendar.
• Issue 306: Submit patches to acts_as_versioned.
• Issue 316: Consider adding version number to iCalendar export.
• Issue 196: Fix acts_as_solr, make it log to a file.
• Issue 401: JSON should be supported by all controller actions.
• Issue 436: Solr’s admin port should not be publicly accessible.
• Issue 447: Import Plancast events.
• Issue 191: Submit patche to acts-as_solr that make it work.
• Issue 397: Timezone in settings should be used.
• Issue 24: Include venue information in iCalendar exports.
• Issue 339: User should be able to create a new event from an old one.

Added and updated issues

• Updated Issue 387: Add JavaScript widgets and usage instructions.
• Added Issue 450: Write guide with per-platform installation instructions.
• Added Issue 451: Add per-item duplicate squasher.
• Added Issue 452: Add fuzzy venue search.
• Added Issue 453: Improve the import system.
• Added Issue 454: Migrate to Ruby on Rails 3.

Thank you for your contributions and support!

-igal

You can download this release from https://github.com/calagator/calagator/tree/v0.20110603 or checkout the “v0.20110603″ tag from the git repository at https://github.com/calagator/calagator

KEY

• [!] – Important note regarding some change.
• [THEME] – Changed theme structure, see the `themes/README.txt` file for details.
• [SETTING] – Changed setting structure, see the `themes/README.txt`file for details.
• [SECRETS] – Changed secrets structure, see the `INSTALL.md` file for details.
• [MIGRATION] – Change schema, run `bundle exec rake db:migrate` to apply.
• [DEPENDENCY] – Changed dependencies.

CHANGES (from https://github.com/calagator/calagator/blob/v0.20110603/CHANGES.md)

• [DEPENDENCY] Added `bundler` for installing dependencies and isolating from unwanted versions of gems. See `INSTALL.md` for usage information.
• [MIGRATION] Added fields to Venues: access notes, “has public wifi” flag, and “is closed” flag.
• [THEME] Added file to describe appropriate content for a Calagator instance, e.g. “Portland-area tech events”. If not present, a reasonable default will be displayed.
• [SETTING] Removed `tz` field. You now only need to set `timezone`. If theme still has `tz`, it will be ignored.
• Fixed documentation to explain how to create a theme, setup a `development` environment, and install a `production` server.
• Fixed export to Google Calendar, which could fail if the event’s description was long or truncated at a bad place.
• Fixed exception notification to send emails with Rails 2.3.10 and newer, submitted fix as patch to `theme_support` plugin maintainer.
• Fixed exception notification to set `From:` in a helpful way so that these can be replied to by those subscribed to notifications.
• Fixed previewing of a new event with a new venue, it would throw an exception.
• Fixed duplicate squashing to not throw exceptions if called with blank arguments, like when hit by a bot.
• Fixed version refresh system, used on event/venue edit forms, to switch between versions of a record.
• Added parsers to import Plancast and Meetup events.
• Added Plancast machine tag to connect Calagator events with their external Plancast counterparts and display Plancast attendees on the event page.
• Added ePDX machine tag to connect events with their ePDX groups.
• Added JSON and KML exports to the venues listing.
• Improved iCalendar importing system to use the better `RiCal` library.
• Improved venues listing to show the latest and most popular venues, search venues, display map, etc.
• Improve display of URLs on various pages by truncating them if they’re long.
• Improved imported sources so they can be deleted and remove their associated event and venue records.
• Improved recent changes rollback system to display messages, be able to rollback the `create` events, and redirect to appropriate pages.
• Improved event form to accept URL parameters, so it can be pre-populated with desired values.
• Improved venue destroy to prevent someone from removing a venue that still has events, to avoid orphaning these.
• Improved new venue form to accept simplified address and not request longitude/latitude.

Thank you for your support, and we’ll hopefully see many of you at the Calagator code sprint tomorrow at the PDX11 Civic Hackathon: http://calagator.org/events/1250460557

-igal

Popular tags for events are displayed in the left sidebar of the main page:

If you go to an event page that has tags, you will see something like this:

Click on any tag’s link and it will take you to a search page with all events (or venues, if you’re on a venue page) that share that tag name.

Calagator also recognizes a special kind of tag, known as a machine tag. Machine tags are a way of providing short pieces of structured data. In our case, we’re using them to link to the Plancast or Upcoming pages for an event, letting you see who else you know might be attending.

Not only that, but thanks to a contribution by Max Ogden, Plancast tags do one more thing:

All attendees for that plan are displayed on the Calagator event page. Pretty neat.

The basic format for a machine tag is ‘source_name:reference_type=reference_id’. For Plancast, that looks like ‘plancast:plan=plan_id’ (you can get the plan id from the url on their site).

Our tag model includes a list of sources and types of links currently supported. In addition to the two sources mentioned above, useful for events, you can tag venues with the relevant Foursquare, Gowalla, and Shizzow links. We also have support for ePDX tags, which can be used to link to things like a sponsoring company, the person who’s organizing an event, or the user group the event is part of.

I’ve published a new stable release of Calagator. You can download this release from https://github.com/calagator/calagator/tree/v0.20110301 or checkout the “v0.20110301″ tag from the git repository at https://github.com/calagator/calagator

v0.20110301:

• [!] This version adds support for specifying the search engine to use for local data. The new default is `sql`, which requires no configuration or setup to work. If you have an existing Calagator instance and want to continue using ActsAsSolr, edit your `config/secrets.yml` file and specify `search_engine: acts_as_solr`. See the “Search engine” section of the `INSTALL.md` file for details.
• [SECRETS] Added `search_engine` field for specifying search engine.
• [DEPENDENCY] Upgraded to latest stable releases of Ruby on Rails and other libraries. Use `rake gems:install` to install them.
• [DEPENDENCY] Added optional `sunspot` search engine, which provides the best search results and is more reliable, efficient and speedy than `acts_as_solr`.
• Fixed importing to support Upcoming’s mobile site, the only one many users can now use.
• Fixed performance of duplicate checking and squashing interfaces.
• Fixed exceptions thrown when filtering events by invalid dates.
• Improved dependencies so production environment doesn’t need testing libraries.
• Added `sql` search engine, which is used by default and requires no configuration or setup.

Now: you ask, we attempt to answer. The response is behind a cut because it’s a bit long; different core team members often have different approaches to things, so we included two responses.

Aaron says:

I use Upcoming or Eventbrite so that I can manage RSVPs for a variety of free events… I know that you guys have been working on the feature for a while; it’s really the one reason why I don’t pay much attention to Calagator at this point. While I’d love to support the local guy, I need the features that the non-local guy has :/

Audrey replies:

Why doesn’t Calagator have an RSVP feature?

Two big things have to happen to get a new feature into Calagator: we have to decide how it will work, and we have to write the code.

Deciding how RSVPs should work involved quite a bit of debate. A system like Eventbrite’s where people RSVP directly to the event organizer doesn’t really make sense for us–we can’t guarantee that the event organizer even uses our site, since events can be added by anyone. Calagator’s goal is to be an event repository, but not necessarily the only or even primary source of information about that event. Eventually we decided that we could probably do a feature where users say “hey, I’m going to this event”, like a public bookmark. We could use OpenID to let people save and retrieve their event bookmarks. This seemed like a good enough idea to start working on it.

Which brings us to the second half, actually writing the code. We got most of the way through implementing this before being derailed by–honestly, I don’t remember what. Something else that needed to get done. Now the code in that branch is probably really out of date, and will take more work to bring it in line. This is the downside of being a volunteer project; we just don’t have time to work on everything we’d like to.

Will Calagator have a RSVP feature eventually?

Well… I don’t want to promise anything. If someone were to pay for the developer time to do it then I think we could guarantee it would happen. But personally, I admit I have a fair amount of ambivalence about this, even as a fellow organizer of free community events. I haven’t really missed Calagator having a RSVP tool, most of the time. It’s not that it’s a bad idea, just that I don’t know if it’s the most Calagatorish thing to do. Events have a lot of different potential RSVP needs (do you want a rough head count? do people need to RSVP to attend, even if it’s free? do they need to buy a ticket?) And there are services that cover each of these use cases separately: Plancast lets you tell your friends where you’ll be, Upcoming is good for a general head count, and Eventbrite lets you sell (or hand out for free) event tickets. So the most appropriate thing might be for us to link into those other services so you can see the information reflected on the Calagator event page. I don’t know. We’ll see.

Igal replies:

Community involvement is vital to Calagator’s success — it’s where we get our content, it’s who we serve, and it’s why we’re doing “Ask Calagator”. Sometimes figuring out how to do something is tricky, and it becomes important to have those that most want a particular feature step forward and describing their vision in greater detail to help those that will implement it.

Calagator is useful as it is for those that need RSVPs now for their events. People publish events requiring these to Calagator to publicize them, and explain in the event’s description of that attendees must reserve or purchase a ticket from another website.

While services like Eventbrite focus on individual ownership of an individual event, Calagator focuses on collective ownership of an entire community’s events. I don’t feel we can add RSVPs to Calagator because it’s designed to let anyone in the community edit events and RSVPs would require us to limit the editing of events to only their owners. However, it is possible to stay within Calagator’s nature and still provide useful information about who is interested in or going to an event.

Last year, I built an experimental Calagator “my_events” branch that provided this functionality. It allowed people to login via OpenID and publish their interest in an event — these are more like user’s favorites, rather than event’s reservations. The new functionality provided a headcount and roster for each event; allowed users to see what events they’d marked and get an iCalendar feed; and allowed people to view others users marked events and subscribe to them.

I didn’t get much positive feedback on this demo’s functionality, with most people complaining about things that I couldn’t do: it didn’t provide real RSVPs, didn’t sell tickets, and wasn’t integrated into their closed source software (e.g., social network, calendaring app, etc). I couldn’t rally support for completing or improving this functionality, so this work was abandoned.

If there’s a renewed interest in this sort of functionality, I’d like to have people lend us a hand by describing some specifics of what they would find useful for us to build, before we throw any more code at this.

'Calagator Loves You' session at BarCampPDX - photo by Selena Deckelmann

Maybe you already know everything you want to about Calagator. It is pretty easy to use, after all. But perhaps after over two years of it being out in Portland’s tech community (as well as communities around the world), there are a few things you’d like to find out. Post your questions in the comments and we’ll do our best to answer them here on the blog.

We made good progress at Saturday’s sprint. Perhaps the most exciting bit of news is that Igal’s “with_theming” branch has now been merged into the main code. This means that Calagator now has support for other groups using our software in their own communities, with custom text and styling.

Before this, people had to edit out the Portland-specific parts by hand. There are already users in Sweden and Vancouver, BC running their own Calagator instance, and this update makes the process much easier. We’re working on fleshing out the documentation, but take at look at the theming README to get started.

Other documentation on how to install, use, and contribute to Calagator is available on our Google Code wiki.

Our code sprinters have enjoyed working on the project. “Lack of time” seems to be the most common reason for not being involved more. We recently created guidelines for submitting a patch, so people will be able to contribute even if they can’t get to code sprints. Our hope is that this will encourage contribution from outside Portland as well.

The most popular requests for where we go next involve expanding Calagator to other areas, and allowing users to mark what events they’ll be attending. The work on those features is just about ready for primetime. You can follow the progress on our mailing list, or check back for further announcements in a couple weeks.

One of the things I’ve been impressed by is how many more tech events Portland has now that there’s a central calendar to find them. In the last year we’ve gained a number of new groups and events that were enabled by people being able to see what else was going on, and what needs aren’t being met. These events are able to grow beyond the organizer’s personal network because there’s someplace the entire community is watching. That’s inspiring.

The usefulness of such a tool has not escaped notice outside the Portland area. Our code has always been available to fork and use elsewhere, but now that we’ve started to add support for re-theming, we’re seeing more people setting up their own copy for another community they’re involved in. We hope that Calagator will eventually be able to support many different areas from the same site, but there’s much work needed to get us there. In another year, maybe we’ll be able to show you a giant starfish of a Calagator, connecting people from around the world.

So yes, it seems we succeeded. Which is not to say that there’s nothing left to do. We have a pesky recurring events requirement that’s turned out to be very complicated to implement, as well as a number of other improvements in the tracker. And that’s before we get into the whole world domination thing. I hope you, the Portland tech community, and those in places beyond, will continue to follow along and join us in creating “the best calendar aggregator possible”.

Today Calagator is one year old. From the mailing list report on our first code sprint:

Update for 1/19 (first meeting): Today several of us met during the Code Sprint gathering at CubeSpace to talk and work on the calendar. … The first draft of the application is available at http://calagator.org/

In just one meeting we had a working application with basic features. Since then we’ve fleshed it out substantially, but of course there’s so much more to do. Please join us for a first birthday code sprint and party afterward, on January 24th, to celebrate how far we’ve come from “wouldn’t it be nice to have a community calendar anyone could edit?”, and build toward future awesomeness.