[vz-dev] Erlang/OTP

[heinz, haeberle]

Hallo Zusammen,

Justin hat mich drauf aufmerksam gemacht, dass Erlang/OTP auf dieser 
Liste aufgetaucht ist.
Da ich auch sowas in Richtung Volkszähler gebastelt habe, hier ein paar 
Anmerkungen dazu:

Mein Aufbau:
- Ferraris Zähler mit ELV IR Reflexlichtschrankenabtastung
- ethersex auf pollin Net IO per watchcat an DSL-Router
(- zuvor habe ich ein embedded Linux board dazu benutzt. Siehe Quellcode 
github)
- erlang web und datenbank server auf einem vServer (€2.49 mtl)
- Kurven ankucken per jQuery.Flot im Browser

Allerdings habe ich aktuell keine lauffähige Hardware im Keller. Die hat 
einen Haus-Umbau nicht überlebt.
Über ca. 4 Monate ist es aber recht stabil gelaufen. Da muss ich auch 
den ethersex Leuten danken. Echt klasse projekt!

Gründe für meinen Aufbau:
- Erlang lernen
- jQuery/flot lernen
- Testen: funktioniert die IR Geschichte
- Stromverbrauchsdaten niemandem weitergeben (weder an EnBW noch an 
google...)

Der existierende code würde ich als ersten Sprint (im Sinne von SCRUM) 
sehen. Ein sogenannter funktionierender Durchstich. Mehr ist es nicht. 
Was auf jeden Fall noch notwendig wäre ist:
- Verwaltung einer Hirarchie (n Zähler an n Häusrern/Objekten von n 
Benutzern)
- Datenkonzentration: je älter Daten werden um so mehr Messwerte werden 
zu einem zusammengefasst.
- Zoom im Plot
- Datenschutz: Wo gibt es Schwachstellen, dass jemand die Daten 
missbrauchen kann sollte es im grösseren Stil verwendet werden (für den 
Fall, dass es einen volkszähler hoster geben sollte ;-))
- Für die IR Geschichte (so sie überhaupt noch eine Daseinsberechtigung 
hat) einen automatischen Abgleich


So jetzt noch ein bisschen Senf zum Thema Erlang/OTP von meiner Seite:

Ich kann nicht sagen ob Erlang für das Projekt die beste Lösung ist. 
Dazu fehlt mir in diesem Umfeld die Erfahrung. ASP.net, Ruby on Rails 
(und all dessen Nachahmer), LAMP usw. bieten sicher ein recht 
fruchtbares und stabiles Umfeld. Allerdings gewinne ich so langsam den 
Eindruck, dass manche dieser  Biester unhandlich werden. (Hier komme ich 
gewöhnlich mit dem Thema DSL = domainen spezifischer sprachen, aber das 
ist ein anderes Thema ;-)).

Wenn man aber mehr den Forschungs (=Spieltrieb)-Gedanken hinzunimmt ist 
es sicher eine interessante Alternative:
Anstelle MNESIA (orginal name war Amnesia, was aber für eine datenbank 
ein denkbar schlechter Name ist!) könnte man DETS als key value store 
einsetzen. Ob es allerdings sinnvoll ist....?

Ich glaube Skalierbarkeit ist hier kein so grosses Thema, da die Daten 
unterschiedlicher Zähler im Wesentlichen unabhängig voneinander sind. 
Und ein Zähler nicht sehr viele Daten liefert.

Ausfallsicherheit ist dabei auch kein sehr wichtiges Thema, ich denke 
die Messgeräte müssen sowieso Daten puffern wenn sie diese nicht 
abliefern können. Ob dies also am Server oder an der Internetverbindung 
liegt ist Jacke wie Hose.


Aber eines bietet Erlang auf jeden Fall: Ein stabiles und erprobtes 
System um die Technik von Morgen zu erproben! Als da wäre:
- kommunikation statt shared memory (keine race conditions! Und damit 
die 1000 cores nicht nur an der semaphore warten)
- leichtgewichtiges Prozessmodell (damit die 1000 cores in Zukunft auch 
was zu tun haben)
- funktional statt imperativ (optimierbar für die 1000 cores;-) und 
besser testbar da ohne Seiteneffekte)
- pattern matching (spart ernorm code, vor allem bei den URL's usw)
- ausdruckstark (der komplette Servercode ist ohne die Verwendung von 
externen libs und mit Kommentaren 380 Zeilen lang)
- es ist einfacher fehlertolerante Systeme zu bauen (sagt Joe zumindest. 
siehe - oder besser höre - den podcast unten)
- dynamisch typisierte Sprache (ist im Web ein bewährtes Konzept)

Fazit:
- wer es nehmen will soll es tun, aber bitte niemand Erlang aufzwingen. 
Es ist ANDERS und damit muss man umgehen wollen.
- Im Sinne der Privatheit der Daten ist es sicher kontraproduktiv auf 
Erlang zu setzen. Hier bietet ein PHP/MySQL Umfeld sicherlich einen 
unschlagbaren Preisvorteil.
Für eine echte plug und play Lösung - wie sie der Elektriker von nebenan 
benötigen würde - ist dies allerdings auch nicht ausreichend.
- aber warum nicht mehrere Implementierungen machen welche auf der API 
Ebene kompatibel sind? Also ich denke mein web Front Ende als auch das 
NetIO würden bei einem PHP/MySQL Server nichts wesentliches bemerken. 
Hat oft sogar den Vorteil, dass die Schnittstellen sinnvoll abgestimmt 
und definiert werden. Und dies trägt gewöhnlich zur Stabilität und 
Flexibilität am meisten bei.

Links:
- http://www.se-radio.net/2008/03/episode-89-joe-armstrong-on-erlang
- https://github.com/kheinz57

Gruessle und guten Rutsch
Heinz
P.S.: Soviel Senf! Ich hoffe es wird niemand schlecht dabei. Naja, Wurst 
;-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20101231/adb2b092/attachment.html>