Re: Tabbie 2.0
Klaas van Schelven
On 10/11/07, Klaas van Schelven <kl...@vanschelven.com> wrote:
> Hi Deepak,
>
> I've been triggered by Meir to think about a next step in Tabbie. Quite
> honestly, I was just about bored with Tabbie.... however, I'd reconsider a
> restart (in a new project) under a number of conditions (I would do some
> maintenence on 1.3, and help the Bangkok guys out, but that's it).
>
Well, I understand. Have been through the boredom phase myself with
many projects. All I can say is thanks for resurrecting something that
was quite close to dead anyway :). Tabbie in its current form is still
very usable for a long time.
I agree... which is the reason I have quite a list of wishes that needs to be satisfied before I start on another path.
> A team of at least 3, preferably 5 *active* developers. - preferably
> including the hotshots of Tabbie's current competitors.
>
> Desktop AND Web app. Desktop App - should be one-click install for desktop.
> BP, American Style (Holland too) and Australian (and Asian) style. Possibly
> more.
> Highly pluggable draw algorithms and adjudicator allocation. Included Draws
> should be WUDC, met-before-avoid and a same-uni-avoid at least.
> Technically combining the best of all current apps.
>
> Idea would be to push Tabbie as *the* Tab softwre worldwide, and to have
> some serious joint fun with an enthousiastic team.
>
> Would you be in? Do you know other who would be willing to join the team as
> well?
I would definitely like to contribute. I am an outsider to the
debating community :), so I do not really know anyone who actively
debates/used to debate. I will contact some people in the NTU debating
squad and see if anyone there wants to join the efforts.
That would be great. Meir has said he wants to do some work, but has limited time. I'm still chasing Aaron Craigie and the guys from the Tournaman team. Also - it would be really cool to get some Australians and Americans on the team. I'm thinking about sending a mail out, but maybe we should start with a smaller team instead, and make something that's cool and extendable enough for everyone to join in.
Interesting thought about a Desktop App and Web App. I agree that it
will be good to have. I have a few points to make :
* We should keep a client-server model. The server does all the
storage/calculation of draw/ adjudication allocation and uses a
lightweight XML/REST api of some sort to communicate with the client.
This has two advantages:
1. We can build consensus on the platform for reference implementation
for the server. But since it is exposing a web based API there is
flexibility in the future to switch platforms/technologies if needed.
2. The client can be a desktop and/or a web app, and as long as
another implementor can implement a interface to the server side API,
he can use any platform or technology he likes.
Excellent ideas. I had been thinking in the same direction.
XML/REST: please something which uses normal POST or GET for the requests and returns more complicated stuff as XML(or json or css)
Can you tell me a bit more on Ruby? How easy is it to roll out and .exe that includes both client and server and runs on windows easily? Or should we get different technology to make a windows app (Delphi or something)? I just found one "py2exe" for Python, but have no experience with it.
What are your thoughts about technology in general? I'm a python fan - specifically for creating the server code. I haven't programmed desktop GUI's in years, but if we have a deployable server that's not much of a concern to me. Ideas here? I know Craigie was thinking about a RoR too.
SQL SCHEMA
============
I am attaching a SQL schema that I was using with my RoR app. I have
normalized the schema used in Tabbie, and basically got rid of
temporary tables.
The tables are
* universities
* venues
* adjudicators : Belongs to university
* teams : Belongs to university
* speakers : Belongs to team
* draws: contains a status field which can be 'draft', 'final' and
'closed' (after results are entered).
* debates : Belongs to draw and venue. Contains fields og,oo,cg and co
to contain the teams for that debate
* adjudicator_debates : Adjudicators officating in a debate including
a 'type' field to indicate 'Chair', 'Trainee' or 'Panelist'.
* motions
* scores: belongs to debate and speaker. Captures the score in the
most basic form (speaker scores). All the rest of the logic is
implemented at the application level.
There might be a case to break normalisation and include redundant
info about team scores in a separate table.. but I have not reached
that point in my implementaion yet :).
Looks good, but I would like to go more radical even (thinking esp. about different forms of debate too):
* get rid of the name "university" and replace it by some more general organisation (could be school, company, whatever)
* the only reason adjudicators belong to uni's is because of the conflicts. So, let's take that link out of the adjudicator table and into two special conflict tables (for team and institute)
* while writing this, I'm wondering if we really need both teams and institutes, but maybe I'm taking it too far.
* I think with positions, we should have a special position table (with long and short representation) and a debate table like so:
id position team
1 1 (og) 32
1 2 21
* On the other hand, I do think taking down the team_scores into the tables is worthwhile, because it could simplify the app layer a lot. However, I would choose the acquired number of points (0, 1, 2, 3) instead of separate columns for first, second etc.
* We also need a very clear terminology. Specifically, I keep confusing myself over "position" "score" and "points". How about (Role, team_points and speaker_points)?
* also, I was thinking of taking properties like ESL, "Novice" etc. out into a separate table, so those become a lot more customizable. We also need to think hard if you want those properties on teams or speakers.
* I like your setup for the draw table a lot.... I am wondering about the use of the debate table though. isn't a table like so sufficient:
draw team_id position_id venue_id
4 45 2 (oo) 892
* I also don't see the difference between "finalized" and "complete" draws
Let me know what you think
Deepak
Can you put the RoR code online (google please, SF sucks) and give me an account?
Also, maybe we should start thinking about the REST/XML interface.
Your turn....
Klaas
Meir Maor
On 10/14/07, Klaas van Schelven <klaasvan...@gmail.com> wrote:
> * I like your setup for the draw table a lot.... I am wondering about the
> use of the debate table though. isn't a table like so sufficient:
> draw team_id position_id venue_id
> 4 45 2 (oo) 892
This does not seem normalized as each draw/debateId has exactly one venue_id.
In gnetab we do not have the concept of debateId
and we use:
CREATE TABLE team_allocation (
round integer NOT NULL,
team integer NOT NULL,
room integer NOT NULL,
"position" character(2) NOT NULL
);
However it may be prefable to use a debateId and have
table debates:
deabteId(auto increment), round,venue
and table team_allocation:
debateId,team,position
in gentab we don't have a status in the allocation table, instead we
use a rounds table
which has a status column:
CREATE TABLE rounds (
round integer NOT NULL,
status integer NOT NULL,
round_type integer NOT NULL
);
We use round status to know if debators/adjudicator have been allocated
if the round has started, if all results have been entered etc.
We can support pairing the next round before all results from the
previous rounds are in,
this is usefull if you want to use speed ballots(no personnal score), or In
smll tournamnets(3 rounds brake to finals) sometimes one does not want
power pair at all
and a draw for all rounds may be computed in advance.
round_type column specifies what drawing algorighm one should use:
power pairing(may want to put several variants),fold or anything else, even
quarter/semi finals etc.
gentab is designed to support internationalization using a message table:
CREATE TABLE messages (
message character varying NOT NULL,
"language" character varying NOT NULL,
string text NOT NULL
);
message&language being the key, and text is what should be displayed.
In order to make entering results simpler and less error prone,
gentab produces adjudicator forms automaticlly, each form has a serial number
so when you get an unordered pile of forms to enter one may type in the
serial number on the top of the page and get an electronic form in the
same layout
as the page he or she is holding. We found this convinient.
I disaprove of breaking normalization in order to simplfy app-layer,
instead I recommend setting up views in the database, and keep al complex
queries in the database and not in the application level.
In gentab we use a system of tables where we have
personn,judge, and debator
when each judge/debator is also a person(hopefully:)). This complicated matters
and I am nor sure it is worth it, but it allows for simplified swinger
allocations.
In gentab a person can be a debator only, an adjudicator only,
a swing debator which may be allocated as an adjudicator as necessary or
an adjudicator whihc may be allocated as swing debator as necessary.
aside from the basic properties for each person we also have a
general person properties table:
CREATE TABLE person_properties (
person integer NOT NULL,
"key" character varying NOT NULL,
value character varying
);
this can be used for anything, such as payment status, crash location or
anything turnamnet related. I believe ESL status is a common enough
feature to merit
its own column in the person/debator table and not be placed in a
generic properties table.
I recommend looking at the databse structure as found in:
http://gentab.cvs.sourceforge.net/gentab/
Me.
Klaas van Schelven
In gnetab we do not have the concept of debateId
and we use:
CREATE TABLE team_allocation (
round integer NOT NULL,
team integer NOT NULL,
room integer NOT NULL,
"position" character(2) NOT NULL
);
This is what I meant
in gentab we don't have a status in the allocation table, instead we
use a rounds table
which has a status column:
CREATE TABLE rounds (
round integer NOT NULL,
status integer NOT NULL,
round_type integer NOT NULL
);
This is how I read Deepak's remarks.
We use round status to know if debators/adjudicator have been allocated
if the round has started, if all results have been entered etc.
We can support pairing the next round before all results from the
previous rounds are in,
this is usefull if you want to use speed ballots(no personnal score), or In
smll tournamnets(3 rounds brake to finals) sometimes one does not want
power pair at all
and a draw for all rounds may be computed in advance.
2 good ideas here... though you lose the extra check on adding up speaker scores if you put out speedsheets without speaks.
round_type column specifies what drawing algorighm one should use:
power pairing(may want to put several variants),fold or anything else, even
quarter/semi finals etc.
gentab is designed to support internationalization using a message table:
CREATE TABLE messages (
message character varying NOT NULL,
"language" character varying NOT NULL,
string text NOT NULL
);
message&language being the key, and text is what should be displayed.
In order to make entering results simpler and less error prone,
gentab produces adjudicator forms automaticlly, each form has a serial number
so when you get an unordered pile of forms to enter one may type in the
serial number on the top of the page and get an electronic form in the
same layout
as the page he or she is holding. We found this convinient.
This is a good idea - though you could simply use the Venu Id for this.
I disaprove of breaking normalization in order to simplfy app-layer,
instead I recommend setting up views in the database, and keep al complex
queries in the database and not in the application level.
fair enough.
In gentab we use a system of tables where we have
personn,judge, and debator
when each judge/debator is also a person(hopefully:)). This complicated matters
and I am nor sure it is worth it, but it allows for simplified swinger
allocations.
I was thinking about this too.... not sure if it's worth it, but my experience with running a tournament says that Swinger Allocation is actually one of the few manual nasty jobs, so it would be great to take that out as well...
aside from the basic properties for each person we also have a
general person properties table:
CREATE TABLE person_properties (
person integer NOT NULL,
"key" character varying NOT NULL,
value character varying
);
this can be used for anything, such as payment status, crash location or
anything turnamnet related. I believe ESL status is a common enough
feature to merit
its own column in the person/debator table and not be placed in a
generic properties table.
I recommend looking at the databse structure as found in:
http://gentab.cvs.sourceforge.net/gentab/
Ok guys,
I think we have enough ideas on this to move forward.
Next question for me would be: which technology to use.
The fact that we still have only two people really committed is a showstopper for me though - so I'll just park it until we get a third one on board.
Klaas
Me.