From 3d7fb2e703c78488133f46aad30f3601f25780a9 Mon Sep 17 00:00:00 2001 From: murat Date: Tue, 29 Nov 2011 14:36:49 +0100 Subject: [PATCH] bla --- .../11-11-29-Treffen-Notizen.txt | 45 +++++++++++++++++++ ws2011/BP/Auftraggebertreffen/treffen ag.txt | 45 ------------------- 2 files changed, 45 insertions(+), 45 deletions(-) delete mode 100644 ws2011/BP/Auftraggebertreffen/treffen ag.txt diff --git a/ws2011/BP/Auftraggebertreffen/11-11-29-Treffen-Notizen.txt b/ws2011/BP/Auftraggebertreffen/11-11-29-Treffen-Notizen.txt index e69de29b..61865af1 100644 --- a/ws2011/BP/Auftraggebertreffen/11-11-29-Treffen-Notizen.txt +++ b/ws2011/BP/Auftraggebertreffen/11-11-29-Treffen-Notizen.txt @@ -0,0 +1,45 @@ +- bei fragen vorher ne mail schicken +- code aufräumen? falls was auffällt, gerne +- json haben wir noch nicht --> nur das neue +- api - was soll es können? ++ daten ein-auslesen (Hauptfokus auslesen) ++ authentifizierung macht grad noch die alte gruppe ++ sollen wirs umstellen aufs neue format? --> ++ framework benutzen: propl problem: dabaschema nicht kompatibel zum standart xml... --> er-dia vom julien +++ propl hauptidee: abstr.layer (orm) ++ tools (orm-designer), die dieses format ausspucken... ++ propl benutzen? --> ++ progs mit dem wir erdia einlesen --> evtl propl xml als output ++ wie weit sinvoll? --> aus xml nur klassen ++ ER und propl stellen gleiches da ++ ruby race: eigene shcemadateien schreiben, daba aufschreiben in pseudo skriptingsprache, einmal machen wenn sich danach was ändert hmmm ++ ansonsten research machen ++ doktrin, propl ++ schon machen, auch wenn man die daba in dieses format schreibven muss ++ mapper verwenden ++ daba spezifizieren bei den mappings ++ benutzt propl +- api: doku wie man daten rein/rauskriegt +- api: nicht mehr als das was es jetzt kann, erst mal auf die neue daba +- api: nach allem filtern können was mgl ist (knoten, geoinfos, datentypen) (alte daba) +- api: authentif nutzer - sql abfrage --> nicht über api +- api: sicherheit, wenn man sql abfragt +- benutzer api nur read auf daba für sql abfragen auf daba +- api: kontrolle was man an infos nach aussen gibt, wollen wir die kontrolle abgeben? eher nicht +- api: rohe sql response +- alternative: api wie man sie kennt basteln +-> daba parsen +!!!!- propl aufsetzen, sql querys auf die neue daba umstellen mit propl +!!!!- querys an ner zentralen stelle sammeln +!- refactory +- code verschönern +- code in einen test ordner duplizieren auf dem server +- 12 dez kommen zwei sensoren auf straba, dann kommen auch daten.... +- julien ist noch an json (spätestens in 2wochen) +!!!- wg api überlegt AG sich nochmal +- visualisierung: gdv'ler ranziehen, vll ändert sich da noch was +- ins svn dürfen wir einchecken (alles) + +zweck an sich: energieeffiziente sensornetzwerke +für die stadt: temp: mikroklimaindex (abschaltungsflächen heizungsflächen bepflanzung) +dB: (grundidee, smartphones mit mirkofon) lärmschutz, hohe datendichte, können alle mitmachen \ No newline at end of file diff --git a/ws2011/BP/Auftraggebertreffen/treffen ag.txt b/ws2011/BP/Auftraggebertreffen/treffen ag.txt deleted file mode 100644 index 61865af1..00000000 --- a/ws2011/BP/Auftraggebertreffen/treffen ag.txt +++ /dev/null @@ -1,45 +0,0 @@ -- bei fragen vorher ne mail schicken -- code aufräumen? falls was auffällt, gerne -- json haben wir noch nicht --> nur das neue -- api - was soll es können? -+ daten ein-auslesen (Hauptfokus auslesen) -+ authentifizierung macht grad noch die alte gruppe -+ sollen wirs umstellen aufs neue format? --> -+ framework benutzen: propl problem: dabaschema nicht kompatibel zum standart xml... --> er-dia vom julien -++ propl hauptidee: abstr.layer (orm) -+ tools (orm-designer), die dieses format ausspucken... -+ propl benutzen? --> -+ progs mit dem wir erdia einlesen --> evtl propl xml als output -+ wie weit sinvoll? --> aus xml nur klassen -+ ER und propl stellen gleiches da -+ ruby race: eigene shcemadateien schreiben, daba aufschreiben in pseudo skriptingsprache, einmal machen wenn sich danach was ändert hmmm -+ ansonsten research machen -+ doktrin, propl -+ schon machen, auch wenn man die daba in dieses format schreibven muss -+ mapper verwenden -+ daba spezifizieren bei den mappings -+ benutzt propl -- api: doku wie man daten rein/rauskriegt -- api: nicht mehr als das was es jetzt kann, erst mal auf die neue daba -- api: nach allem filtern können was mgl ist (knoten, geoinfos, datentypen) (alte daba) -- api: authentif nutzer - sql abfrage --> nicht über api -- api: sicherheit, wenn man sql abfragt -- benutzer api nur read auf daba für sql abfragen auf daba -- api: kontrolle was man an infos nach aussen gibt, wollen wir die kontrolle abgeben? eher nicht -- api: rohe sql response -- alternative: api wie man sie kennt basteln --> daba parsen -!!!!- propl aufsetzen, sql querys auf die neue daba umstellen mit propl -!!!!- querys an ner zentralen stelle sammeln -!- refactory -- code verschönern -- code in einen test ordner duplizieren auf dem server -- 12 dez kommen zwei sensoren auf straba, dann kommen auch daten.... -- julien ist noch an json (spätestens in 2wochen) -!!!- wg api überlegt AG sich nochmal -- visualisierung: gdv'ler ranziehen, vll ändert sich da noch was -- ins svn dürfen wir einchecken (alles) - -zweck an sich: energieeffiziente sensornetzwerke -für die stadt: temp: mikroklimaindex (abschaltungsflächen heizungsflächen bepflanzung) -dB: (grundidee, smartphones mit mirkofon) lärmschutz, hohe datendichte, können alle mitmachen \ No newline at end of file