alles

ws2011/.gitignore

@@ -0,0 +1,2 @@
+
+Semantic

ws2011/BP/API Propel Stuff/propel_irc_help.rtf

@@ -0,0 +1,35 @@
+{\rtf1\ansi\ansicpg1252\cocoartf1138\cocoasubrtf230
+{\fonttbl\f0\fmodern\fcharset0 Courier;}
+{\colortbl;\red255\green255\blue255;\red237\green245\blue255;\red245\green0\blue0;}
+\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
+\deftab720
+\pard\pardeftab720
+
+\f0\fs26 \cf0 \cb2 [09:02] <tud> Do propel has the option to automatically join tables with their foreign key? I have some tables and would like to join them all with their foreign keys\
+[09:05] <\cf3 Jarda\cf0 > tud: you can do FooQuery::create()->joinWith('Foo.Bar')->find()\
+[09:06] <Jarda> didn't really get what you mean\
+[09:06] <tud> Is "Bar" the foreign key in your example?\
+[09:07] <Jarda> yeah\
+[09:07] <tud> thanks\
+[09:08] <tud> dorn here xD\
+[09:08] <tud> the problem is we need 2 join a lot of tables dynamicly\
+[09:08] <tud> is there a best pratice\
+[09:09] <tud> for example we get via get params ColumnA,TableA and ColumnB,TableB -> now we need 2 join those 2 tables and select the 2 coulmns\
+[09:09] <tud> this needs 2 be done dynamicly\
+[09:09] <Jarda> hmm.. ok\
+[09:09] <tud> any ideas?\
+[09:09] <Jarda> well\
+[09:10] <Jarda> you could in your FooQuery class write a public function joinByParameters(array $params) \{\'a0foreach ($params as $parm) \{ $this->joinWith(...); \} return $this; \}\
+[09:10] <Jarda> or something like that\
+[09:10] <Jarda> depends on the specific use case\
+[09:12] <tud> so the best way is 2 use joinwith where u give the column u wanna join on?\
+[09:12] <Jarda> yeah, or actually it's the foreign key name you give as parameter\
+[09:13] <Jarda> <foreign-key foreignTable="bar"><reference local="bar_id" foreign="id" /></foreign-key> and then you use ->joinWith('Foo.Bar');\
+[09:13] <tud> what happens if u have done smith like this: tbl1->join with(tbl2.column) ->joinwith(tbl3.column)->join with(.... does that work?#\
+[09:13] <Jarda> you can have multiple joins, yes\
+[09:14] <tud> and he automatically detects how 2 join it? over multiple tables?\
+[09:14] <Jarda> yes, it should work\
+[09:16] <tud> for example if tbl1.A->tbl2.A and tbl1.B->tbl3.A but we join tbl1->join with(tbl2.A)->join with(tbl3.A) - this will work?\
+[09:17] <Jarda> if the foreign keys are wrintten in the schema, it should work\
+[09:17] <Jarda> try it out\
+[09:18] <tud> k much thx if that works its really amazing work ;-) much thx 4 the help}

ws2011/BP/Auftraggebertreffen/11-11-15-Treffen-Notizen.txt

@@ -0,0 +1,11 @@
+qs doc
+wiki für docs auf der homepage weiterführen
+mit den vorgängern treffen - mit code auseinandersetzen
+gui und visualisierung wird angeschaut
+api definieren und der ersten gruppe bescheidgeben
+(zugangsdaten zum webserver kommt per email, formulare zum tk-acc, daten von den anderen)
+sftp-zugang
+tk-accounts laufen bis anfang sose
+reines php für die website
+mysql für die datenbank
+zugang zum webserver über ssh und/oder telnet...

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

ws2011/BP/Auftraggebertreffen/11-12-13-Treffen-Notizen.txt

@@ -0,0 +1,42 @@
+propel anpassen
+sqls umschreiben
+julien anschreiben wg neues er-dia -> hab ich hochgeladen
+
+wiki beim code weiterführen -> git
+-wiki: grob überblick, was wir ändern
+propel z.b.
+was hat sich geändert, was mussten wir machen (bsp sql abfrage alt/neu) (allg. beispiele was passiert)
+wenn fkt schwer verständlich sind, dokumentieren (wichtiges ins wiki, ansonsten code)
+strukturdokumentation und wichtige änderungen im laufe des projektes in die wiki
+api doku auch in die wiki
+
+-api: abstrakt, keine sql-commands ausspucken
+mashup (andere können daten anbinden)
+xml ausgabe? <- das nicht
+json ähnlich wie xml? <- das hier
+anfrage an api, wie? - request an url
+array-werte angeben -> alle mgl filter
+-> strukturierter request
+so wies im mom funzt solls wieder funzen (wenn wirs mit propel machen kommen wir an api.php da passiert dann alles)
+api in funtkion bringen mit der neuen datenbank (wird mit den ganzen mobilen anwendungen genutzt)
+1. identifier <- im mom
+2. abstrahieren
+
+
+-qs-doku:
+funktionalität und benutzerfreundlichkeit
+benfrkeit: noch mal ne studie machen... (googledocs umfrage)
+kompatibilität (api und neue daba eingebaut, ob iwo iwelche apps probleme bekommen)
+interoperablilität mit verschiedenen browsern, html5 (teil der javascript api)
+(bzgl der visualisierung animationen reinbauen
+- wir schauen, wie wir das machen...)
+
+-fokus auf refactoring:
+propel mit sql, da muss man sowieso refactoren
+
+(parameter.php kann man wieder ins github hochladen
+ins git die änderungen pushen, wenns stable ist, kann man auf dem server dann pullen...)
+
+-sql zeugs zentral verwalten?
+in eine datei (model.php :-) )
+css auch zentral, so wie wirs grad haben =) (creplace(ments), view.class.php)

ws2011/BP/Auftraggebertreffen/12-01-10-Treffen-Notizen.txt

@@ -0,0 +1,14 @@
+- view bis nächstes treffen
+- propel integration bis nächstes treffen
+- json parser bis nächstes treffen
+- immanuel tifft sich mit visualisierungsfrau nächsten montag
+- authentifikation nicht geklärt wer es macht
+- json besprechung -> leq/data -> umbennen nach "value"
+- waspnodes - divice id = mac address
+- oauth file -> war ein test -> kann weg
+- präsentation: Über Projekt + Website -> nicht über coderefactoring
+- speed mit ins json aufnehmen
+- ein einziges json format - keine unterschiede für verschiedene anwendungen
+- das andere jsonformat -> für update der diviceinfo
+- weiter auf testsite arbeiten
+- nächstes treffen wieder 13:30

ws2011/BP/Auftraggebertreffen/12-01-24-Treffen-Notizen.txt

@@ -0,0 +1,12 @@
+Nächstes Treffen:
+nächsten Dienstag (31.01.2012): 10.oo Uhr
+
+- Propel fertigmachen
+- Noisemap: wurde von Chris komplett neu geschrieben. Hat kein Propel wegen Zeitdruck genutzt. Sein Endpoint soll richtig funktionieren. Im Moment keine andere Möglichkeit. 
+- API muss komplett (reinschreiben, auslesen) funktionieren und soll dann auf die hauptseite geschoben werden.
+- API mit Noisemap-App testen!
+- Testen, testen, testen!
+- Authentifizierung: checken ob der User eine gültige sessionID hat bzw. diese authentifiziert ist bevor Daten in die  Datenbank geschrieben werden können.
+- Benutzerbereich muss bis 1.2. fertiggestellt werden
+- HTML5-Map einbinden, wenn wir sie erhalten
+

