This is a read only archive of pad.okfn.org. See the
shutdown announcement
for details.
BCG14samstag-appdevcamp
Barcamp Graz 2014 - Tag2 - Samstag, 12. April 2014
Dieses Pad kann von allen benutzt werden, um die einzelnen Sessions beim Barcamp Graz mitzudokumentieren.
Es würde uns freuen, wenn ihr davon gebraucht macht und möglichst ausführlich in den Sessions mitschreibt!
Seien es Links, Kommentare, Statements, wichtige Notizen, Zusammenfassungen oder was euch sonst sinnvoll erscheint.
================Appdevcamp================
Session 1: 12 Punkte zum erfolgreichen IT-Projekt - Vortragende/r
Phase 1
1. Punkt: Vision
- klar formuliert
- finden von Netzwerk
2. Punkt: Zielgruppe
- eingrenzen,
- mit den Leuten reden, die Vision testen
- Feedback holen
- Wie? zb. Auf die Uni gehen, Flyer verteilen mit RedBull Dose
3. Punkt: Return Of Investment
- Auftraggeber will Geld verdienen mit einem beauftragten IT-Projekt
- Croudfunding verbindet Punkt 2 mit Punkt 3
- Kosten/Nutzen Rechnung
4. Punkt: Finanzierung
- Finanzierungsplan erstellen, wann ist wieviel Geld nötig, wann ist zu zahlen
- Sind Kunden zahlungsfähig?
- Sicherstellen dass bezahlt wird!
- Rechtberatung einholen
Phase 2
5. Punkt: Projektmanagement
- Kunde braucht Meilensteine, Verantwortlichkeiten, Ansprechpartner
- Dem Kunden kommunizieren, wie ich arbeite
6. Punkt: Design
- It's how it works (Steve Jobs)
- Festhalten wieviele Lieferungen des Produkts es gibt, wieviele Iterationen
- Mit dem Kunden in Kontakt bleiben
- Design lässt sich nicht einem Sprint abliefern
- Design entwerfen, zum Kunden schicken, abnehmen lassen >> dann implementieren
7. Punkt: Entwicklung
- Irgendwas wird funktional mehr
- Funktionalitäten in Arbeitspakete runterbrechen, priorisieren
- zb. Webshop: wichtigste Funktionen: Bezahlfunktion, Check cart, also auch zuerst implementieren
- business value vs. system critical risk
- im Meilensteinplan festhalten, jeden Schritt kommunizieren, und zwar bevor man damit anfängt
8. Punkt: Deployment
- schauen, dass was bei mir am Entwicklungssystem läuft, auch am Deployment System läuft
- Drei Schritte: Entwicklung > Staging > Live
- Staging: ein system, wo der Kunde hinschauen kann und das genau dem entspricht, wie's live läuft
- Und zu beachten: Weiterentwicklungen von live wieder zu Entwicklung, zb. Zusatzfunktion, aber schon unter Existenz von live daten
Phase 3
9. Punkt: Role-Out
- Internationalisierung, Regionale Unterschiede
- App für die ganze Welt? Die Welt funktioniert nicht überall gleich. Gehört auch zum Thema Zielgruppe, etc. und die meisten vorigen Punkte
10. Punkt: Sales
- Marketingkampagne
- Aufmerksammachen, an den Kunden bringen
- Viel höheres Budget als Entwicklungsbudget
- Abgrenzen, ob man für Marketing als Entwickler zuständig ist!
11. Punkt: Support
- Kein Produkt funktioniert einwandfrei
- Es ist immer der Entwickler schuld, wenns keinen Support gibt
12. Punkt: Version 2
- Wenn ein Produkt erfolgreich ist, gibts automatische Nachahmer und Plagiate, billiger
- Version 2! Wir sind einfach besser. Damit man was nachlegen kann und die anderen abhängen kann. 20-30% vom Entwicklungsbudget
Session 2: Android-Automatisierung mit Tasker - Vortragende/r
Session 3: Sessiontitel - Vortragende/r
Session 4 Mobile und Machine Learning - Jörg Simon (Know Center)
Tools:
- WEKA (Android)
- Tool zum Ausprobieren/Testen/Kennenlernen von Machine Learning auf Android
- Daten können von WEKA-Desktop aufs Android-Smartphone übernommen werden
- Anwendungen:
- Stresserkennung durch physische Aktivitäten (ob man steht, geht, sitzt, liegt, fährt, ...) mit Accelerometer
- Soziale Interaktionen (mit wem und wie ich rede)
- Bluetoothgeräte in der Nähe
- Nähe??
- Hidden-Markov-Modelle (stromaufwendig)
- Semantic Place Detection
- Nicht wo man ist, sondern was das ist (z.B. Café, Beisl u.ä.)
- Algorithmen:
Jörg fragt uns, wofür wir Machine Learning verwenden würden.
- Kontexterkennung
- Problem: sehr allgemein, man bräuche für jede Situation aber einen eigenen Algorithmus
Supervised Learning
- riesiger Datensatz, um Overfitting zu vermeiden
Unsupervised Learning
- ??? (Name nicht verstanden)
- Clustert die Audiodaten
- Ambient Noise (Hintergrundgeräusche)
- Strukturiert nur Daten und nummeriert sie
- Nummern können später manuell mit Sinn versehen werden
Sound Sense Paper
http://dl.acm.org/citation.cfm?id=1555834
Nokia: Datensatz zu Orten auf 200 m Radius lokalisiert (im Internet verfügbar)
Reality-Mining-Datensatz vom MIT
- Wen habe ich wann angerufen usw.
Google Now:
- Gibt es vergleichbare offene Sachen?
- Wo ist mein Arbeitsplatz usw.
Ergebnis des Papers von Jörg Simon:
- Relativ leicht erkennbar: Wo ist Heimort und wo der Arbeitsplatz?
- Standort zu bestimmten Uhrzeiten wird an ein paar Tagen angeschaut → über 90 %ige Wahrscheinlichkeit, dass Zuhause u. Arbeit richtig identifiziert sind.
- Andere Dinge wie Public Transport, Restaurants usw. sind schwieriger.
Man könnte neben Standort und Beschleunigung ev. auch in die Kalendereinträge des Smartphones schauen.
Google fragt nachher noch den Nutzer, ob die erkannten Dinge wirklich stimmen.
Machine Learning = Statistics on Steroids
- heißt, es gibt immer Fälle, die nicht geschafft werden (z.B. Schichtarbeiter)
Modellproblem von Machine Learning aus den Kursen:
- Daten werden eingestuft in Klassen
- wenn man eine sehr hohe Trefferquote (?) wie z.B. 99,999% bekommt, hat man wahrscheinlich ein "Overfitting" = zu genaue Klassifizierung
- das will man nicht → Ausnahmen sollen Ausnahmen bleiben!
Das Trainieren auf mobilen Geräten ist nicht gut möglich, weil:
- zu hoher Strombedarf, zu hoher Rechenbedarf für Handy-Prozessor usw.
- man muss die Daten irgendwohin schicken (in die "Cloud")
Hinweis auf Framework:
Eine Bachelorarbeit:
Eine Art von freiwilliger Überwachung, z.B. für Patienten, die nach einer mediz. Behandlung überwachen lassen, wieviel sie zu Fuß gehen, damit der Arzt genaue Daten darüber bekommt.
Modelle:
- Na??? Bayes - war in dem Fall am erfolgreichsten.
- Decision Trees - ist sonst meistens am erfolgreichsten.
Trainingsphase:
- Testpersonen haben Buttons am Handy, die sie drücken, wenn sie gerade: gehen, liegen, Rollstuhl fahren, etwas anderes machen.
- Wichtig: Korrektur anbieten für das Labelling, weil Leute manchmal vergessen, den richtigen Button bei Zustandsänderung zu drücken.
Klassisches Beispiel für Overfitting: wenn man viel mehr Features als Daten hat
- z.B. wenn zufällig das WLAN während dem Trampolinspringen an ist, könnte das System glauben, dass das zusammengehört
- deswegen trainiert man normalerweise für einen bestimmten Kontext
- eig. ist so gut wie alles ein Kontext, d.h. "Kontext-Detection" wäre eig. "alles erkennen" und das geht nicht.
Bei den meisten Forschungspapers gibt es eigentlich zu wenige (z.B. 5-20 Leute) Daten.
Bsp.: Schrittzähler:
- sind ganz genau
- haben eine sehr gute Genauigkeit (Accuracy) für "normale" Menschen
- Aber: für ältere Personen ist die Empfindlichkeit zu niedrig
Wieviele Datensätze man braucht für eine genaue Klassifizierung?
- Ist stark abhängig davon, wie stark sich die zwei Klassen unterscheiden:
- z.B. Liegen und Trampolinspringen ist mit sehr wenig Daten sehr genau unterscheidbar
Geschätztes Datenvolumen z.B. für funf: weiß Jörg Simon nicht.
Session 5: Freedom Box - Vortragende/r
- Zentralisierte Internetdienste ermöglichen Überwachung
- Freedom Box: eigene Box für zuhause, mit allen deinen Daten
- Debian Server, mit vorinstallierter Software
- existiert auch für Raspberry Pi
- Github Repos: NickDaly/freedom-maker, petterreinholdtsen/freedombox-setup
- aktuelle Version 0.2
- pagekite tunnelt statische IP-Adresse
- Enigma Box? ist ein Produkt einer schweizer Firma mit ähnlichem Ziel
- Eine weitere Anwendung: unhosted.org
Session 6: Sessiontitel - Vortragende/r