Datum: 11.Januar.2005 Anwesend: Gunnar, Marcel, Martin, von jeder Gruppe mindestens 2. (weiter unten nach dem Protokoll noch die Sondermeldung in Bezug auf den Status/Plan) -------------------------------------------------------------------------------- Moin, hier die Punkte die mir im Ged"achtnis blieben. 1) Status/Zeitplan (und ``sollen/duergen wir in der Vorlesungsfreien Zeit arbeiten?'') Momentan sind die einzelnen Gruppen in Bezug auf Status und Zeitplan noch nicht richtig Aussagef"ahig, da manche Teilnehmer w"ahrend der Ferien gearbeitet haben und demzufolgen erst noch gruppenintern der Stand abgeglichen werden muss. Das gilt auch (und ganz besonders!) in Bezug auf die Einbindung der Tester. Was die verbleibende Zeit betrifft: der Zeitplan ``Ende des Semesters ist Schicht'' bleibt, da weder von unserer Seite noch (vermutlich) von Seiten der Studenten eine ``Dauerveranstaltung'' gew"unscht wird (ms: von mir wird sie jedenfalls nicht erw"unscht....). Das bedeutet: wenn sich im Lichte des - bisher erreichten - des noch zu erreichenden/geplanten, daraus folgend - der bislang beobachteten Geschwindigkeit, und - m"oglicher Stolplersteine auf dem Weg ins Ziel abzeichnet, das man sich einzelne Funktionalit"aten > vereinfachen muss (einfacherer Balancieralgorithmis, einfachere Forum einfachere Oberfl"ache, was auch immer) > (Extra)features weggelassen muss dann soll man das _geplant_ so machen. Mit ``geplant'' ist gemeint da"s man explizit sagt - Dies und das lasse wir weg/implementieren wir nicht Nicht statthaft ist: ``unser vereinfachter Plan sieht vor dass wir alles implementiere, soweit wir es halt schaffen, und am Ende schau'mer mal: das was da ist, ist das was wir wollten...'' Ferner soll man ber"ucksichtigen, da"s es nicht gut ist den ``Fertigstellungstermin'' auf den Tag der Demo zu setzten! Der Plan sollte mindestens 2 Wochen vorher sagen: da planen wir, im Grunde fertig zu sein! (erstens kommt es eventuell anders, zweitens muss man eventuell noch nachbessern, denn die Tester werden nicht 2 Wochen vorher die Arbeit einstellen....Umgekehrt natuerlich: die Tester fangen auch nicht 2 Wochen vor Ende des Semester an, das ist auch hoffentlich klar.) Aktionsplan: jeder der Gruppen setzt sich - intern zusammen, und gleicht sich untereinander ab wie der Status ist - Entwickelt ein Statement im Lichte des oben gesagten, ob sie noch im Zeitplan sind bzw ob sie einen Reduzierten Umfang realisieren wollen/muessen (und worin die Reduktion besteht!) - Die Interne Absprache geschieht unter Mitwirkung des Testers, denn jeweilige muss verst"arkt eingebunden werden! Speziell die Gruppen PHP2 und Java soll die Sache auch nicht nur intern abkl"aren sondern in einer Sitzung bei der mindestens einer von uns (Gunnar/Marcel/ich) dabei sind, da der Wunsch von mindestens einem Mitglied der Gruppe ge"au"sert wurde. Gruppe PHP1 glaubt, die interne Coordination (und die Coordination mit Ihrem Tester) selbstst"andig regeln zu k"onnen; eine Gemeinschaftssitzung dann nur nach Bedarf. o SQL-Testdaten: Oliver Niemann hat die in der Mache, aber die ``Klienten'' (bis auf eventuell PHP1?) nutzen sie noch nicht (aber der Wunsch ist vorhanden. Auch dies muss schleunigst in die Wege geleitet werden (und ist sicherlich ein Punkt der bei den Gruppen-Coordinationssitzungen auf der Tagesordnung stehen wird..... Spezielle sind auch ``gute Daten'' im Gegensatz zu ``boesen Daten'' erw"unscht, sowie vermutlich Doku und Kommunkation. o Admin Rolle aka Henne/Ei-Problem Angeregt durch das Problem der PHP1 Gruppe kamen 2 Dinge zum Vorschein: 1) keine der Gruppen verwendet die Admin-Rolle f"ur Konferenzen, die in trunk/sql/db_schema.txt beschrieben sind. 2) Keine der Gruppen verwendet die an gleicher Stelle beschriebene Option der Roles-Tabelle (nicht role), die in den Diskussionen f"ur diejenigen als optional erlaubt wurden, die ein flexibleres und erweiterbareres Schema wollten als das feste, numerische Schema "uber Integers. Da also niemand Admin als Rolle einer Konferenz implementiert noch die Tabelle Roles verwendet => - die numerischen Rollen-Werte sind nach Beschluß somit für alle Verbindlich bis auf die Rolle admin. - Die Tabelle Roles fällt weg. (Sieht nun etwas unsch"on aus, da"s die Nummer 01 nicht verwendet wird, aber daf"ur mu"s man den Code nicht anpassen. => Aktion: wir (org) "andern das in trunk/sql, die globale Spec wird von uns angepasst. o Endabnahme: Demo+Vortrag, wir werden uns um einen Raum mit Zugriff auf Snert k"ummern (vermutlich Ue2, wie gehabt). Martin ==== ``sondermeldung''== Moin. Das hatten wir vergessen anzumerken, und es ist wichtig, deswegen die ``Sondermeldung''. Heute stand auf dem Plan: Status/Plan bis zum Ende des Semester. daraus ist nichts geworden, aus dem Umstand heraus, dass sich die Gruppen nach der partiellen Weihnachtspause erstmal selbst wieder Gegenseitig abgleichen muessen. Genehmigt und ergibt Sinn.... Umso _dringender_ ist ein vern"unftiger, koordinierter expliziter Statusbericht und Restplan der Gruppen beim kommenden Mal! -- Wer, um sich daf"ur zu begeistern, eine Begr"undung braucht: 1) Anders als zuvor, wo man noch Dinge ausgleichen aufholen konnte (oder sich dies zumindest einreden konnte: ``ach, wenn erst mein Seminarvortrag rum ist, an Heiligabend, da arbeite ich doppelt, unterm Weihnachtsbaum kann ich immer gut denken'') ist die Phase nun so da"s Zeit, die man sich jetzt versch"atzt wird man _nicht_ wieder aufholen koennen Die Alternativen w"aren: Todesmarsch (tut mir Leid, ist ein Fachwort, kein geschmackvolles, zugegeben) was vermutlich auch nix bringt, oder Ferienarbeit, oder unvollst"andige Deliverables. Das heisst: jetzt (oder nie) ist ein wichtiger Moment, realistisch zu sagen, was ist, was kommt noch 2) Wir muessen realisieren, da"s wir Zeit zur integration/testen/chill-out brauchen (chill-out = Vorbereitung auf die Demo). Wie gesagt, die Demo wird nicht gehen, wenn man das so plant: 12:00: Letzter Termin da"s jeder hat seinen code abgegeben hat 12:05: Zusammenbau 12:10 das erste ``Aaahh, es l"auft alles zusammen'' -- Was meinen wir Mit ``koordiniertem Statusreport/Zukunftsreport'' meinen wir nicht: ------------------------------------------------------------------ -> Wie siehts aus, mit Gruppe G, vielleicht sagt Mr x was dazu? <- Oeh, l"auft so, aus meiner Sicht, 3/4 durch, von den andern, weiss ich nicht so genau. -> Ok, fragen wir sie: und bei Dir, Mr y aus Gruppe G? <- bei mir auch, ich sch"atze ich bin bei 67% -> und bei Dir, Mr z? <- geht so, bei mir ungef"ahr 81% -> also im Durchschnitt bei Gruppe G 75%? <- Jau, kommt hin (bis auf die vielleicht, die nicht da sind, aber wir fragen mal). -> Prima. N"achste Gruppe ------------------------------------------------------------------ Was dann: Die Gruppe stellt ihren Status vor, explizit. Einer der f"ur den Report die Wortfuehrerschaft "ubernimmt stellt ihn als _gemeinsamen_ Status vor (also besser nicht Dinge pr"asentieren wie: ``den Teil von dem Typen, dessen Namen ich vergessen habe, kenn ich nicht so genau''. Die Vorstellung braucht kein Folienvortrag sein (machen wir ja im Semester auch nicht, sollte aber an der Tafel stattfinden, also an der Rampe, und nicht bequem von der Hinterbank aus. Es ist das _Publikum_ der anderen Gruppen (also nicht immer nur wir) ermuntert, Kommentare, Fragen, Anregungen, Hilfe oder "ahnliches zu "au"sern. Vielleicht lernen wir sogar voneinander! Explizit hei"st nicht nur ``eine Pr"asentation vor dem Klassenraum'' sondern auch ein schriftliches Statement, welches wir vorher verteilen (und ausgedruckt mitbringen). Man k"onnte sich vorstellen, da"s die spec/architecture Beschreibung (die ja alle gruppen gemacht haben :-) ein Rolle dabei spielen kann. Worauf wir hinauswollen ist: nehmt das bitte Ernst, wir wollen daruch Euch einen etwas gehaltvolleren Statusreport entlocken, als bisher, und durch (eventuelle) Diskussion eventuelle Stolpersteine auf dem Weg ins Ziel identifieren und wenn m"oglich entsch"arfen (und viel Zeit um Dinge zu entsch"arfen ist nicht mehr). Ferner f"anden wir es gut, wenn aus den Gruppen diejenigen die Wortf"uhrerschaft "ubernehmen, die sonst sich zur"uckhalten (wer sich angesprochen f"uhlt, der ist gemeint :-) Die Gruppe Test ist wieder mal ein Sonderfall. Weil sie auf mehr oder minder auf 3 Gruppen zugeteilt ist, wollen wir von von jedem der Tester ein solches Statement. Soviel dazu, was heute mittag hinten runter gefallen war. Martin PS: die zwei W"unsche nach Extra-Terminen (Beratung, Koordination, Planung) f"ur PHP2 und Java bleiben nat"urlich bestehen! ===== vorankuendigung ==== Moin + Gutes Neues. Was steht morgen auf dem Plan? Das wichtigste was mir so einf"allt ist : o Status/Plan fuer den Rest. Auch wenn Weihnachten war, ist die Arbeit bei einigen Gruppen anscheinend weitergegangen, auch sind wir demn"achst auf die Zielgerade gehen: - wie weit ist der Forstschritt, wieviel wird noch bis Ende gemacht? Insbesondere im Lichte der (eventuellen) Fortschritte in der Vergangenheit: wie viel ist realistisch noch zu schaffen? > Merke: besser einen reduzierten Leistungsumfang sicher, fest, und getestet und lauff"ahig als eine unrealistischen grossen Leistungsumfang, der aber hinten und vorne klappert. Da wir uns, wie gesagt, auf die Zielgerade zubewegen, sollte man aus dem bislang erreichten eine gute und realistische Absch"atzung des noch zu erreichenden abgeben k"onnen. > Beachte: man soll _nicht_ so planen, da"s man bis um 24 Uhr des letzten Tages des Semesters codet! Insbesondere wegen des kommenden Punktes ``Testing'': o Einbindung der Tester das ist angelaufen. Wie ist der STand/Plan da? Speziell: wie sieht es mit den Testdaten aus. Es gab (oder gibt?) aber ein paar Reibungspunkte, die m"ussen bereinigt sein/werden Daneben: o technisches Problem des Datenmodells: Admin-rolle resp. Henne-Ei-Problem? dies hat die Gruppe PHP2 (speziell Torben) heute aufgeworfen und entspricht auf dem ``Fehler #42'' von Mohamed. Zun"achst einmal ist es kein Fehler der SQL-Spec (behaupte ich mal) denn die Admin-Rolle dort nicht festgeschrieben! Auch die Informelle Requirements sagen nichts darueber aus, sondern stellen ihn ``ausserhalb'': `` The administrator is not part of the scientific organization of the conference, i.e., he does not take part semantical decisions concerning the content. In a certain sense, he's outside the game.'' Dennoch scheinen alle drei Gruppen (php1/php2,java) sich einen admin als Rolle zugedacht zu haben. Aus der Diskussion mit Torben schienen folgende 3 (oder 5) L"osungsans"atze denkbar. 1) InnoDB weg, myisam w"urde hier nicht meckern. => aus meiner sicht keine L"osung, bestenfalls ein schlechter Hack. Ausserdem wollen wir den InnoDB-Flamewar nicht noch mal.... 2) den Constraint f"ur Person-Rolle-Konferenz wegwerfen. Analog wie 1), 2a) eventuell erlaubt es SQL, den Constraint selektiv f"ur nur die Admin-rolle aufzuheben. Kein so ein hack mehr wie 2), aber wahrscheinlich nicht m"oglich 3) Admin ist keine Rolle 3a) Admin daten werden in ein einer Extra-Tabelle gehalten, die ausserhalb der Konferenzen-Tabelle stehen 3b) Admin ist nur virtuell vorhanden, d.h., gar nicht in den DB-Tabellen (sondern nur irgendwo anders, eventuell, oder nur durch die Tatsache, da"s er root zugriff hat...) Der Nachteil dieser L"osung ist, da"s PHP2 (und andere Gruppen) fest den Admin in ihr Rechte-System etc eingebaut haben. 4) ``Default-Konferenz'' Es wird eine default-konferenz angelegt, dies zerbricht den Deadlock Henne-Ei. Sie ist immer vorhanden, kann auch nicht gel"oscht werden und hat einen default-Bezeichner (z.b. der Leere String). Vermutlich die sauberste und f"ur alle schmerzloseste L"osung. Martin