ws2011/BP/Auftraggebertreffen/12-01-31-Treffen-Notizen.txt

@@ -0,0 +1,32 @@
+Di, 31.01.2012
+
+-API Sachen einschränken
+-Falls sich Namen der Messserie nicht ändert, dann wird das
+ zusätzlich in die Datenbank aufgenommen
+-Uid: Name der Messserie + UserId (gibt es in der neuen DB nicht)
+-Mehrere tags an ein Value möglich
+-Join geht über Primärschlüssel
+-Reinschreiben hat höchste Priorität (bis Morgen)
+-Map-Filter (GPS, Mobilfunk, Zeit) <-- müssen wieder funktionieren
+  Reicht erst einmal als Funktionalität, wenn das funktioniert
+-GET einbauen, die auch benutzt werden für die Map
+-In den Filtermöglichkeiten gibt es keine Unterschiede
+-Notfalls im Parser die Namen der Felder ändern
+-Benutzerbereich kann erst einmal weggelassen werden
+-Wichtig: Wenn kein Benutzer, dann nur anzeigen von öffentlichen
+Datensätzen auf der Karte
+-Visibility:0 -> Mit Christian und Julien absprechen, was
+öffentlich und was private ist
+-Private Daten nicht ohne login anzeigen
+-Checkboxen (GPS, Mobilfunk) <-- GPS zeigt immernoch alle
+Werte an <-- korrigieren
+-Karte soll auf neue API arbeiten
+-Neuen Filter einbauen, wenn ein Benutzer eingeloggt
+  -Eigene Daten (Öffentliche + Private (mit UserID))
+  -Öffentliche Daten (sichtbar für alle)
+  -Alle Daten(Eigene + Öffentlich)
+-Seite soll zu Beginn der Benutzerstudie nicht komplett sein,
+ aber zumindest die Daten aus der neuen DB anzeigen können
+-API soll bis Ende der Woche fertig sein
+-eMail an Immanuel, wenn JSON-Parser funktioniert
+-Danach: HTML5 und Visualisierung

ws2011/BP/Auftraggebertreffen/12-02-21-Treffen-Notizen.txt

@@ -0,0 +1,7 @@
+Di, 21.02:
+
+- moses, traffic analysis, traffic data, cron, productive, …
+	-> alle Ordner die nicht zu uns gehören stehen lassen
+- unceclustered deployen
+- filter einbinden
+- 

ws2011/BP/Auftraggebertreffen/12-03-07-Treffen-Notizen.rtf

