The first draft of the application is available at http://calagator.org/
This barebones application:
- Lets you import events from hCal (e.g., point it at an Upcoming event)
- Lets you search/view/add/edit/delete events using a form
- Lets you search/view/add/edit/delete venues and assign them to events
For example, I've manually added an entry for the Code Sprint and
imported the Upcoming event for Ignite Portland 2.
The application isn't currently a masterpiece of design, usability or
functionality, but rather the first of many steps. It provides a minimum
amount of features and infrastructure so that we can incrementally
improve it as we work towards greater goals.
A lot of the work that's gone into this isn't visible through the
- A parser abstraction system that lets us easily add drivers that can
read more calendaring formats without having to rewrite our existing code.
- A new WordPress blog I setup at http://blog.calagator.org/ that needs
to be populated. I've given admin rights to Audrey and Selena. The
advantage of having this run on our server is that we can set the URL
and have full control over how it works as opposed to the one hosted off
- A password-protected web-based application administration system that
makes it easy to start, stop, restart, deploy and rollback the
application at http://calagator.org/ from a browser. This tool has its
own logins which can be given away more liberally than SSH accounts into
the production system. I've given Audrey rights to create additional
accounts. I made this as a stand-alone Ramaze application, so it can
manipulate the Rails app running calagator.org without being dependent
on any its code, thus making it possible to rollback a broken version of
- An AutomateIt recipe that automatically sets up the entire
calagator.org server. The recipe is run against a freshly-installed
Ubuntu server and does everything else, like setting up the OS, creating
UNIX users, installing dependencies, checking out the application,
managing the mongrel cluster, creating nginx proxies, setting up
Wordpress, etc. This lets me easily build and maintain a staging server
and reduce surprises by only deploying well-tested changes into
production. This automation will also help us more easily expand, adapt
and migrate the system in the future.
Anyway, I think we have most of the infrastructure in place that will
give us a stable platform and let us focus on adding new features that
people can see.
PS: I've also registered calagator.com and calagator.net, and rewrite
any requests that come in through these domains to the .org site.
Will it be able to aggregate for other communities besides the tech
community. I know I am involved with other groups that could really
use similar tech.
The beauty of this open source development model is that the
deliverables are whatever people find important enough to contribute. So
the way it looks, how easy it is to use, how well it meets people's
needs, how sophisticated its features get ... all these are dependent on
who can make time to work on this. If those other groups can get
involved, we'd be glad if they can join us so those features can be
> I added one as a test - 'Show a Calendar'....
Perfect, thanks. Let's stick with the Google code issues tracker
until there's a reason to move. I think it'll be simpler to have the
code and bugs and feature requests all in one place.
Because I am new to this, how do you all want to track bugs/issues?
It looks like importing does not automatically add the venue, at least
when I just tried.
Also, when importing from eventful, which appears
to also use hcal, the link is broken.