compinabox-discuss — Discussions on CompInaBox development

[CompInaBox-discuss] User "types" -- personal and functional

[Eric D N. <nie...@MI...>]

In the past all "types" of users were shoehorned into the same class.
All users had a username, password, and a linked person (who has at least a
primary email).

However, a lot of teams use a functional account for their group registration --
ie the account is shared by mutliple team officers -- so the linked "person"
often ending up being (firstname: Brown; lastname: Ballroom; email:
officer_email@...),  Rather than having each officer create an individual
account and then grant appropriate permissions down the chain, the functional
account is labelled as a "Team Captain" with full rights over their team.  As
officers come and go, there isn't a need for yearly/semesterly grant/revoke
(thought some teams might need to worry about password changes to keep possibly
disaffected ex-officers from causing problems, of course).

As I'm currently working on the user-based registration process now, I wanted to
re-examine this.  Some questions:

1) I'm  planning to create a class hierarchy for users
(User<-[Personal|Functional]) so that functional accounts aren't forced into
having first and last names, etc.  Any reasons not to?

2) Are there other different types of accounts that I should consider (note, not
different access levels that's an independent axis that I think I have well
under control).

3) Is there a better name for the personal v. functional account that is likely
to be easily understandable? personal v shared?  With my previous military
experience and work in matrixed organizations, functional makes total sense to
me, but I don't know if its clear to others....

Thanks,

Eric

Re: [CompInaBox-discuss] creating user accounts

[Stephen G. <gi...@st...>]

>   What's your opinion about creating an account automatically for the
>   partner of the person registering?

Seems reasonable.  I remember one couple where he always misspelled
his partner's name when he registered them.  It would have been handy
for her to have been able to easily log in and update herself.

 < Stephen

Re: [CompInaBox-discuss] creating user accounts

[Eric D. N. <nie...@MI...>]

On Aug 14, 2006, at 10:09 PM, Stephen Gildea wrote:
> I don't mind the "you need to create an account" aspect.  I suspect
> that most competitors are repeat visitors and so won't mind creating
> an account.  You might even be able to design the pages so the account
> creation doesn't require an extra page.

What's your opinion about creating an account automatically for the  
partner of the person registering?

> You collect their email address; why not use that as the name of their
> account?

That can work, but people's email accounts are relatively mutable  
(however it won't be a primary key, so I guess that's ok).  However  
there is the problem with mutliple people using one account -- some  
teams (Tufts, Yale, etc) tend to register their entire team under one  
email address.  Some married couples only have the one account, etc.

>
> Using a funny character to distinguish auto-generated accounts seems
> kludgey.  Why not just add an attribute "needs new password".  You
> might find yourself using that attr again if you implement a "reset my
> password and email it to me" feature.

Agreed.  The "needs new password" bit is always needed, the "needs  
new username" is the one I'm questioning.

Eric

[CompInaBox-discuss] creating user accounts

[Stephen G. <gi...@st...>]

I don't mind the "you need to create an account" aspect.  I suspect
that most competitors are repeat visitors and so won't mind creating
an account.  You might even be able to design the pages so the account
creation doesn't require an extra page.

You collect their email address; why not use that as the name of their
account?

Using a funny character to distinguish auto-generated accounts seems
kludgey.  Why not just add an attribute "needs new password".  You
might find yourself using that attr again if you implement a "reset my
password and email it to me" feature.

 < Stephen

[CompInaBox-discuss] Compinabox using Ruby on Rails Update...

[Eric D N. <nie...@MI...>]

Here's an update on the compinabox rewrite to RoR for the list (and a few others
BCC'd)

I was at a Ruby on Rails training studio for most of last week, and while I had
already taught myself most of what they were teaching, I did come away with a
lot of using tidbits, not to mention living Rails for three days 9-5 in class,
plus hacking away 6-midnight most evenings can really help.

I know I've been saying this for a while, but I am very closs to deploying the
current code base to my beta test server.

I currently have user createable/configurable competitions (no registration
rules or pricing details yet though).  I have rudimentary stats with a basic
registration process in place.

I have four items left on my immediate to-do list:
  Name conflict
  Login/auto-password
  Competition Ownership
  Refactor the admin section

The first two are probably what's holding up the intial beta roll-out.  The
third is needed soon, but the app could be played with by some people without
it.  The fourth is jsut for me as I don't like how that code is arranged right
now.

I'm running into some design issues with the first two however.  Historicially
I've already viewed three main use cases for registration:
a) first-time/infequent user -- I wanted the process to be easy and
straightforward.  I didn't want to require an account creation process before
registration, especially when it was per competition.  This is what the
existing sliding doors was an implementation of.
b) regular user, couple-based -- This was my envisioned "portal" based
registration system that would remember your recent partners/events and
streamline future registrations based on that.  Accounts are required here.
c) regular user, team/studio based -- This is what the Team admin section was
aiming to meet -- people who register a whole team repeatedily.  Accounts are
required here.

Now that all the competitions live in one database, instead of being broken out
part of the justication for a) is gone.  Plus the close-name match problem is
going to be greatly increased due to the larger database.  I'm thinking about
moving to an account required for use, and I'd like to know what you think
about that option?

My current though is that I'll keep the no-log in required path, and like the
current sliding doors, it will generate a password for further changes.  It
will, however also create a full user account with user name auto-generated as
well (something like firstname_lastname_digit), probably with an embedded
special character that will be illegal in regular usernames.  The first time a
user logs in with such a username, they'll be asked to change it and the
autogenerated password.  Does this sound reasonable to y'all?  Should this
happen with the "prime" registrant only, or with all the individuals created
during a registration process?

Other thoughts how how I should handle identity and accounts?