@@ -0,0 +1,12 @@
+{\rtf1\ansi\ansicpg1252\cocoartf1138\cocoasubrtf320
+{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
+\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatural
+
+\f0\fs24 \cf0 - Stra\'dfenbahnsensoren "null"\
+- alle Filter funtkionieren\
+- Sensorfilter weg, Filteroptionen nehmen dingens auf\
+- graph in fancybox;\
+- Graph muss die verschiedenen Sensoren anzeigen. Wie ist noch offen und uns erstmal \'fcberlassen!\
+- API whitelist: nur API-Abfragen zulassen, die von der Website ben\'f6tigt werden!}

ws2011/BP/Auftraggebertreffen/12-03-27-Treffen-Notizen.rtf

@@ -0,0 +1,8 @@
+{\rtf1\ansi\ansicpg1252\cocoartf1138\cocoasubrtf320
+{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
+{\colortbl;\red255\green255\blue255;}
+\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
+\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatural
+
+\f0\fs24 \cf0 - Filter aus der API auskommentieren\
+- Zeitfilter Heatmap fixen}

ws2011/BP/Code Review/sql-found-windows.txt

@@ -0,0 +1,222 @@
+Datei: /ordner/dateiname
+Zeile x bis y
+---------------------------------
+Datei: /JsonParser.php
+Zeile 146
+Zeile 150
+Zeile 158
+Zeile 164
+Zeile 180
+Zeile 187
+Zeile 194
+Zeile 212 bis 217
+
+Datei: /markers.php
+Zeile 17 bis 94
+Zeile 117 bis 124
+Zeile 156
+
+Datei: /show.php
+Zeile 26, 33
+
+Datei: /classes/Data.php
+Zeile 014
+
+Datei: /classes/DataItem.php
+Zeile 025
+
+Datei: /classes/getCSV.php
+Zeile 019
+
+Datei: /classes/db/ArgumentController.php
+Zeile 077
+Zeile 290 //
+Zeile 292 //
+
+Datei: /classes/db/DasenseLogin.php
+Zeile 084
+Zeile 108
+
+Datei: /classes/db/DasenseRegistration.php
+Zeile 125
+Zeile 141
+Zeile 151
+
+Datei: /classes/db/DasenseSelect.php
+Zeile 052
+Zeile 055
+Zeile 062 //
+Zeile 063
+Zeile 065
+Zeile 069
+Zeile 073 bis 076
+Zeile 081
+Zeile 099 bis 101 //
+Zeile 106 bis 109
+Zeile 120
+Zeile 121
+
+Datei: /classes/db/DBSCANHandler3.php
+Zeile 166
+
+Datei: /classes/db/DBSCANHandlerRecursive.php
+Zeile 151
+
+Datei: /classes/db/DBSCANNodeHandler(2).php
+Zeile 008
+
+Datei: /classes/db/DBSCANSquareHanlder.php
+Zeile 008
+
+Datei: /classes/db/account/DasenseLogin.php
+Zeile 096
+Zeile 152
+
+Datei: /classes/db/analysis/AddressHelper.php
+Zeile 051
+
+Datei: /classes/Data.php
+Zeile 014
+
+Datei: /classes/getData.php
+Zeile 55
+Zeile 60 bis 77
+Zeile 83, 86, 94
+
+Datei: /classes/registrationCommand.php
+Zeile 23, 28, 32
+
+Datei: /classes/SecuredCheck.php
+Zeile: 30 bis 31
+Zeile: 68 bis 69
+Zeile: 78, 110
+
+Datei: /classes/db/DBSCANSquareNoExpandHandler.php
+Zeile 8
+
+Datei: /classes/db/JsonParserOO.php
+Zeile 167, 171, 179, 185, 201, 208, 215
+Zeile 229 bis 234
+Zeile 244, 251
+
+Datei: /classes/db/Logger.php
+Zeile 102
+
+Datei: /classes/db/SQLDelete.php
+Zeile 5
+
+Datei: /classes/db/SQLInsert.php
+Zeile 14
+
+Datei: /classes/db/SQLQuery.php
+Zeile 57, 75, 97, 134, 144, 151
+
+Datei: /classes/db/SQLSelect.php
+Zeile 35, 56, 63, 70, 77, 79, 88
+
+Datei: /classes/db/SQLUpdate.php
+Zeile 20
+
+Datei: /classes/db/account/DasenseRegistration.php
+Zeile 118, 134, 144
+
+Datei: /classes/db/account/DasenseRegistrationStudy.php
+Zeile 133
+
+Datei: /classes/db/analysis/SerieDetails.php
+Zeile 48, 74 bis 76
+Zeile 119 bis 121
+Zeile 157 bis 159
+Zeile 190 bis 192
+Zeile 236 bis 238
+
+Datei: /templates/admin_data_table.php
+Zeile 050
+Zeile 386
+Zeile 454
+Zeile 489
+Zeile 521
+
+Datei: /templates/admin_page_management.php
+Zeile 051
+Zeile 237
+Zeile 387
+Zeile 456
+Zeile 491
+Zeile 523
+
+Datei: /templates/admin_user_management.php
+Zeile 054
+Zeile 249
+Zeile 412
+Zeile 481
+Zeile 516
+
+Datei: /templates/create_app.php
+Zeile 040
+
+Datei: /templates/dasense.php
+Zeile 004
+
+Datei: /templates/geopoint.php
+Zeile 005
+
+Datei: /templates/location.php
+Zeile 5
+
+Datei: /templates/login_user.php
+Zeile 167 bis 168
+
+Datei: /templates/map.php
+Zeile 4
+
+Datei: /templates/oauth_verify.php
+Zeile 26, 32, 51
+
+Datei: /templates/sensor.php
+Zeile 5
+
+Datei: /templates/user_account_management.php
+Zeile 54, 206, 259
+
+Datei: /templates/user_data_table.php
+Zeile 99, 291, 435, 635, 671
+
+Datei: /tools/csv-export.php
+Zeile 012 bis 014
+Zeile 018
+Zeile 020
+
+Datei: /tools/generator.php
+Zeile 11, 23, 33 bis 39
+
+Datei: /wsdl/index.php
+Zeile 035 bis 041
+Zeile 171 bis 176
+Zeile 202
+Zeile 213
+Zeile 223
+Zeile 268 bis 273
+Zeile 309
+Zeile 320
+Zeile 339
+Zeile 350
+Zeile 360
+Zeile 385
+Zeile 387
+Zeile 414
+
+Datei: /wsdl/backup/index.php
+Zeile 141 bis 146
+Zeile 172
+Zeile 183
+Zeile 193
+Zeile 235 bis 240
+Zeile 275
+Zeile 286
+Zeile 305
+Zeile 316
+Zeile 326
+Zeile 349
+Zeile 351
+Zeile 375

ws2011/BP/Code Review/template zeugs was was ist.txt

@@ -0,0 +1,25 @@
+/lang/de-de/default/
+data.php
+dbscan.php
+geopoint.php - rechtsklick auf karte -> geopoint
+home.php - frame am anfang
+impressum.php - Impressum
+location.php
+map.php
+project.php - Über das Projekt
+sensor.php - auf ein sensor klicken und auf die id klicken...
+
+/lang/de-de/error/
+general.php - Benutzer
+
+/lang/de-de/
+dasense.php - homepage
+
+/templates/
+about.php - Über das Projekt-Frame
+dasense.php - Homepage
+geopoint.php - rechtsklick auf karte und geopoint
+home.php - anfangsframe (Herzlich willkommen)
+impressum.php - Impressum-Frame
+login_user.php - Benutzer-Frame
+sensor.php - klick auf den einzelnen sensor und die id

ws2011/BP/Json von Julien/json_testen.txt

@@ -0,0 +1,24 @@
+
+
+JSON Format falg = deviceinfo:
+
+http://www.da-sense.de/test/api.php?flag=deviceinfo&json=02-15 23:32:20.992: D/JSON_DATA(10367): Request: {"device":"357194040202988","series":[{"timestamp":1329344950572,"visibility":1,"values":[{"tags":[{"value":"66150","key":"measurement:samples:count"}],"timestamp":1329344154574,"speed":0,"altitude":0,"value":37.9518928527832,"provider":"network","longitude":8.608966,"latitude":49.6767661,"accuracy":26},{"tags":[{"value":"220500","key":"measurement:samples:count"}],"timestamp":1329344159599,"speed":0,"altitude":0,"value":31.49476432800293,"provider":"network","longitude":8.608966,"latitude":49.6767661,"accuracy":26},{"tags":[{"value":"220500","key":"measurement:samples:count"}],"timestamp":1329344956096,"speed":0,"altitude":0,"value":34.84609603881836,"provider":"network","longitude":8.6088607,"latitude":49.6690467,"accuracy":1750}],"name":"Messreihe @ 15.02.2012 23:29:09"},{"timestamp":1329345063600,"visibility":1,"values":[{"tags":[{"value":"220500","key":"measurement:samples:count"}],"timestamp":1329345068976,"speed":0,"altitude":0,"value":34.751121520996094,"provider":"network","longitude":8.6088607,"latitude":49.6690467,"accuracy":1750}],"name":"Messreihe @ 15.02.2012 23:31:02"},{"timestamp":1329345132005,"visibility":1,"values":[{"tags":[{"value":"66150","key":"measurement:samples:count"}],"timestamp":1329345134053,"speed":0,"altitude":0,"value":36.24472427368164,"provider":"network","longitude":8.6089665,"latitude":49.6767497,"accuracy":36}],"name":"Messreihe @ 15.02.2012 23:32:10"}],"user":5,"measurementType":1}
+
+
+{"deviceType": 2, "deviceID": "12345", "deviceManufactor": "LIBELIUM", "deviceModel": "TESTWASPMOTE", "deviceName": "Test Waspmote", "sensors": [ { "type": 4, "sensorAttributes": [ {} ] } ] }
+
+
+02-15 22:43:43.601: D/JSON_DATA(9798): <b>Fatal error</b>:  Class 'dasensedata\SensorTypesQuery' not found in <b>/home/dasense/test/classes/propel/propel_dasensedata.php</b> on line <b>231</b><br />
+
+
+JSON Format flag = input:
+
+http://www.da-sense.de/test/api.php?flag=input&source=smartphone&json={"device":"201288","measurementType":1, "user":20, "series": [ { "name":"newTableNames", "visibility":0, "timestamp":123 , "values": [ { "timestamp":1, "value":52.25234634, "longitude":0, "latitude":0, "altitude":0, "accuracy":0, "speed":null, "provider":"GPS", "tags": [ { "key": 1, "value":35 } ] } ] }, { "name":"testseries5", "visibility":0, "timestamp":2 , "values": [ { "timestamp":1, "value":62.25234634, "longitude":0, "latitude":0, "altitude":0, "accuracy":0, "speed":null, "provider":"GPS", "tags": [ { "key": 1, "value":35 } ] } ] }] }
+
+
+JSON Format result = ? :
+
+http://www.da-sense.de/test/api.php?result= ….
+
+
+{"device":"357194040202988","series":[{"timestamp":1327825923746,"visibility":1,"values":[{"tags":[{"value":"44100","key":"measurement:samples:count"}],"timestamp":1327825925143,"speed":0,"altitude":0,"value":213.6781463623047,"provider":"network","longitude":8.6091076,"latitude":49.676669,"accuracy":39},{"tags":[{"value":"220500","key":"measurement:samples:count"}],"timestamp":1327825930152,"speed":0,"altitude":0,"value":139.90003967285156,"provider":"network","longitude":8.6091076,"latitude":49.676669,"accuracy":39} ,"name":"testparser22"}],"user":94,"measurementType":1}

ws2011/BP/Json von Julien/new json.txt

@@ -0,0 +1,100 @@
+1.) Folgendes wird übermittelt beim Start/Login/Änderungen von Optionen (z.B der Kalibrierung)
+
+HTTP-Post-Parameter:
+	flag=deviceinfo
+	json=JSON-Daten
+
+Das JSON hat folgendes Format:
+
+{
+	“deviceType”: INT,		//(1: Smartphone 	| 2: Waspmote)
+	“deviceID”: INT,		//(Smartphone: IMEI 	| Waspmote: MAC-Adresse)	
+	“deviceManufactor”: STRING,
+	“deviceModel”: STRING,
+
+	“deviceName”: STRING		//(“Benutzerspezifischer Name,
+					//kann selbst vergeben werden, z.B Julien Handy”)	
+
+	“sensors”: [
+		“type”: INT,		//(1:Audio | 2: CO2 | 3: CO | 4: °C)
+		“sensorAttributes”: [	//Sensorattribute als Key-Value-Pair
+			“key”: STRING,
+			“value”: STRING
+		]
+		
+	]
+  
+}
+
+
+
+
+
+2.) Neues JSON-Format für das Senden der Daten.
+
+HTTP-Post-Parameter (wie gehabt)
+	flag=input
+	source=smartphone bzw. waspmote
+	json=JSON-Daten
+
+
+{
+  “device”: STRING,		//(Smartphone IMEI | Waspmote MAC-Adresse)
+  “measurementType”: INT, 	//(1:Audio | 2: CO2 | 3: CO | 4: °C)
+  “user”: INT,			//(dasense User-ID)
+
+	“series”: [
+		“name": STRING,,
+		“visibility”:INT,
+		"timestamp”:LONG,
+
+	
+		  “values”: [
+			“timestamp”: LONG,
+			“value”: FLOAT,
+			“latitude”: FLOAT,
+			“longitude”: FLOAT,
+			“altitude”: FLOAT,
+			“accuracy”: FLOAT,
+			"speed": FLOAT bzw. NULL,
+			“provider”: STRING,	
+	
+				“tags”: [
+ 	  			“key”: STRING,
+	  			“value”: STRING,
+				]
+  			]
+   ]
+}
+
+
+Bitte folgende Klammerung einhalten:
+
+zu 2.) ein Beispiel:
+
+{	"device":"APITEST,
+	"measurementType":1,
+	"user":20,
+		"series": [ {	"name":"testseries",
+				"visibility":0,
+				"timestamp":1 ,
+					"values": [ { 	"timestamp":1,
+							"value":52.25234634,
+							"longitude":0,
+							"latitude":0,
+							"altitude":0,
+							"accuracy":0,
+							"speed":null,
+							"provider":"GPS",
+								"tags": [ { 	"key": 1,
+										"value":35 } ] 
+						} ]
+				 } ]
+ }
+
+ {"sensors":[{"type":1, “sensorAttributes”:[]}],"deviceModel":"Nexus One","deviceName":"noisemap smartphone","deviceManufactor":"google","deviceType":1,"deviceID":8970601655653731891}
+
+
+
+ {"sensors":[{"type":1}],"deviceModel":"Nexus One","deviceName":"noisemap smartphone","deviceManufactor":"google","deviceType":1,"deviceID":8970601655653731889}
+

ws2011/BP/Latex/befehle dave.txt

@@ -0,0 +1,20 @@
+\documentclass[article,colorback,accentcolor=tud1a]{tudreport}
+\usepackage[utf8]{inputenc}
+\usepackage[ngerman]{babel}
+\usepackage{enumitem}
+\usepackage[
+    colorlinks,
+    pdfproducer={},
+    pdfauthor={David Kaufmann},
+    pdfsubject={HMS Mitschrift SS11},
+    pdftitle={HMS Mitschrift SS11},
+    pdfkeywords={HMS, Hardware, Modellierung, Sprache, TU Darmstadt, TUD, SS11, Mitschrift, Hardwaremodellierungssprachen, Sommersemester},
+    pdfpagelabels,
+    pdfstartview = FitH,
+    bookmarksopen = true,
+    bookmarksnumbered = true,
+    linkcolor = black,
+    plainpages = false,
+    hypertexnames = false,
+    citecolor = black]
+{hyperref}

ws2011/BP/QS-Dokument/.gitignore

@@ -0,0 +1,2 @@
+
+QS

ws2011/BP/QS-Dokument/Anforderungen-an-das-QS.txt

@@ -0,0 +1,50 @@
+Stichpunkte zur Vorlesung "Anforderungen an das QS-Dokument" vom 23.12.2011:
+
+
+- Was wollen wir sichern? Was ist das Ziel, wie definieren wir es, und wie wird es gesichert?
+- Schlecht wenn Ziele nicht eingehalten werden können. Falls externen Abhängigkeiten dazu beitragen, dass gesetzte Ziele nicht eingehalten werden können, so kann man dies im Anhang aufführen -> Kein Problem! Prinzipiell müssen die Qualitätsziele jedoch erreichbar sein.
+- Qualitätsziele, die für das Projekt nicht relevant sind und Maßnahmen, die nicht durchgeführt werden, gehören nicht in das Dokument
+- Benutzbarkeit, Benutzerstudie: Schlecht, dass wir am Ende des Projektes eine Benutzerstudie durchführen. Doof, dass am Ende keine Zeit mehr ist, um auf Feedback einzugehen. Es muss also genug Zeit sein, um die Ergebnisse in das Projekt einfließen zu lassen (ca 4 Wochen vor Ende des Projekts) die Benutzerstudie durchführen.
+- WER (auch Tool) macht WAS wann und WIE reagieren wir auf Probleme??? Namen und Zeitraum nennen!!
+- Dokument im TUD Design mit maximal 10 Seiten. Deckblatt, Glossar, Literaturverzeichnis, Versionshistorie und Anhang sind nicht in den 10 Seiten enthalten. Als normaler Fließtext können auch 4 oder 5 Seiten reichen. 10 Seiten ist das absolute Maximum!!
+- Ausarbeitung der Tests bzw. Benutzerstudie gehört in den Anhang. Auch der Fragebogen im Anhang?!?!
+- Beschreiben Sie nicht, was Benutzbarkeit ist bzw. was Qualitätssicherung ist!!!!! Stabilität soll jedoch beschrieben werden.
+- Deckblatt: Qualitätssicherungsdokument nur in klein, Gruppennummer, Kontaktadressen (kann auch auf nächster Seite kommen), Dateum/Version.
+- Kurze Einführung in das Projekt -> Passt !
+- Stellen Sie einem unbeteiligtem Dritten folgende Fragen: Welches sind die zentralen Qualitätsziele des Projekts? Warum sind dies die zentralen Ziele? … (mehr Fragen auf den Folien)
+- Qualitätsmerkmal ist kein Ziel. 
+- ISO 9000 : Sicherung der Prozessqualität (tendenziell eher schwieriger)
+
+Ergebnisse aus den aufgezeigten Beispielen:
+- Ein Kapitel hat immer zwei Unterkapitel und nicht nur eins wie in Einleitung -> Das Projekt!
+- Anwendung der deutschen Rechtschreibung (Bindestriche etc.)
+- Eine Evaluation kann die Benutzerfreundlichkeit nicht sicherstellen, sie kann nur Grundlage für anschließende Maßnahmen sein.
+- Einleitung: In diesem Dokument werden…. zu unspezifisch für das aktuelle Projekt! -> weglassen!
+- Jeder Satz soll Projektspezifisch sein!
+- Alle im deutschen geläufigen Wörter auch in deutsch schreiben
+- nicht "wir wollen", "es sollte getan werden…" -> "Wir sichern die Qualität des Codes auf die folgende Art und Weise…."
+- Kommasetzung
+- Codequalität: Zitat kann drin bleiben. "des Projekt"
+- Qualitätswerkzeuge: Steigern unsere Produktivität, dienen jedoch nicht der Qualitätssicherheit. Bsp.: Fehler in der Syntax findet der Compiler, nicht nur Netbeans. Nicht einfach alle Werkzeuge aufzählen.
+- 3.3.2 Fragebogen: Was ist Anfang März? "verschiedensten" gibt es nicht. "nutzerspezifische Anforderungen", was ist damit gemeint? Warum darf der Nutzer die Anforderungen erstellen?
+- 3.3.3 Analyse: Projekt ist viel zu kurz, um eine Logfile-Analyse durchzuführen.
+- 3.4 Codequailtät: "…werden dem Ziel … " "Der Code soll…."  wo ist der Zusammenhang?
+- manuelle Überprüfung: Was heisst Aussagekräftig?
+
+
+Stichpunkte von Treffen mit Dominik:
+- 2.1, 2.2 Kopie von ISO rausmachen. "Wir definieren nach ISO"!
+
+Codequalität: In der OpenSource Szene sind folgende Codestandards etabliert…..
+
+Strukturierung: einfachstes Format: grobe, große Ziele. Kann auf eine halbe Seite passen. Rest sind Maßnahmen. Also Aufteilung in zwei Kapitel möglich.
+
+Abgabetermin: Ende Januar (24.01)! Anhang dann Ende März!
+
+
+
+
+
+
+
+

ws2011/BP/QS-Dokument/QS-Anhang.txt

@@ -0,0 +1,5 @@
+Die von uns angek"undigte Benutzerstudie konnte nicht durchgef"uhrt werden, da unser Aufraggeber die Zeit f"ur das Refactoring zu gering abgesch"atzt hat, als es tats"achlich in Anspruch genommen hat. Weil das Refactoring eine h"ohere Zeit in Anspruch genommen hat als gedacht, konnten wir keine Visualisierung der Webseite angehen, was in der Benutzerstudie zum Einsatz kommen sollte.
+
+Hinzu kommt, im Hinblick auf die Sicherheit, die "Uberf"uhrung von SQL-Statements aus dem Quellcode in Propel. Die Umstellung brachte einige unvorhersehbare Probleme mit sich. Zum einen kann Propel nicht mit Unterstrichen in den Namen der Datenbanktabellen umgehen, zum Anderen hat sich herausgestellt, dass sich dynamische SQL-Queries nicht so leicht durchf"uhren lassen. Dies f"uhrte zu Stundenlangen Auseinandersetzungen mit den Entwicklern von Propel.
+
+Da wir mit der Entwicklungsumgebung Netbeans gearbeitet haben, hatten wir die M"oglichkeit, unsere "Anderungen am Quellcode direkt im Webbrowser zu testen. Netbeans erlaubt das Hochladen des Quellcodes, unmittelbar nach einer "Anderung, auf den Server, so dass es direkt testbereit ist. Dadurch konnten wir sehen, ob unsere "Anderungen wirksam waren. Im Hinblick auf die Fehlerbehebung haben wir in unserem Repository ein issues-Dokument angelegt, in die wir alle gesichteten Fehler aufgenommen haben. Diese wurden dann von uns zum Beheben herangezogen.

ws2011/BP/QS-Dokument/QS-Kommentare-Dominik-17-12-11.txt

@@ -0,0 +1,56 @@
+> 1.1.enumeration
+Die Formulierung mit Infinitiven passt wahrscheinlich besser. ("Umstrukturierung der Datenbank für neue Sensortypen")
+
+> 1.1.
+> Da das Projekt auf insgesamt drei Gruppen aufgeteilt wurde, werden in diesem Dokument ausschließlich die Bereiche der Gruppe 1b behandelt.
+Passt irgendwie nicht so ganz mangels kausalem Zusammenhang. Vielleicht eher: "Das Projekt wurde auf insgesamt drei Gruppen aufgeteilt. In diesem Dokument werden ausschließlich die Bereiche der Gruppe 1b behandelt."
+
+> 2.
+Schreibt nicht so häufig, was ihr da beschreibt, sondern macht es einfach. Eher weniger "In diesem Kapitel soll...". Das ist zwar beliebter Stil in der wissenschaftlichen Schreibpraxis, soll aber, soweit ich weiß, bei uns eher vermieden werden.
+Funktionalität wird also vom Auftraggeber gefordert. Benutzbarkeit nicht? Habt ihr die euch also ausgedacht? Vermeidet diesen Eindruck, der momentan noch entsteht.
+Die Codequalität taucht da noch überhaupt nicht auf, weiter unten dann allerdings als Kapitel, was den Leser wundert.
+
+> 2.1. und 2.2. Definitionen nach ISO.
+Eine löbliche Verwendung von Referenzen. Momentan stehen die aber bloß einfach so da. Macht etwas mit diesen Informationen, erläutert, was ihr für die Angemessenheit, Richtigkeit, Sicherheit, Verständlichkeit, Erlernbarkeit, et cetera, tut, oder lasst sie weg. 
+
+> 2.3. Zitat
+Keine Ahnung, ob zitieren gut ist. Lassen wir es drinnen, geben es am 18. ab und warten gespannt, was die Projektbetreuung spricht. Mir persönlich gefällt es, man müsste es thematisch bloß noch mehr an den Inhalt anketten. Beispiel:
+"»Any fool can write code that a computer can understand. Good programmers write code that humans can understand.« [FBBOR+1999]. Der Quellcode, welcher im Rahmen dieses Projektes erstellt wird, soll offen für Erweiterungen sein und wird von weiteren Gruppen und Arbeiten genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind."
+Ihr könntet auch bemerken, dass euer Code schon während der Entwicklung im Laufe des Projektes von anderen, parallel arbeitenden Gruppen verwendet wird. Das erhöht die Wichtigkeit dieses Zieles weiter.
+
+> 2.3.enumeration
+Alles tolle Sachen, jedoch: Wie dienen sie den Qualitätszielen? Alle Aufzählungspunkte sind Maßnahmen zur Sicherung der Codequalität und keine Selbstzwecke.
+
+> 3.1.
+Hier ebenso: tolle Tools, aber was bringt es denn für Funktionalität und Benutzbarkeit, dass ihr Fehler etwa gerade mit FireBug meldet, und nicht mit Post-Its?
+
+> 3.2.
+Wieso fiel die Auswahl gerade darauf?
+Wann werden diese Tests durchgeführt?
+Wie sind sie aufgebaut?
+Was passiert, wenn sie fehlschlagen?
+Welche Metrik stellt einen Fehler fest?
+Wer ist dafür verantwortlich?
+
+> 3.3.
+Tippfehler: "deshalb" ohne "des", quasi nicht ganz sondern nur "halb".
+Sonst schön.
+
+> 3.3.1.
+Viellicht noch ein Paar Worte zu den Metriken. Auf was wollt ihr beim Beobachten achten?
+
+> 3.3.2.
+> Der folgende Fragebogen kann sich im Laufe des Projekts ändern. Es können neue Fragen hinzukommen oder aber bereits
+> vorhandene geändert bzw. herausgenommen werden.
+Prima. Wann? Wieso? Durch wen? Wie?
+Was liegt dem Fragebogen zugrunde? Wieso sieht der gerade so aus? Wer wertet den aus? Wann findet die Studie statt?
+
+> 3.3.3. Datenschutz
+Gut!
+Wieso GoogleAnalytics?
+
+> 4.
+Dampft das besser ein, indem ihr die Seitenumbrüche herausnehmt. Das ist zwar gut gemeint und gefällt mir so auch besser, ich weiß allerdings nicht, ob das Dokument zur Lektüre gedruckt wird, möglicherweise sogar mehrfach. Dann könnte die Zahl leerer Seiten sauer aufstoßen.
+
+> 5.
+Anders herum. Das früheste Datum steht ganz oben.

ws2011/BP/QS-Dokument/QS-VV-2.txt

@@ -0,0 +1,61 @@
+2.3 "Erweiterbarkeit"
+	
+	-> "Damit das Projekt in Zukunft in der Open-Source-Szene anerkannt wird, werden die Open 			Standards nach [OSI] angewendet. Hierbei duerfen keine kommerziellen Tools im Projekt 	
+		eingesetzt werden"
+
+		ersetzen durch
+
+	   "Die Open Standards werden nach [OSI] angewendet. Dieser schliesst den Einsatz kommerzieller 
+		Tools im Projekt aus." [Anmerkung: schliesst schreibt man mit scharfem S!]
+
+-> leicht abgeändert eingefügt!
+		
+3.1 "Funktionalitaet"
+
+	-> "Richtigkeit":
+
+			
+	-> "Interoperabilitaet":
+	
+		   "In jedem Browser werden exakt dieselben Benutzereingaben ausgefuehrt. Die jeweiligen
+		    Ausgaben koennen somit direkt verglichen werden."
+		    
+		    ersetzen durch:
+		    
+		   "Jeder Browser wird mit den selben Benutzereingaben ausgefuehrt. Die jeweiligen
+		    Ausgaben erlauben einen direkten Vergleich."
+		   -------------------
+		   "Zudem erhalten wir durch die Auswertung des Fragenbogens, der im Rahmen der
+		    Benutzerstudie an Probanden ausgegeben wird, eine Rueckmeldung ueber eventuell
+		    auftretende Fehler der Visualisierung."
+		    
+		    ersetzen durch:
+		    
+		   "Ausserdem werden, im Rahmen der Benutzerstudie, Frageboegen an Testpersonen [oder 	
+			Probanden] ausgegeben. Die Auswertung dieser Frageboegen ermoeglicht es uns, 
+			Rueckschluesse auf eventuell auftretende Fehler in der Visiualisierung zu ziehen und zu 
+			beseitigen."
+			
+3.2 "Benutzbarkeit"
+
+			Mein Vorschlag:
+
+		   "In der ersten Maerzwoche 2012 fuehren wir eine Benutzerstudie durch, um das 
+			Qualitaetsmerkmal der Benutzbarkeit des Webinterfaces zu gewaehrleisten. Hierzu bekommen 				frewillige Probanden einen Fragebogen ausgeteilt, mit dem sie die Ausgestaltung und 	
+			Bedienung der Webseite bewerten. Die Evaluierung der Ergebnisse gestattet die Erkennung 			und Beseitigung von Problemen im Webinterface. Ausserdem wird festgestellt, ob der 
+			Benutzer in einem angemessenen Zeitrahmen die gewuenschten Inhalte finden und abrufen 
+			kann. Fuer die Benutzerstudie kommen Menschen unterschiedlichen Alters und mit 
+			unterschiedlicher Interneterfahrung in Frage. Dies steigert die Aussagekraft der Studie."
+			
+3.2.1 "Beobachtung"
+
+		   "Die Beobachtung des Probanden waehrend der Bedienung der Webseite, stellt die einfachste 
+			Methode dar, um auftretende Probleme fruehzeitig zu erkennen. Hierbei nimmt der 
+			Entwickler die Position des Beobachters ein und fuehrt Protokoll. Dem Probanden stehen 	
+			fuenf Minuten zur Verfuegung, um sich mit der Benutzeroberflaeche vertraut zu machen. 
+			Anschliessend [Anmerkung: Anschliessend mit scharfem S!] werden Aufgaben gestellt, die 
+			er loesen muss. Waehrend der Beobachtung achtet der Entwickler auf folgende Punkte:"
+			
+3.2.2 "Fragebogen"
+
+		   Wuerde ich gerne Morgen nochmal besprechen

