[portland] Reservation system code sprint update: October 4

Igal Koshevoy igal at pragmaticraft.com
Sun Oct 5 19:15:34 CEST 2008


Sorry for cross-posting, but many of yesterday's developers weren't part
of the mailing list that I normally post technical updates to. Please
post comments on this message only to the mailing list at
http://groups.google.com/group/pdx-tech-calendar/ to avoid the
discussion from getting scattered across a bunch of lists and to help
more Calagator developers see your comments. Thanks!


SUMMARY

At the sprint, we wrote up a feature list for the app. We ended up
working on two different implementations of the application. A demo of
one of the implementations is online at
http://calagator-with-reservations.demo.pragmaticraft.com:81/


DETAILS

The sprint was very productive. Many thanks to Jeff for organizing it
and to the attendees for participating.

We produced a feature list for the new project, available at:
http://code.google.com/p/csvp/wiki/Features

There were many common areas of agreement, but it soon became clear that
there were mutually incompatible goals, priorities, and implementation
approaches, so we decided to split up into two teams that worked
separately on their own implementations:

1. One team wanted to build a new application using Python and Django
that -- as I understood it -- was intended to be a general-purpose
reservation aggregation system that other systems could also access
through a web service API. Jeff lead this effort and will post an update
about what this group accomplished and what it's future plans are.

2. Another team wanted to add basic reservation features to the existing
Calagator application. We completed a working demo, available online at
http://calagator-with-reservations.demo.pragmaticraft.com:81/

DO NOT PUT ANY DATA YOU WANT TO KEEP IN THE APP ABOVE, IT'S JUST A DEMO!


This demo app provides the following new features compared to the
current Calagator.org:
* Users can login via OpenID -- the login link is on the right-side of
the menu
* Users are automagically routed through the login form if they're not
logged in and try to perform an action that requires an account, such as
making a claim that they're going to an event
* Users can go to their account page and see their reservation statuses
per event
* Users can go to an event page and view their reservation status for
the event
* Users can go to an event page and set their reservation status using
an unobtrusive AJAX control
* Users can go to an event page and see a total count of reservations by
status
* Users can go to an event page and expand a section to see a detailed
list of reservations by status

Assuming the text and UI are improved, are the minimalistic features
seen in this demo adequate for your basic reservation needs? If not,
what do you feel is critical for this to be useful to you?


I didn't commit these changes to the main Calagator code repository, but
instead published a fork at
http://github.com/igal/calagator_with_reservations/tree/with_reservations

This code isn't in the main repo because it diverges from what was
agreed to by the Calagator team the last time we talked. There was no
plan to add a reservation system in the roadmap to Calagator 1.0, so
incorporating this will delay the release of 1.0 because time will have
to be spent finishing this new functionality and bringing the UI and
code to Calagator's high quality standards. Also, adding logins was
something that the Calagator team tried very hard to avoid ever since
the project's inception, however, I think this fork honors the original
spirit by not taking away anything from anonymous users, providing them
with at least read-only access to reservation information, and providing
complete access to logged-in users.


There were at least three different approaches discussed for what ought
to be done next:

1. This fork should be improved and merged back into the existing
Calagator code, while the new Django app goes its separate way as a
general-purpose reservation system

2. This fork should be abandoned and an effort made to implement these
features with the new Django app and alter the Rails application to
couple it to the Django application

3. This fork should be abandoned and no integration added between the
Rails application to the Django application, and let the reservation
system live an entirely separate existence

Which of these directions appeals to you? Or can you suggest a better path?

-igal


More information about the Portland mailing list