Thanks

eric

[CompInaBox-discuss] CIB mid-summer update...

[Eric D N. <nie...@MI...>]

So I've been pushing ahead with the Ruby on Rails rewrite/redesign of
CompInaBox.

I have rudimentary functionality for competition setup (levels, styles, events,
dates, contact personal, etc) and I'm working into the registration process. 
I've been getting a little bogged down with some of the issues involved with
merging the per-competition databases with the central database, but hope to
have that resolved soon.  (More details on the current issues below, near the
end.)

I am planning to extend CIB to NDCA competitions over the fall (once I get the
collegiate needs taken care of).  I have a committment for a Feb 2008
competition.

I'll be attending a Ruby On Rails training course next week, I hope that will
help me be even more productive.

Current design issues:
  1.  Because I've merged all the satellite DB's into the central DB under the
new design, a few of my "solutions" from before don't port very well.  I'm
currently fighting the most with couple management.
    A.  Instead of a couples (id, leader_id, follower_id, ...) table, I'm moving
towards a "registrant_entry" table (id) coupled with a
"registrant_entry_membership" (id, registrant_entry_id, person_id, role).  Thus
couples, team matches, formation teams, and solo exhibitions can all be
"registrant_entries" for use in the event_registration table.  This makes some
queries easier and some harder, but on the whole I like where its going.
    B.  However, at present there is NO non-surrogate key information in the
registrant_entry table (ie its only column is the PGSQL SERIAL/MYSQL
auto-generate) key.  This does make some of the logic needed to create a
couple/check for duplicates a little complicated, but it developing.
    C.  The problem, at this point a "registrant_entry" is NOT associated with a
competition.  In the past, even in the per-competition DB, this was true as well
-- a couple without events wasn't considered registered.  However, my currently
planned "single-user" UI (non-team/studio) has split the "add-partner" step
from the "add events to couple" step.  Thus "event-less" couples will need to
be listed as options for receiving events.  This list could start to get long,
in the collegiate world with lots of partner swapping.
       i) Option 1:  Add a "competition_registrant_entries" table to hold the
active, but possible non-registered couples for a given competition.  "New
partner" adds to this list for this competition, along with some sort of
"Previous partner" select box.
      ii) Option 2: Add a way to flag "retired_partnerships" have all
non-retired partnerships show as non-registered, but registerable couples.
     iii) Option 3: Some other idea....


Eric

[CompInaBox-discuss] Concerning a possible change to RoR instead of PHP....

[Eric D N. <nie...@MI...>]

While on a mini-vacation the past 5 days or so, I continued to play with Ruby on
Rails as a possible replacement for PHP in the web-application component of
CompInaBox version 2.

I am currently leaning strongly towards switch to RoR for the CIB rewrite.  My
RoR code base is already more evolved than the PHP rewrite; and I've started to
tackle harder problems and RoR isn't letting me down.

Here's the two frameworks I've been considering:

PHP-Based:
PHP5
simpletest
smarty
phpdocumentor
creole (maybe)
home-grown ORM

or Rails-based
Ruby (including the built-in RDoc and Unit tester)
Rails (includes ORM, templating, etc)

I'm also planning to switch to Subversion on SF.net instead of CVS very soon as
its much more in-line with agile development processes.

My current Rails version of CIB has the following: (+'d things are also in the
PHP rewrite at present, *'d things are "new" to CIB)
  User Login (simple no extra permission levels/ownership yet), +
  List of Competitions, +
  Details for a competition, +
  Create/edit/delete a competition with general information, *,+
  Add "extras" to a competition, like show tickets, *
  "Prime" registration
     with purchase options for extras, *
  Add fee levels, levels, styles to a competition via a web admin interface, *

I plan to continue working on the Rails version until this weekend at which
point I hope to check in either the RoR or the PHP version to subversion as the
official beginning of the new development effort.  If you have strong feelings
on either languange, please let me know.

Does anyone have any comments?

Eric

[CompInaBox-discuss] Investigating Ruby on Rails....

[Eric D N. <nie...@MI...>]

After about of month of progress on the rewrite of CIB, I'm taking about a week
to explore Ruby on Rails.  In three days, I've matched and passed the progress
from the php rewrite.

I'm beginning to feel I might switch languanges/frameworks for CIB version 2. 
If anyone has any experience with RoR and wants to help out, please let me know
or if you really think its a bad idea, please let me know too.  I should know by
mid next week which path I plan to pursue more.

Eric

[CompInaBox-discuss] Ajax and CIB...

[Eric D N. <nie...@MI...>]

As part of the rewrite of CIB, I'm also re-examining the role JavaScript/Ajax
could play in CIB.

In the past I've been rather opposed to spending time on JavaScript solutions --
partialyl because I almost always browse with JS turned off, partially because
I've never taken the time to learn JS, and partially because I want to code for
a wide lowest common denominator in the interface.

That said, I'm open to fooling around some with JS as time permits (not too
likely in the short-medium term, for me personally, but I beleive there is a
growing body of interested developers this summer).

Does anyone have any thoughts on where some Ajax based improvements could help
with the basic registration process, and still fallback gracefully?  Any
proposed solutions for dealing with the infamous collision pages?

I'd be willing to "require" JavaScript for the Team Administration and Comp
Administration pages, if the feature set is sufficiently useful.  I'm not
willing to require it for the SlidingDoor semi-authenticated interface.

Eric

[CompInaBox-discuss] Object/Relational Mapping layer under development....

[Eric D N. <nie...@MI...>]