ws2011/BP/QS-Dokument/QS-Verbesserungen_von_michael.txt

@@ -0,0 +1,44 @@
+QS-Dokument - Verbesserungsvorschläge:
+
+-> Bei jeder Maßnahme muss aufgeführt werden: 	
+	- Was wird gemacht? 
+	- Wie wird getestet? 
+	- Wann wird es gemacht? 
+	- Wer macht es? 
+	- Und wie wird im Fehlerfall reagiert?
+
+
+3.1 Funktionalität:
+
+Richtigkeit (Datenbankinteraktionen und Darstellung der Visualisierung):
+
+
+
+
+Sicherheit:
+
+
+
+Interoperabilität:
+
+
+
+
+------------------------------------------------------------------------------------------------------------------
+
+3.2 Benutzbarkeit:	
+
+
+3.2.1 Beobachtung:
+
+
+3.2.2 Fragebogen:
+
+------------------------------------------------------------------------------------------------------------------
+
+3.3: Codequalität:
+
+
+
+
+

ws2011/BP/QS-Dokument/QS_Inhalte_Stichpunkte.txt

@@ -0,0 +1,7 @@
+- 2.1, 2.2 Kopie von ISO rausmachen. "Wir definieren nach ISO"!
+
+Codequalität: In der OpenSource Szene sind folgende Codestandards etabliert…..
+
+Strukturierung: einfachstes Format: grobe, große Ziele. Kann auf eine halbe Seite passen. Rest sind Maßnahmen. Also Aufteilung in zwei Kapitel möglich.
+
+Abgabetermin: Ende Januar (24.01)! Anhang dann Ende März!

