Montag, 11. März 2013

Swisscom NATEL: Achtung hohe Rechnung!

Vor einigen Tagen kam bei mir eine "Update der Netzbetreiber-Einstellungen" auf dem iPhone rein:


Was ist das bloss?!? Ich habe es - der swisscom blind vertrauend - angenommen.

Jetzt ist klar, was das war:
Das update aktiviert die automatische Einwahl in die swisscom hotspots: MOBILE-EAPSIM etc.!

Wo ist das Problem? 

Eigentlich wäre das ja gut, aber: Wenn das iPhone sich in einem WLAN wähnt, kann es ungehindert tonnenweise Zeugs aus dem Internet nachladen, z.B. Filme, Software-Updates etc. etc.. z.B. synchronsiert Evernote Megabytes-weise Zeugs, sobald es in einem WLAN ist. 
Und Achtung: Swisscom verrechnet diese Megabyte voll und ganz mit denen, die man im Abo gelöst hat, in meinem Fall sind das 250MB pro Monat. Alle weiteren Megabytes kommen sehr teuer auf die Natel-Rechnung. 

Lösung:

Darum habe ich die Swisscom WLAN immer deaktiviert (dieses Netzwerk ignorieren etc.), um zu verhindern, dass meine Natel-Rechnung explodiert. 
Ich finde, möchte Swisscom, dass wir die WLAN benutzen, muss sie deren Benutzung unlimitiert machen. 
Naja, natürlich entfällt dieses Problem bei den Leuten, die so ein unlimited-Abo haben... was ich leider nicht habe. (Dafür mit unlimited Speed :-) ) 

Nachtrag: 

Was genau Swisscom mit diesem Update ändern wollte, kann ich nicht nachvollziehen. Vermutlich wollten sie mehr ändern, und haben nur nebenbei diese WLAN aktiviert. 

Mittwoch, 6. März 2013

Das Erbe von WebObjects

Meine ersten Schritte in der Welt von Mac OS X, Web-Applications und OR-Mapping machte ich im Jahr 2001 mit WebObjects / EOF (und natürlich mit dem TemperatureConverter in Cocoa) - leider habe ich danach den Anschluss verloren.

WebObjects und EOF haben mich geprägt, und wesentlich dazu beigetragen, dass ich die ganze Zeit über misstrauisch über die Komplexität von JPA, Hibernate, JSF, etc. etc. geblieben bin. NeXT und Apple konnten das damals schon - warum war das bis jetzt in der Java Welt so kompliziert?

Leider ist WebObjects und EOF mehr oder weniger eingestellt (EOF lebt als CoreData in OS und iOS weiter) - es gibt aber noch Open-Source-Spuren davon, die ich hier aufschreiben will:




Type Coercion

http://tapestry.apache.org/typecoercer-service.html
das muss ich mir mal genauer anschauen. (Im Zusammenhang Authorization Context, Types, XACML)


(Ok, dieser Post war jetzt tatsächlich nur Note to Myself. :-)


Montag, 4. März 2013

mvn: viele Projekte, die faktisch nur eines sind.

Die Ausgangslage

Ich bin "Integrator" in einem mittelgrossen Projekt, das aus mehreren "Komponenten" besteht. In einem normalen Fall würde man ein (hierarchisches) maven-Projekt erstellen, mit den "Komponenten" als Sub-Module. In meinem Fall wären das ca. 14 Submodule (ca. 3 JEE6-Applikationen, Modelle etc.), wobei die Submodule auch wieder in Submodule unterteilt sind. 
Das Set-Up wäre also vergleichbar mit dem Set-Up von JBoss AS.

Die Entwicklung zum Problem

Durch meine anfängliche Unerfahrenheit als Integrator liess ich mich durch Architekten und anderen Entwicklern dazu verleiten, das Projekt aufzuteilen: 
Die "Komponenten" sollen unabhängig sein, weil sie später von anderen Projekten wiederverwendet werden sollen, und auch von anderen Entwicklerteams weiterentwickelt werden.  
Was dabei rauskam: 14 Total unabhängige Projekte, mit eigenem mvn-Build und eigenem Job auf der Continous Integration (Hudson), z.T. mit eigenem CVS (sic!) Repository, die aber eine enge Kopplung via Maven-Dependencies untereinander haben. 

De-Facto handelt es sich aber um ein Projekt, die Entwickler arbeiten immer an 4-5 Projekten gleichzeitig.
Um dieses Problem zu entschärfen, habe ich alle 14 Projekte und deren Dependencies von der Continous Integration als SNAPSHOT builden lassen. So haben alle Entwickler immer die neuste Version von allem. Ausserdem habe ich die Dependencies durch ein BOM-pom (Import eines Dependency-Management) synchronisiert - was mir von den Architekten etc. prompt wieder verboten wurde, weil "Abhängigkeit". 

Dieses Set-Up hat uns aber massive Probleme mit der Aktualität der SNAPSHOT beschert. 

Ausserdem: das Release der 14 beteiligten Projekte und deren Abhängigkeiten ist eine "Integration Hell" und beschäftigt einen Entwickler 6h lang. 

Lösungsansätze

Probleme mit der Aktualität der SNAPSHOT zu entschärfen, haben wir uns überlegt, dass die Entwickler die Sub-Projekte halt releasen soll und die Abhängigkeiten von Hand in den abhängigen Projekten nachtragen soll. Auch das ist natürlich sehr fehleranfällig und sehr zeitaufwändig. 

Frage

Die Frage ist nun: gibt es ein Werkzeug, dass die Abhängigkeiten bei einem Release der 14 Projekte in den abhängigen Projekten automatisch nachführt? 
Mein (unerfahrenes) Gefühl sagt mir, dass ich hier total auf dem Holzweg bin, und die 14 Projekte eigentlich nur eines sein sollten, so wie JBoss. Wenigstens so lange, wie das Team "querbeet" daran arbeitet. 
Was aber sage ich meinen Architekten, die finden, jede "Komponente" müsse total unabhängig sein?
Und was ist mit den Projekten, die jetzt schon abhängig von einem unserer "Komponenten" sind?


Fazit und Lösung: 

Nach vielen Diskussionen (mit maven-Experten) hat sich diese Lösung herauskristallisiert, die mir eigentlich von Anfang her als Gefühl klar war (siehe oben): 
In einem solchen Set-Up sollte nur ein Maven-Projekt existieren: die 14 Teilprojekte werden module dieses Projektes, wobei diese Module wiederum sub-Module haben können. 
Das gibt keine Einschränkungen in Sachen low-coupling. 
Werden später die Module tatsächlich eigenständige Projekte, die von einem eigenen Team separat entwickelt werden, und auch einen total unabhängigen Release-Zyklus haben, können die Module leicht herausgelöst werden. 
Anders ausgedrückt: Die Zusammenfassung als maven-Projekt sagt nichts aus über die Kopplung der Software in den Modulen. Sie bildet nur den Fakt ab, dass die Module gemeinsam gebaut werden. Die Module bleiben schwach gekoppelt, unabhängig und wiederverwertbar. 



Links:

http://stackoverflow.com/a/11478970/1800814
http://stackoverflow.com/a/2837816/1800814