Most of my efforts over the last week or so have been on creating a new
"Object/Relational Mapping" Layer.  If you're not familiar with this term it
refers to the code that handles "saving" regular Object-Oriented style objects
into a regular Relational Database system.  The two paradigms OO and RD are
designed for different uses and there's often a little bit of "juggling" to
accomplish to make a smooth transition, especially if both your Object Model
and your Data Model are non-trivial (and therefore likely very different from
each other).

I'm taking the approach of an "ignorant" but rich domain model and a "smart" ORM
layer.  Thus the Domain Model (classes like Competition, Event, Person, Couple,
etc) will loook like standard objects from an OO perspective.  They won't know
that there is a database behind them.  I'm endeavoring to make sure that
requirements from the ORM don't spill over into the Domain Model -- no
requirements for specific constructors, or specifically named getter/setters,
no requirements for a field to hold the database primary key, etc

The ORM layer will be slightly more complicated as a result, but 90% of that
complexity is already required in order to support the more flexible mapping
required before tacking on those requirements.  The ORM is modelled roughly
after Hibernate from the Java world; albeit greatly simplified at present and
with PHP-idioms applied as well.

Mapping files are currently in a "natural" languange syntax, not an XML format.
Mapping files are parsed when first needed by a script (they are not all loaded
on every request)
The ORM maintains an Identity Map that tracks primary keys to objects and vice
versa.  This Identity Map can be used to return previously retrieved objects
without hitting the DB a second time for the same object in one request. 
(Hibernate's first level cache, PHP's short lived scripts doesn't make
Hibernate's second level cache possible in any meaningful way).  The ORM also
saves a clone of the object to use for dirty field checking to avoid updating
un-needed fields (as the database is expected to have on update triggers
defined).

The ORM layer will be responsible for creating the connection(s) to the database
and restricting access to said connection to within the ORM module.

The ORM will support Lazy Loading of objects via creation of proxy classes at
run-time when needed.  (Ie when lazy loading is requested for a class, it first
checks for a Proxy version of that class, if not found, it checks for a file
containing a Proxy definition of the class with a timestamp after the last
modification of the real class, if not found it creates a file with a proxy
definition of the class and then loads it.  This proxy class acts exactly like
the real class, but won't access the database for its information until the
information is requested.)

For instance a Competition has a list of Events, each Event has a list of
Couples, each Couple has a list of Events, etc.

When a Competition Object is loaded, the EventList is initally proxied and not
transfered from the DB.  The Competition object is loaded on practically every
SlidingDoors page, but the actual events are seldom needed.  If a client of the
Competition object calls a method like ->getEventByName, or ->getEvents, then
the proxy gets loaded behind the scenes and the client "thinks" nothing unusal
happened and that the data was always there.

If anyone is interested in more details on the ORM layer, please let me know. 
If anyone is interested in a more "traditional" programming project (aka
non-web), this would be a great place to help out as its a more stand alone
component without some of the complicating web-concerns, but still complicated
in its own right.

Eric

[CompInaBox-discuss] CompInaBox -- Web rewrite update...

[Eric D N. <nie...@MI...>]

I've been making slow, but steady progress on my rewrite of the web components
of CIB.  I'm nearing the point of initial code check-in to the sf.net
repository for this code.  Once I have about 3 more web actions/views
established I should be able to post the code and invite others to help push
the development -- I want to at least show my envisioned way of handling the
common tasks associated with a web application -- list of foos, details on a
foo, updating a foo, and testing authorization.  Early/simple projects for
others can be porting/reimplementing the calendar system and the front page
announcements; slightly harder would be porting/reimplementing the result
tracker or SlidingDoors admin or stats pages.  Hardest would be assisting with
the reimplementation of SlidingDoors registration and Team Admin.

There has been some changes in the infrastructure requirements.  If you are
interesting in helping over the summer and beyond, here's the current list of
required, optional, and being explored dependencies:

Required:
  PHP5 (CIB was previously a PHP4 application)
     -- Reasons for change -- better object model and third-party dependencies
  PostGreSQL 8.1.x (CIB was previously based on the 7.4.x series)
     -- Reasons for change -- good time to update & savepoints are nice
  Smarty 2.6.13 (CIB previous used an inhouse code-generation/template system)
     -- Reasons for adoption -- its about time; its a good solution and helps
           maintain proper seperation of concerns

Optional (but highly recommended)  (both already in use)
  SimpleTest 1.0.1alpha3 -- Unit Testing framework
  PhpDocumentor 1.3.0rc6 -- Documentation Generator

Currently being explored, Currently looking favorable
  Creole (and Jargon) -- a PHP DB abstraction layer.  Unlike most other cross
database layers, this one seems to take a "greatest feature union" approach as
opposed to a "lowest common denominator"  It emulates where needed, but falls
back to native support where ever possible.  I've been working push SQL further
and further from the average coding tasks and I think that coupling my existing
PhraseBook class with Creole's prepared statement support will yield a very
type/quote-safe solution.  I'm not likely to change DB back-ends and I'm not
planning to comb over the schema looking to make it portable.

Currently being explored, neutal
  Phing -- a PHP build tool, similar to Ant, Propel (below) requires it; I want
to look to see if it (commandline) runs the Unit Test Suite more efficiently
than the normal web launcher, if it does, its likely to get upgarded to
favorable status.  It would also be useful for documentation updates, download
packaging, etc.

Currently being explored, looking unfavorable
  Propel -- a port of Java's Torque persistence engine (ORM).  This a
code-generation approach to ORM is is basically a Row Gateway/Table Gateway
hybrid solution.  The code generator creates base classes to act in Row/Table
Gateway forms for search, update, etc.  It takes the approach that objects will
have minimal logic (non-rich Domain Model) and it appears to practicalyl require
a 1:1 mapping of classes to database tables.  The latter is the primary reason
for my current unfavorable review of Propel.  It looks like a great product for
other uses, especially for simpler systems where the DB schema almost completely
determine the shape of the application.  (Single use databases).

I'm leaning towards a Data Mapper inspired solution (aka more like Java's
Hibernate than Torque).  I haven't seen any F/OSS PHP Hibernate inspired
solutions, so I'm coding one myself.  The solution I'm working on is different
from the CIB Version 1 system of StoredObjects (an Active Record style
solution).  The new domain knowledge will have no knowledge of the persistence
layer (so no more $db references being stored _everywhere_).  I'm aiming for
the persistence layer to be detachable from CIB for offering as a standalone
OSS project after it gets more fleshed out.  I plan to send more details about
this layer in a seperate email in the near future.