ws2011/BP/QS-Dokument/code-standart.txt

@@ -0,0 +1,13 @@
+Ich habe hier zwei Vorschläge bezüglich des vewendeten codesytles:
+
+Von Pear:
+
+  Pear ist "die standart Library" für php.
+
+  http://pear.php.net/manual/en/standards.php
+
+
+  Hier ein etwas einfacher dokumentierter Ansatz:
+  (Mein Favorit, da einfacher zu lesen)
+  
+  http://www.buxaprojects.com/de/php_coding_guidelines.htm

ws2011/BP/QS-Dokument/erweiterbarkeit.txt

@@ -0,0 +1,155 @@
+Auf den folgenden Seiten sind die einzelnen teaminternen Codereviews aufgelistet. Jedes einzelne Treffen wird in einer eigenen Tabelle gef"uhrt.
+
+\paragraph{Teaminterner Codereview - 21.11.2011}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 1 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & Einlesen in den Code \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - Code sehr un"ubersichtlich \newline - fehlende Kommentare \newline - doppelte Klassen auf mehrere Ordner verteilt \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & der Alle Dateien innerhalb des Projekts \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Ausfindig machen, welche Klassen weggelassen werden k"onnen \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Batu, Gebhardt, Murati, Scholz \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 01.12.2011}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 2 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & Aufr"aumen des Codes \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & Das Projekt beinhaltet nicht verwendete Klassen \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien innerhalb der Ordner Classes und Templates \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Verbesserung der Projektstruktur durch entfernen von nicht verwendeten Klassen \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Batu, Gebhardt, Murati, Scholz \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 15.12.2011}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 3 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & SQL-Abfragen und JSON Format \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - Code enth"alt SQL-Abfragen, die mit Hilfe von Propel ersetzt werden sollen \newline - JSON Format entspricht nicht dem neuen Datenformat \newline - in den Templates sind HTML-, JavaScript- und PHP-Code nicht getrennt \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien innerhalb der Ordner Templates und Classes \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & SQL-Abfragen aus den betroffenen Dateien rausschreiben (Aufgabe 1) \newline rausgeschriebene SQL-Abfragen mit Propel realisieren (Aufgabe 2) \newline JSON Format anpassen (Aufgabe 3) \newline Strukturieren des Codes in den Templates mit Hilfe von Platzhaltern (Aufgabe 4) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Batu und Murati \newline Aufgabe 2: Gebhardt \newline Aufgabe 3: Scholz \newline Aufgabe 4: Batu und Murati \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 09.01.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 4 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & JSON, View \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - Umsetzung des neuen JSON Format noch nicht abgeschlossen \newline - View kommt mit den Platzhaltern in den Template Dateien nicht zurecht \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien innerhalb der Ordner Templates, view und json \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & neues JSON Format umsetzen (Aufgabe 1) \newline neue View schreiben, die mit Platzhaltern umgehen kann (Aufgabe 2) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Scholz \newline Aufgabe 2: Batu, Gebhardt, Murati \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 23.01.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 5 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & API \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & API ist mit der neuen Datenbank nicht kompatibel \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien im Ordner api \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & API an die neue Datenbankstruktur anpassen (Aufgabe 1) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Batu, Gebhardt, Murati, Scholz \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 07.02.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 6 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & API, Propel und Datenbank, Benutzerbereich \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - Propel kann mit den Tabellennamen nicht umgehen \newline - der Benutzerbereich enth“alt Fehler (Daten editieren und l"oschen) \newline - die Heatmap wird nicht geclustert \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien innerhalb der Ordner propel, user und cluster \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Tabellennamen in der Datenbank um"andern und Propel neu generieren (Aufgabe 1) \newline Fehler im Benutzerbereich beseitigen (Aufgabe 2) \newline Heatmap geclustert anzeigen (Aufgabe 3) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Gebhardt und Scholz \newline Aufgabe 2: Batu und Murati \newline Aufgabe 3: Batu, Murati und Scholz \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+
+\paragraph{Teaminterner Codereview - 21.02.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 7 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & Fehler auf der Webseite \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - Sensor-Diagramme werden nicht mehr angezeigt \newline - Bedienung des Isolationsmodus nicht benutzerfreundlich \newline - nicht alle Pfade in den Templates sind korrekt gesetzt \newline - es sind nicht genutzte Codeteile vorhanden \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & Alle Dateien innerhalb des Projekts \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Sensor-Diagramme wieder einblenden (Aufgabe 1) \newline Isolationsmodus leichter bedienbar machen (Aufgabe 2) \newline Pfade in den Templates anpassen (Aufgabe 3) \newline Code strukturieren (Aufgabe 4) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Batu und Murati \newline Aufgabe 2: Scholz \newline Aufgabe 3: Murati \newline Aufgabe 4: Gebhardt \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 07.03.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 8 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & Fehler auf der Webseite \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & Filteroption f"ur die "offentlichen Daten mit Propel nicht ohne weiteres m"oglich (Propel klammert die Ausdr"ucke innerhalb eines SQL-Statements selbstst"andig) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & get_markers.php und QuerySelect.php \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Umsetzung der Filterm"oglichkeiten mit Propel (Aufgabe 1) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & Aufgabe 1: Scholz \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage
+
+\paragraph{Teaminterner Codereview - 27.03.2012}
+\vspace{1cm}
+\begin{tabbing}
+\begin{tabular}{||p{5.4cm}||p{11cm}||}
+\hline \rule[-2ex]{0pt}{5.5ex} Reviewnummer & 9 \\
+\hline \rule[-2ex]{0pt}{5.5ex} Thema & Abschlussreview \\
+\hline \rule[-2ex]{0pt}{5.5ex} Teilnehmer & Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz \\
+\hline \rule[-2ex]{0pt}{5.5ex} Erkannte Probleme & - abfrage sensibler Daten mit Hilfe der Filter in der API \newline - "Andern des Zeitfilters hat keine Auswirkungen auf die Ergebnisse der Heatmap \\
+\hline \rule[-2ex]{0pt}{5.5ex} Betroffene Datei & api.php und propel \\
+\hline \rule[-2ex]{0pt}{5.5ex} Aufgabe & Abschalten der Filter in der API (Aufgabe 1) \newline Kooperation des Zeitfilters mit der Heatmap sicherstellen (Aufgabe 2) \\
+\hline \rule[-2ex]{0pt}{5.5ex} Zust"andige Person & - Aufgabe 1 und 2: Gebhardt \\
+\hline
+\hline
+\end{tabular}
+\end{tabbing}
+\newpage

ws2011/BP/QS-Dokument/glossar_anlegen.txt

@@ -0,0 +1 @@
+Um das Glossar zu erstellen muss die .text-Datei einmal kompiliert, dann mittels Konsole und "makeglossaries Qs-Dokument" die Glossardateien erstellt und anschließend die .text-Datei nochmals kompiliert werden.

ws2011/BP/User Stories/Projekttagebuch.tex

@@ -0,0 +1,105 @@
+\documentclass[article, colorback,accentcolor=tud4a]{tudreport}
+\usepackage[latin9]{inputenc} %unter Linux muss latin9 durch utf8 ersetzt werden!!
+\usepackage[ngerman]{babel}
+\usepackage{enumitem}
+\usepackage{lineno}
+\usepackage{wasysym}
+\usepackage{latexsym}
+%reihenfolge von "hyperref" und "glossaries" ist wichtig!!!! nicht ändern!
+\usepackage[pdftitle={Projekttagebuch}]{hyperref}
+
+
+
+
+\begin{document}
+
+\title{Thema: da-sense\\
+Gruppe 1b}
+
+\subtitle{Projekttagebuch zum Bachelor-Praktikum im Wintersemester 2011/2012}
+
+\subsubtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
+Gruppe 1b: Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz\\
+Teamleiter: Dominik Fischer}
+
+\author{Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz}
+\maketitle
+
+\noindent
+Im Rahmen des Bachelor-Praktikums sind bei der Umsetzung des Projekts einige Probleme aufgetreten. Im Folgenden sind Zeitpunkt und eine kurze Beschreibung für jedes eingetretene Ereignis aufgelistet. \\ \\
+
+\noindent
+\textbf{Problem 1:} \\ \\
+Datum: \hspace{25mm} 27.01.2012 \\
+Problembeschreibung: \hspace{3mm} Datenbanktabellen haben keine Fremdschl"ussel \\
+Verantwortlicher: \hspace{10.5mm} Ulf Gebhardt \\
+
+\noindent
+Während der Umstellung des Projekts auf Propel sind einige Probleme hinsichtlich der Datenbank aufgetreten. Die API erfordert, dass viele Tabellen zwecks Datenabruf gejoint werden müssen. Der Join-Vorgang der Tabellen wurde jedoch durch die Tatsache der fehlenden Fremdschlüssel erschwert, sodass wir uns gezwungen sahen, die Datenbank-Tabellen in der neuen Datenbank mit Fremdschlüsseln zu versehen. Diese Maßnahme hat die Verwendung der API-Abfragen erst möglich gemacht. \\ \\
+
+\noindent
+\textbf{Problem 2:} \\ \\
+Datum: \hspace{25mm} 08.02.2012 \\
+Problembeschreibung: \hspace{3mm} Propel kann mit Unterstrichen und Umlauten nicht umgehen \\
+Verantwortlicher: \hspace{10.5mm} Michael Scholz \\
+
+\noindent
+Dieses Problem ist erst in einer späteren Phase des Projekts aufgetreten. Bei der Verwendung der Datenbank-Tabellen ist uns aufgefallen, dass Propel insbesondere auf die Namen der verfügbaren Tabellen achtet. Damit das Projekt mit Propel umgesetzt werden kann, muss darauf geachtet werden, dass sich keine Unterstriche oder Umlaute in Tabellennamen befinden. Für die Fehlerermittlung haben wir viel Zeit aufgewendet und wegen mangelnder Dokumentation des verwendeten Frameworks den Kontakt zu den Entwicklern suchen müssen. \\ \\
+
+\noindent
+\textbf{Problem 3:} \\ \\
+Datum: \hspace{25mm} 01.02.2012 \\
+Problembeschreibung: \hspace{3mm} Student hat Ressourcen blockiert, sodass diese nicht von uns genutzt werden konnten \\
+Verantwortlicher: \hspace{10.5mm} Lulzim Murati \\
+
+\noindent
+Ein weiterer Student, der im Rahmen seiner Bachelor-Arbeit eine Benutzerstudie zum da-sense Projekt erstellt hat, hat einen Teil der gemeinsam verwendeten Ressourcen für einen gewissen Zeitraum belegt, sodass wir diese nicht nutzen konnten. Hierbei mussten wir geplante Änderungen verschieben und uns stattdessen anderen Aufgaben zuwenden. \\ \\
+
+\noindent
+\textbf{Problem 4:} \\ \\
+Datum: \hspace{25mm} 07.12.2011 \\
+Problembeschreibung: \hspace{3mm} Code nicht dokumentiert. Doppelte Klassen. \\
+Verantwortlicher: \hspace{10.5mm} Lulzim Murati \\
+
+\noindent
+Beim Einstieg in das Projekt haben wir uns aufgrund der gegebenen Projektstruktur sehr schwer getan. Der bereitgestellte Code war sehr dünn dokumentiert und wies so gut wie keine Kommentare innerhalb der Dateien auf. Weiterhin sind im Projekt mehrere Klassen doppelt vorgekommen, die jedoch auf verschiedene Ordner aufgeteilt waren. Wir haben viel Zeit damit aufwenden müssen, herauszufinden welche dieser doppelten Klassen verwendet werden und wie die einzelnen Klassen in Verbindung zueinander stehen. \\ \\
+
+\newpage
+
+\noindent
+\textbf{Problem 5:} \\ \\
+Datum: \hspace{25mm} 25.01.2012 \\
+Problembeschreibung: \hspace{3mm} da-sense-App enthielt Bugs \\
+Verantwortlicher: \hspace{10.5mm} Michael Scholz \\
+
+\noindent
+Unser Auftraggeber hat uns ein Android-Smartphone zur Verfügung gestellt, mit dem wir unseren JSON-Parser testen konnten. Bei der Verwendung des Smartephones mit der da-sense-App haben wir festgestellt, dass diese erhebliche Fehler aufwies. Diese ist permanent abgestürzt und hat das Testen unserer Module verhindert. Wir mussten uns mit dem Entwickler der App in Verbindung setzen und eine Rücksprache f"ur die Fehlerbehebung führen. \\ \\
+
+\noindent
+\textbf{Problem 6:} \\ \\
+Datum: \hspace{25mm} 08.02.2012 \\
+Problembeschreibung: \hspace{3mm} Propel nicht dokumentiert \\
+Verantwortlicher: \hspace{10.5mm} Murat Batu \\
+
+\noindent
+Das ORM-Framework Propel ist nicht ausreichend dokumentiert, sodass im Falle eines aufgetretenen Problems der Support-Chat als einzige Alternative in Anspruch genommen werden musste. Wir haben einen Teil unserer Zeit mit der Kontaktaufnahme zu den Entwicklern aufwenden müssen. Die Entwickler waren gut erreichbar und haben kompetente Hilfe geleistet. \\ \\
+
+\noindent
+\textbf{Problem 7:} \\ \\
+Datum: \hspace{25mm} 15.12.2011 \\
+Problembeschreibung: \hspace{3mm} MVC-Modell nicht richtig umgesetzt \\
+Verantwortlicher: \hspace{10.5mm} Ulf Gebhardt \\
+
+\noindent
+Die Vorgängergruppe hatte das MVC-Modell nicht konsequent umgesetzt. Gegenüber einer beträchtlichen Anzahl an Controllern hat jedoch keine View existiert, sodass wir gezwungen waren, notwendige Bausteine beizusteuern, um dieses Modell zu vervollständigen. Dies ist im Rahmen des Code-Refactorings geschehen. Letzteres hat sehr viel Zeit in Anspruch genommen, da zwecks Erweiterbarkeit ein gewisser Teil des Projekts neu geschrieben werden musste. \\ \\
+
+\noindent
+\textbf{Problem 8:} \\ \\
+Datum: \hspace{25mm} 01.03.2012 \\
+Problembeschreibung: \hspace{3mm} Ausfall der Benutzerstudie \\
+Verantwortlicher: \hspace{10.5mm} Murat Batu \\
+
+\noindent
+Die Gründe hierfür waren unter anderem die sich ändernden Anforderungen im agilen Softwareprozess. Es sind die Probleme 1, 2 und 6 aufgetreten. Diese haben sehr viel Zeit in Anspruch genommen, sodass die Benutzerstudie letztendlich nicht mehr durchgef"uhrt werden konnte.
+
+\end{document}