Eric

[CompInaBox-discuss] How about a single competition tool?

[Karri K. <ka...@si...>]

Hi to everybody in the group.

I have been educating scrutineers and competition directors if Finland 
for more than 10 years now and I am currently a bit tired of the 
problems caused by proprietary software. The rules keep changing and the 
original authors lose interest and refuse to let others have the sources 
for various reasons. So today I run lots of classes by hand or Excel sheets.

I would like to help in writing a totally free, open source 
scrutineering tool for the CIB. It should be able to handle result feeds 
to broadcasting systems and also be able to handle electronic judging. 
(I have already written some feasibility studies in using Java applets 
in WiFi capable PDA's and tablets. An example is available at 
http://sipo.fi/lomake.html )

The requirements we have in Finland are identical to the way IDSF 
calculates the results. But in addition we need to be able to handle 
Lindy Hop, Boogie Woogie and Rock'n'Roll.

I also have a need to feed more data into the database than is available 
to the general audience. For evaluating judge performances I am 
interested in the capability of judges to spot the semifinal and final 
couples from the preliminary rounds and I would also like to get some 
correlation value of the judges marks compared to the final result of 
the competition and perhaps also to the ranking list before the competition.

Another thing I have found very useful is to be able to dynamically 
choose the number of crosses for the next round. If you want to have 12 
couples for the semifinals and have a tie that requires 15 couples you 
could pass only 11 crosses to the calculation of the next stage and that 
may solve the tie.

This works only if the judges use points instead of crosses. But that is 
the case in all WRRC dance disciplines.

I would prefer an engine that would warn on errors in the judges marks 
but would not require the errors to be corrected. Sometimes I have 
judges who judge using the wrong techniques and it is impossible to get 
the info I want out of them in time. But their error does not perhaps 
have any effect on the result so I can do a final skating with a judge 
that has given two 3's etc. When TV is present and sending live you just 
make things work and sweep some minor problems under the carpet. The 
tool should be able to do this.

I am hoping to have something available by 2007.
Any comments or others with same kind of interests?

I am currently judging WRRC disciplines internationally using digital 
judging systems and also on paper. So I have some ideas of what works by 
now.
--
Regards,

Karri Kaksonen
ka...@si...

[CompInaBox-discuss] CompInaBox -- Version Two emerging details and questions...

[Eric D N. <nie...@MI...>]

So I've been rolling on the rewrite of the SlidingDoors module the past week or
so and I suspect its going to evolve into a complete rewrite of most of CIB
over the summer.

As mentioned before there are two main goals for this rewrite:
  1.  Streamline the registration process/remove navigation limitations
  2.  Fold the per-competition databases back into the central DB

Architecture
  I'm looking at a rather sophisticated underlying architecture compared to the
old CIB.  The old CIB is probably best classified as a Page Controller with a
relatively poor (as in non-rich) Domain Model with builtin DAO.  The new system
is moving to a Front Controller based system, a richer Domain Model and
seperated data mappers.  Many of these changes are partially driven by
testability concerns and os far the new system appears to be shaping up in a
good way.  I've almost finished the first page view -- having built most of the
infrastructure, including some of the generic error handlers (database down,
invalid competition, invalid command, etc).  I don't havge a good handle on the
View component yet, but it will be some form of Template View.  Unsure of how
chrome/theming will be handled .

The Front Controller itself is slightly more complex than the normal Front
Controller, but less so than my version last summer when I had it fallback to
the old style Page Controllers if no "Module Controller" claimed the request. 
(Last year was an incremental plan, this year is a ground-up plan).

Since PHP is loaded anew on every invocation, I didn't want to a huge mapping
file like the Java world would tend to use.  Thus the top level Front
Controller maps the request against a series of regexps to find which "Module"
to invoke --  SlidingDoors, SlidingDoorsAdmin, Results, Calendar, TeamAdmin,
etc.  When the Module is selected the associated Request and Context helper
objects are "upgraded" to hold Module specific information as needed (database
references, phrasebooks, etc).  The Module Controller then basically repeats
the process to select either a Command or an Application Controller.  Commands
handle and updates to the underlying system and retrieval of information from
the DB into the Context for use by the selected view.  Application Controllers
are used when there is a "wizard" type series of pages (such as registration,
result importing, or check entering) with possibly complex state changes.  It
is here that I hope to allow the more flexible navigation within the
registration process.

Development plan --
  I'm starting with the URL /register/[index[.php]/] its a non-existing page on
the current CIB.  But it will be a simple list of open competitions with some
supporting data.  Something along the lines of
http://www.ballroomregistrar.com/comp_summary.php?type=OPEN

As its a simple page with no "actions" associated with it, only retrieiving a
list from the DB.  This is almost complete (without chrome).

  Next will be navigating from this index page to a competition registration
home page.  Ie something like
http://www.ballroomregistrar.com/register/MIT06/
However the information content will be restructed to something like
http://www.mit.edu/~nielsene/CIB/comp_index_v2.html
designed to handle an arbitrary number of deadlines, arbitrary number of contact
names/emails, etc.  As well as being less wordy.

  Step 3 will be the admin page for the comp home page -- ie the plan rewrite is
including the folding in of PrepStep into SlidingDoors at every step along the
way.  This first admin page will allow: Editting the Competition Name, Dates,
deadlines, and contact information and, of course, requires authentication. 
Once complete it will be hooked up to an option from the list page (and other
places as appropriate) for creating a new competition.

 Step four will be either more comp setup or straight into the comp registration
 process depending on timing issues.

OK, if you've read this far, thank you! :)  Now for the questions that are
emerging --
  I hope to merge the per-competition databases into the central database.  This
should make no difference to end-users, but will make setting up a competition
much easier.  It might have some preformence implications, but I can deal with
those in a variety of ways, should it become an issue.  However it does
generate two issues:
  1)  Close name matching -- the library of names will be much larger as instead
of matching against just one competition it will match against all people.  This
is probably a good thing, assuming I handle it right (big assumption).  I'm
still NOT assuming/enforcing user-accounts to register and thus non-users will
get auto-generated passwords for each competition.  (Required if some schools
use different bulk registrars, etc).  Can anyone think of other issues here?

  2) "Unixname" all competitions currently have a "unixname" this is the
competition name that appears in the URL for register/* and stats/*.  The
Unixname is currently the primary key in the comps table.  However, this is now
exposed in three places:  results importing, beta PrepStep, and the Calendar. 
Most end-users entering data in the calendar or in PrepStep would have no clue
as to why/what they should enter for this for their event.  Thus I think I will
be demoting the unixname from the primary key to a candidate key.  (The calendar
app didn't need a unixname at all in the first place. neither did the
result_tracker.... only hosted competitions really "needed" it as it was the
name of the per-comp databases and part of the abosolute path to the scripts --
as the new system doesn't need either at a physical level I could get rid of it
completely.
   However, I still need something to use in links.  I can pick the "comp
abbreviation" during result importation, I could assign one when approving
non-hosted calendar entries, I could assign one when approving a configured
competition prior to opening registration, etc and thus not really change the
existing system/URLs.
   I could change to using a number (ie register/12/); I personally hate the way
that looks and how it doesn't help the user know which competition a link may
bring them to, but its an option.  I could change to using the full competition
name, URL-encoded, but that's likely to be messy, long, and annoying as heck.
   Any other thoughts?

Thanks

Eric

[CompInaBox-discuss] Comp Registration home page requirements....

[Eric D N. <nie...@MI...>]

As a first part of the rewrite, I'm tackling the front page of a competition --
for instance:
http://www.ballroomregistrar.com/register/MIT06/

Without addressing the layout or verbiage, what information do you see as
required/superfluous/missing?

Two areas with the template hasn't often met the needs of some competitions:
  -- Hard-coded two sets of names (Title, Name, Email)
  -- Two registration deadlines

Some competitions have Co-Coordinator(s), some don't have seperate
Coordinator/Registrars, etc.  If the competition doesn't set-up their own
internal mailing list aliases for the multiple coordinators, I can't easily
accomodate their needs.  Some competitions have early, regular, and late
registration deadlines.

Information that I think is important to show on the registration page, please
let me know if you think any is superfluous
 -- Name of the competition
 -- Website for more information
 -- Official contact address(es) (arbitrary number and titles)
 -- Date of event and deadlines

I think I can remove the Venue adress.  I think I can remove the top navbar.  I
plan to merge the "Browse Current Registration" and the summary table.

I suspect that the contents of this page will be placed into the same template
as the main ballroomregistrar site, so the bottom matter will be
removed/handled by the column'd template.

Eric

[CompInaBox-discuss] I'm starting on the SlidingDoors re-implementation...

[Eric D N. <nie...@MI...>]

Like last "summer" I'm starting off with an ambitious plan, if I make decent
progress by June, I'll continue with the plan, otherwise I'll fallback to a
more conservative approach.

The plan --
  rewrite all of SlidingDoors -- registration, stats, and comp admin
  eliminate the per competition databases (merge content into the central DB)
  build a comprehensive test suite
  migrate to a better MVC architecture

I've been wanting to eliminate the per-competition databases for a long time;
however that requires touching a lot of the files.  Therefore a rewrite is the
right time to do it.  If I'm starting from "scratch" its easier to ensure that
the proper test cases are involved.

I plan to lift as much code as I can from the old CIB and my work last summer on
migrating to the new MVC architecture.  I haven't figured out how to combine the
goals of code-reuse and comprehensive test cases.

I hope to proceed using test driven development, for both source changes and DB
schema changes.

If anyone is interested in helping, as always, please let me know.  A division
of labor with someone helping with either the admin or stats while I tackle the
registration, or vice versa, etc would be very helpful.

Eric

[CompInaBox-discuss] MC's Control Station---

[Eric D. N. <nie...@MI...>]

During some debreifing with various people after the Harvard  
Competition, the concept of the MC's control station application came  
up again.

If there is anyone interested in working on a stand-alone CIB  
application, here's an interesting project:

This is a day of application for the MC/MC assistant to help keep  
track of upcoming events, judge panel changes, etc.

Ideally the MC station should have color coding for:
1) Which events have been scrutineered and are ready for callbacks
2) Which events are being scrutineered actively
3) Which events have run, but are in the queue
4) Which events have yet to start within these session
5) Some special indication for when extra rounds of an event is  
needed due to odd callbacks

It would also be nice to show how long the various judges have been  
judging (assuming the collegiate model of rotating panels within the  
shift, versus the NDCA version of 1.5-2 hours panels)

It would even be possible to link it to a music library/schedule to  
eliminate the need for a specific DJ.  (Not recommended for large  
competitions, but for smaller comps, or mock comps within a team it  
could be very useful).

If it knew the expected scheudule and could show the deltas it would  
make know if you/re ahead/behind easier.  If it captured the data on  
when the rounds ran it could even forecast and capture the amortized  
timelengths for better estimates for the next year, etc.

The application itself is rather simple, I think, crafting a useful  
communication link between the station and the various information  
sources and sinks is the tough part (ie it should be able to  
automatically accept data from Chester, CompMngr, S3 for  
scrutineering and should be able to power various projectors with pre- 
canned possible display choices   (upcoming schedules, current event,  
callbacks).  Perhaps also provide a way for the deck captain to help  
annotate no-shows/scratches for the initial heat distriburtion, etc

I 'm not likely to get a chance to work on this myself, though I can  
help specifically with parsing Chester data.  And I'm happy to help  
brainstorm, explain the concept more.  Anyone interested in running  
with this idea?

Eric

[CompInaBox-discuss] Touching base regarding CiB Development

[Eric D. N. <nie...@MI...>]

Greeting everyone,

My work on the scheduleing compoenent "FloorCraft" came to somethin  
of a halt as
the busy spring season started -- where it feels like I'm opening 2  
competitions a week.
There are currently 7 open competitions with three more in the  
configuration process right
now.

We are about 2 months from the end of spring competitions and the  
start of my major
development effort.  Current plans are a MAJOR rework of the basic  
registration process,
aka SlidingDoors.  Its probably going to require complete re-writes  
of some of the
code, while other parts can be salvaged (I think the stats and admin  
areas are "safe")

I'ld like to get a feel for which, if any, of you think you're going  
to have time to help
with development this summer.  We're going to need to do some  
brainstorming over
the next few months to get ready.

Thanks,
Eric

[CompInaBox-discuss] FloorCraft 0.1.2 released and bundled...

[Eric D N. <nie...@MI...>]

I released FloorCraft 0.1.2 last night.

Changelog:
- Added Ability to reorder sessions via a move up/down interface
- Improved the jar file to be double clickable on machines with Java 5.0 VM's as
default
- Fixed an event deletion bug
- Fixed a few loss of selection bugs

If you have played with FloorCraft, please let me know your feedback.  I'm
hoping to move out of "Pre-Alpha" and into "Alpha" status in another few
releases.  Following is my planned roadmap:

Version 0.1.3: (Funtionality)
-- set an actual (clock) time for the start of the day (done in CVS)
-- change the estimated size of an event.
-- all open bugs at bundling time

Version 0.1.4: (Interface Rafactoring)
Here's my list of minimal required UI improvements:
-- Collapse the double lists (Session and Event) to a tree view

Version 0.1.5: (Respond to some keyboard events)
-- Map the Menu "Deletes" to "del"/"backspace" key presses in the
tree view

Version 0.1.6: (Context Menus)
-- Context menus in the tree view for rename, change event size
-- Possible removal of said actions from main menu

Version 0.2.0 Alpha:
-- Fix some of the sizing and labeling issues of components.

Would you think at that point I can start asking some of my more
techno-friendly comp-organizers to play with it?

Things that I know I need soon, but maybe not before I let some
organizers play with it:
-- Style/dance filtering, suggested by Tuan (Ie in the Event creator dialog,
when you select Smooth, then non-smooth dances should disappear and the
remaining dances should be ordered in normal smooth dance order)

-- Expose selected "constants" for tweaking -- especially heat size, and awards
time (offer radio box selection for "Numbers only", "Numbers and Names",
"Number, Names, and Affiliations" with appropriate mappings into times)

-- Possibly convert the model dialog for Event Creation to modelless
for easier entry of multiple events -- need to make sure that a good feedback
channel is retained for indicating that the event has been added, so people
don't add like 50 copies of the same event...

-- Printing the schedule.

-- Event ordering -- currently it organizes by rounds, but within the rounds the
events are in arbitrary (normally insertion) order.  It doesn't know anything
about the ordering of levels or dances yet.

Eric

[CompInaBox-discuss] FloorCraft v0.1.0 released at sf.net

[Eric D. N. <nie...@MI...>]

I've added a jar file to the File Release System at SourceForge:
http://sourceforge.net/project/showfiles.php? 
group_id=40795&package_id=176902

You'll need a Java 1.5 VM to run it and it requires a commandline like:
java -cp FloorCraftApplication.jar  
net.sf.compinabox.floorcraft.FloorCraftApplication

The paired tarball has the snapshot state of the sources at the time  
the jar was made.

This is still a very minimal application, not functional for its  
domain yet.  However the "bones" are there and hopefully it will  
reach a useful level of functionality soon; and thereafter a useable  
level.
My two main outstanding tasks to reach the minimal useful  
functionality are: interleaving rounds and chaining durations to a  
start time to generate an actual schedule.

Eric

[CompInaBox-discuss] Initial development version of FloorCraft check-in to CVS at sf.net

[Eric D. N. <nie...@MI...>]

I just checked in the initial developer version of FloorCraft to CVS  
at sf.net under the CompInaBox project, using the module name of  
FloorCraft.

The UI is barely useable and is still missing many required  
operations as well as needing massive layout help.  I'll look into  
creating a downloadable executable in the near future.  I think it  
should be easy, but I'm not sure.

Currently it knows about "Sessions","Events", and "Rounds".  It can  
calculate the minimum time required for each event to run in  
isolation. My next step is to add on a bottom panel that shows the  
interleaved schedule of rounds inside the session and can thus  
calculate the total time required for the session.  The initial  
scheduler will NOT enforce a set time distance between consecutative  
rounds of the same event, nor attempt to estimate scrutineering  
requirements; it will merely interleave backwards in level order from  
finals to first rounds as needed.  Thus the session time will be the  
same as the total of the contained events.  Following that addition,  
the UI can start to be cleaned up as the main elements will be present.

The following iterations will likely focus on filling out the range  
of operations exposed to the user (such as the currently missing edit/ 
remove event ... ).

At some point the hard coded constants for heat size/times, etc will  
need to be exposed to be customizable as well as more intelligent  
scheduler's adder.

It currently has a rather thorough unit test suite -- the only  
component to be knowledge that is insufficiently tested for the  
current functionality is the CustomEventListRenderer as I wasn't sure  
how to dig into that.  The unit tests require the following  
components that are not distributed with FloorCraft : JUnit, Jemmy  
(from NetBeans), gsbase (from sf.net) and EasyMock 2.0 (sf.net).  I  
am hoping to be approved for a free licensee of Clover to use on this  
project to help report on the test coverage.

Eric

[CompInaBox-discuss] Initial development release of "FloorCraft"

[Eric D N. <nie...@MI...>]

Over the past two weekends I've been working on the off-line scheduling
component of CIB, "FloorCraft".  I have two more feature sets to implement
before it can do "anything", which point it'll be committed as a new module in
the CIB sf.net CVS repository; I hope that will be sometime this week.

I'd greatly appreciate code review at that time (if you want to see the current
non-useful code, please let me know).

FloorCraft is designed to be the useful for event organizers in both the
pre-planning and the week-of planning stage.  In Pre-planning I'm hoping that
it can be used to do lots of "what-ifs" of different event offerings, session
layout, etc.  In the week-of planning its main goal is reconciling event size
estimates with actual registration figures and producing the round-by-round
schedule.

Currently, the application:
  Allows you to Add Sessions
  Allows you to Add Events to a Session
  Allows you to Save

The two missing feature sets for what I'm considering the initial developer
releases are:
  Load
  Hard-coded timing calculation (ie no user customization of heat sizes, music
length, etc at this time)

Of course, stuff like rename and delete sessions is needed soon; as well as
edit/delete events, etc.  The initial developer release is not meant as a
useable tool yet.

Its written in Java; it has full JUnit tests and uses EasyMock and Jemmy for
testing the graphical elements.  I'm using Eclipse and haven't setup an Ant
build yet and am rather clueless about a lot of thing like that.  I suspect my
current MVC implementation is slightly off.

Just a heads up about what's coming soon.

Eric

[CompInaBox-discuss] Comp Admin Area thoughts....

[Eric D N. <nie...@MI...>]

Here's the briefly mentioned followup to the previous email, detailing the
problems with the per-competition admin area.

The competition admin area currently offers a variety of services:

At a glance reports on:
  Payment status of individuals
  Payment status of teams
  Confirming the accounting of checks
  Any refunds required
  Fees received, waived, total income from registration, total outstanding

Payment tracking:
  Entering payment waivers
  Entering registration fees paid by checkes (PayPal payments are auto-entered)

Registration Management:
  New Registration
  Search & Edit existing registrations
  Explicitly opening or closeing registration

Announcements:
  Message of the Days
  Mass email to competitors or people registered with TBAs

Exporting:
  Assigning numbers
  Generated Printed Program excerpts
  Exporting to scrutineering tools (only S3 supported via the web at present)

Several other desireable reports and features have been indentified, but given
the current development pace, I'ld like to focus on organizing what we have,
not what we might have.

The page layout is poor ATM; I'll try to get a screenshot up somewhere for
developers without admin access to a competition to see.  But the rough outline
is that all of these features typically have their own sub-page, but are
directly reachable from the admin index.  I think we'll need to introduce some
mid level pages to control the fan-out at a given level.

Access to the admin pages are limited to users with cib_central accounts and who
have been explictily granted some level of access to the named competition. 
There are four access levels at present -- Staff | (Registrar | Comptroller) |
Coordinator.  In order of increasing access permissions.  I'm considering
adding a "Scrutineer" level as well -- this would be roughly below Staff in the
hierachy and would only have access to the Export Data to Scrutineering Tools
features -- payment information and total must be masked.

The largest problem is that at present the main page is VERY slow to load due to
the inclusion of the registration totals -- these used to be fast to calculate
before the addition of the multiple registration deadlines and audit tables. 
Now they are quite slow and can become extremely frustrating for administrators
of large competitions.  The simple solution is to move the payment information
off the main admin page, along with the reports, etc leading to a simpler
layout and a more unified funcation area that can be easily hidden from
non-appropriate people.

The second biggest problem is that the admin registration features -- new
registration and registration editting currently simply feed into the regular
process.  This means that
1) the admin can not override the registration rules even if s/he wants to
2) the admin sometimes "loses" their login and can't use use "back" to return to
the admin area.
3) there isn't anyway to do a lot of the common cleanup tasks (like merging
duplicates, or identifying/removing ghosts)
These problems are primarily bug-fixes or new features and wouldn't be addressed
by a simple reorganization, but are worth keeping in mind at this point.

Eric

[CompInaBox-discuss] Fall semester update on CIB...

[Eric D N. <nie...@MI...>]

Its been a busy semester for CompInaBox hosting; while development has gone in
short bursts.

Ily from the Georgetown University ballroom team has come on board as a
developer and has already made several extremely useful contributions in
multiple areans: packaging/documentation, S3 scrutineering export support, and
making good suggestions for improving the comp admin areas.  I look forward to
his continued involvement.

I was making a lot of progress at the beginning of the semster with a new
infrastructure/code architecture that would migrate the SlidingDoors to a Front
Controller/MVC architecture.  The current system is more of a Page
Controller/Transaction Script model that's been verging on dissolving into
spaghetti code as more and more options have been added for different
competitions.  I've had to put this work on hold for the regular competition
support.  If there is interest, I'll branch the code and commit the work in
progress for others to review and/or help -- its currently non-working.  If you
want to hear more about it, please follow up with an email to the list.

The result tracker seems to be very popular; in terms of page views it catching
up with the individual competition's registration pages.  I've loaded just
about a full year worth of new england college competition data and hope to
work backwards as time permits.  I should be able to reach back to about 2002
with at least some of the competitions.  There are a few issues, like Novice is
completely ignored, but its not a huge deal.

The new password system for the regular SlidingDoors accounts is in operation
and generally has been behaving -- two large bugs that had been catching a lot
of people were recently fixed after an outstanding bug report from the Caltech
competition organizers.   One was the dreaded "intrusion attempt detected" --
this was caused by a recently added table that lacked a primary key
specification; I'm not sure how I left it off, but....  The other was one cause
of the "Should Never Happen" bug -- this was a timing-bug where a rapid
insert-delete pair confused the audit tables and rejected the update, however
the second half of the update succeeded.  I've added a forced delay into the
system but I'll need to investigate whether I need a different foreign key
action or a full transaction warpper to fix it properly.

The team admin features for bulk registration aren't getting strong use.  They
are missing two required features and have one layout bug that needs fixing
before I push them harder on the teams.  The missing features are a cron based
process for pulling "regular" registrations into the team system and
enforcement of the competition registration rules (enforced in SlidingDoors,
currently bypassed in bulk registration).  The layout bug in MSIE causes a huge
empty space in the screen, I think do to different CSS handing of nested
"clear"s.

Finally, the extensive use of the comp admin areas by the DCDI organizers has
identified a strong need for a complete reorganization of the admin section,
including moving some of the calcuation into the database.  This work is yet to
start, but hopefully will have some detailed discussion soon.

Eric

Re: [CompInaBox-discuss] Interesting new twist to CIB....

[Eric D. N. <nie...@MI...>]

Some more information:  The main cause of the overusage was
a runaway process that was causing the stats rebuild to not set its  
"updated"
flag; therefore it thought that the stats were always stale.

However there seems to be some strong candidate queries for clean up.

The queries for calculating how much a given person owes to the  
competition are "wordy"
and muttiple.  Furthermore they can not at present be collected into  
a single meta query to
aggregate them.  Thus there is an explosion of N+1 style queries to  
generate team
invoices or master lists for the competition.  This happens on every  
stats rebuild, and on many
admin page views so its a rather common and "expensive" web-server to  
database server
query.

I think the way ahead is to move the code for calculating
   a) deadline met
   b) registration fee total
   c) person paid
   d) person waived
should be moved out of CompDB.inc and into a
stroed procedure in the Database.

This will have two benefits
1) reduction of inter-machine traffic
2) easier aggregation of monetary totals

It will probably still have roughly the same number of queries, but most
wont have to travel across the wire and the "API" will look cleaner.

Not sure when I'll get to it, but just wanted to get the idea into  
the archives.

Eric




On Oct 27, 2005, at 11:23 AM, Eric D Nielsen wrote:

> The five open competitions (with four have near simultaneous  
> deadlines) finally
> caused me to go over my bandwidth quotas.  Nothing too bad and I  
> don't expect
> similar concentrated surges to occur too often so I'm not worried.   
> However it
> was very enlightening to look into the bandwidth distribution.
>
> Basically something like 90% of the bandwidth is between the  
> database server and
> the web server; web/email traffic is a small percentage.
>
> As an immediate stop-gap measure to gain some protection from  
> further overages
> this month I've throttled back the stats rebuild to only check for  
> changes
> every three minutes instead of every minute.
>
> However I don't know at this time what time of use cases contribute  
> to the
> intra-server bandwidth:
>
> Comp/Team Admin operations tend to be rather "heavy" but are less  
> common and
> accomplish more per page.
>
> Stats Rebuild are extremely data intensive and are load dependent  
> in frequency
>
> Regular SD pages are rather light, but very frequent
>
> Result Tracker is moderate, but not in heavy use yet.
>
> Does anyone have any thoughts on how I can attempt to better  
> measure/quantify
> the bandwidth breakdown to figure out where we should try to  
> optimize, if
> anywhere?
>
> Eric
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> CompInaBox-discuss mailing list
> Com...@li...
> https://lists.sourceforge.net/lists/listinfo/compinabox-discuss
>

[CompInaBox-discuss] Interesting new twist to CIB....

[Eric D N. <nie...@MI...>]

The five open competitions (with four have near simultaneous deadlines) finally
caused me to go over my bandwidth quotas.  Nothing too bad and I don't expect
similar concentrated surges to occur too often so I'm not worried.  However it
was very enlightening to look into the bandwidth distribution.

Basically something like 90% of the bandwidth is between the database server and
the web server; web/email traffic is a small percentage.

As an immediate stop-gap measure to gain some protection from further overages
this month I've throttled back the stats rebuild to only check for changes
every three minutes instead of every minute.

However I don't know at this time what time of use cases contribute to the
intra-server bandwidth:

Comp/Team Admin operations tend to be rather "heavy" but are less common and
accomplish more per page.

Stats Rebuild are extremely data intensive and are load dependent in frequency

Regular SD pages are rather light, but very frequent

Result Tracker is moderate, but not in heavy use yet.

Does anyone have any thoughts on how I can attempt to better measure/quantify
the bandwidth breakdown to figure out where we should try to optimize, if
anywhere?

Eric