NSA, Prism and industrial espionage

Wow, was für ein Titel. Der ist aber notwendig, damit die einschlägigen Suchmaschinen auch einen Treffer landen. Der große Skandal! Jetzt ist es raus, so ca. nach 15-20 Jahren. Die NSA liest tatsächlich unsere E-Mails mit. Wer hätte es gedacht. Ich kann mich noch an Diskussionen in Mailing-Listen zu Zeiten meines Studiums erinnern, in denen es um just dieses Problem ging. Das ist jetzt..knatter, knatter.. an die 20 Jahre her. Der Konsens war damals der, daß der Besitzer des Backbone, also quasi des obersten Netzknotens schön blöd wäre, wenn er die ganzen durchflutschenden Postkarten nicht irgendwo abspeichern und zur Seite legen würde. Spam-bereinigt braucht man eigentlich nicht soviel Plattenplatz dazu, jedenfalls wesentlich weniger als für Freeloader HD-Filme. Und dann kann man geeignet suchen, filtern, Konversationen zusammenfügen und alle Geheimnisse lesen, die andere für Geheimnisse halten.
Jetzt sagt an, wer von euch hat schon einmal richtig vertrauliche Dinge verschickt? Zugangsinformationen zu Accounts? Gründe, warum jemand gekündigt werden muss? Absprachen für Kundenangebote? Echt intime Details?
Ok, ihr könnt die Hände wieder runternehmen.
Man kann die NSA jetzt für die “Guten” halten, den FSB für die “Bösen” und die Chinesen für.. naja, die Chinesen eben, die meisten scheinen jedoch diese Neuigkeiten völlig reglos hinzunehmen. Bei dieser Thematik gibt es durchaus ein paar besondere Kuriositäten:

  • Irgendwie ahnt jeder, dass E-Mails, genau wie Chat-Nachrichten, SMS oder Facebookinhalte irgendwie nicht richtig privat sind, stört sich aber nicht daran. Warum? Weil er sich nicht vorstellen kann, wie diese Informationen mißbraucht werden können.
  • So lang wie es die o.g. Diskussion gibt, gibt es auch Sicherheitsmaßnahmen dagegen: Jeder kann mit mehr oder weniger Aufwand seine E-Mails so verschlüsseln, daß NSA & Co. diese erst in Jahrhunderten knacken können. Aus reiner Bequemlichkeit wird darauf verzichtet, es gibt keinen anderen Grund. In meinem Adressbuch gibt es nur einen einzigen(!!) Kontakt, mit dem ich öffentliche Schlüssel getauscht habe und verschlüsselt reden kann. Und nein, es ist kein geschäftlicher Kontakt.
  • Mein Geheimfavorit: Unternehmen lieben es geradezu, vertrauliche E-Mails im Klartext zu versenden, aber mit reichlich Hinweisen auf ihre Vertraulichkeit zu garnieren. Das ist, glaube ich, so eine Art Verfahren, damit ungewollt garantiert mitgelesen wird, genau wie die eine Marktfrau der anderen ins Ohr flüstert, “sagen Sie es ja nicht weiter, aber stellen Sie sich vor, was ich über XY gehört habe..”. Wo GEHEIM drauf steht muss einfach interessant sein, oder?

Wir wissen alle, das hier dringend etwas geschehen muss. Aber keiner tut was und alle schütteln nur bedröppelt die Köpfe, wenn wieder ein Auftrag verloren geht. Oder der Chinese wirklich verblüffende Fortschritte in der Solartechnologie macht.

Und damit das Ganze nicht zu unproduktiv endet, ein Link zu einem aktuellen Artikel (arstechnica), in dem erklärt wird, wie das so geht, mit der Verschlüsselung. Also wirklich. Wir müssen ja nicht jeden reinlassen, oder?

p.s. Kaum daß ich hier ein paar Worte verliere kommen die Engländer mit Tempora um die Ecke. Wieviel Anregung braucht die Öffentlichkeit noch? Ausgerechnet Augstein kommt mit einer Kolumne auf SPON, die zwar gewohnt empört oberflächlich, im Kern der Sache aber durchaus richtig ist.

p.p.s 1.Juli.. ich kann es kaum glauben, es schlägt immer höhere Wellen. Steckt der BND mit unter der Decke? Wußten die das alles? Wenn man den Gedanken konsequent weiter verfolgt, wäre der Austritt aus der NATO die richtige Konsequenz.

iPhone und Apple

In meinem “offiziellen” Job bin ich nun seit 8 Wochen (mit einigen Unterbrechungen) mit Softwareentwicklung für das iPhone beschäftigt. An dieser Stelle möchte ich kurz meine bisherigen Erfahrungen resümieren. Vorausschickend noch anzumerken ist, daß sich vieles wie Meckerei anhört. Das sollte nicht so sein. Ich bin dem Apple-Virus nicht anheim gefallen, verwende die Geräte privat nicht und habe daher einen neutralen Standpunkt. Es geht nicht darum, ob iPhones cool oder praktisch sind. Eher, was passiert wenn man dafür Software entwickelt.

iPhone Entwicklung – lohnt sich das denn?
Die Frage aller Fragen. Angesichts der unüberschaubaren Flut an Apps im Apple Store kann das Gefühl entstehen, daß dieser Markt komplett gesättigt ist. Das stimmt allerdings nicht, denn es werden immer noch Neugeräte (und damit Apps) verkauft. Allerdings – um “entdeckt” zu werden muß man entweder kostenlos (Blödsinn, wir wollen Geld verdienen) oder sehr gut sein. Wer früh kommt, verdient allerdings auch mit simpelsten Anwendungen Geld. Inzwischen geht das aus meiner Sicht für den Apple-Store / Consumermarkt nur dann, wenn es nur wenig Konkurrenz für die “Idee” gibt. Man muss berücksichtigen: Wenn man, sagen wir, in 2 Wochen eine sehr einfache App entwickelt (ganz optimistisch gerechnet) bei einem hiesigen, sehr konservativen Tagessatz von 500€ und noch die Hardwareeinstiegskosten (iMac Mini + iPod = 1.000€) + 100€ Entwicklerlizenz dazunimmt, liegt man bei einer initialen Investition von 6.100 €. Setzt man 1€ an muss die App 8.714-mal heruntergeladen werden (Apple Steuer: 30%), bevor man den break even erreicht. Ab diesem Zeitpunkt verdient man Geld. Aber nicht vergessen: Das ist der Consumer-Markt. Man ist zum Support verpflichtet. Bekommt man von nur einem Promille aller Anwender eine E-Mail (ganz dolle optimistisch), muß man bis zu diesem Punkt schon 8 Supportanfragen bearbeiten. Oh, lala. “Läuft” es einmal, wird die Anwendung in der Regel sehr schnell gecrackt und Plagiate tauchen auf, wie Kollegen von mir schon erfahren haben. Die Verkaufskurve zeigt dann unwillkührlich wieder nach unten. Ein großer Vorteil soll natürlich nicht verschwiegen werden. Als Entwickler im stillen Kämmerlein hat man mit dem AppStore eine fantastische Vertriebskette zur Verfügung. Die Kunden müssen nicht mehr gefunden oder geworben werden. Falls, tja, falls sie einen innerhalb der derzeit rund 200.000 angebotenen Apps selbst finden. :-)
Jetzt entwickeln wir nicht für den Consumer-Markt. Wir haben Geschäftskunden, die Masse ist nicht entscheidend. Allerdings bleibt die Gerätevielfalt dieselbe. Zur Anwendungsentwicklung auf einem Endgerät existiert eine preiswerte Alternative, und zwar die Implementierung einer für mobile Geräte optimierten Webseite. In vielen Fällen müssen ohnehin online auf Geschäftsdaten zugegriffen werden, eine Internetverbindung ist also erforderlich. Und ob HTC/Android, Berry oder iPhone, es läuft überall (mehr oder weniger ansehnlich) gleich. Im Funkloch tut sich dann nichts mehr, aber das ist dann vom Anwendungsfall abhängig. Man prüfe also, ob man sich das antun will ;)

Restriktionen
In der Apple-Welt lebt man auf einer Insel. Das ganze System ist darauf ausgelegt, dass der Anwender und der Entwickler ausschließlich Apple-Komponenten verwenden. Das fängt schon bei Kleinigkeiten an, wie dem Anschluß einer herkömmlichen PC Tastatur an einem Mac mini. Oder die Darstellung der Apple-Dokumentation in anderen Browsern außer Safari. Oder der Verbindung zu Windows Shares im Finder. Lauter kleine Ärgernisse, die man zwar irgendwann durch Googelei lösbar sind, aber trotzdem nerven, weil es sich um bewußt ausgelegte Stolpersteine handelt. Wer will sich schon gern die Arbeitsweise vorschreiben lassen. Ganz extrem ist natürlich dann die Entwicklungsumgebung fürs iPhone, ausschließlich mit XCode auf einem Mac Betriebssystem. Das hat keine technischen Gründe. Besonders zynisch dabei ist aus meiner Sicht, daß die darunterliegenden Komponenten aus der Unix-Welt stammen und wie der GCC beispielsweise der GPL unterliegen. Alles sicherlich rechtens, komisch riechen tut es trotzdem.

Entwicklung
Wie entwickelt man denn nun? XCode entpuppt sich als vollwertige und moderne Entwicklungsumgebung. In der Produktivität bleibt das Programm trotzdem meilenweit hinter Visual Studio zurück, was an dem umständlichen Debugger und am Fehlen von Funktionen wie “Edit & Continue” und der etwas zähen Intellisense Unterstützung liegt. Objective-C hätte ich mir schlimmer vorgestellt, ich habe mich trotz meines etwas vorgerückten Alters relativ schnell damit zurechtgefunden. Aber die Bibliotheksfunktionen! Immer wieder herrlich, wenn man selbst primitive Dinge wie das Zusammenfügen von Strings in der Doku nachschlagen darf, nur weil man den Funktionsnamen wieder vergessen hat. Man merkt auch, daß die Programmiersprache nur auf C übergestülpt ist. Probleme wie die Korruption des Speichers oder Stacks, Zugriff auf de-allokierte Objekte und ähnliche Schweinereien die ich schon ziemlich verdrängt hatte sind wieder an der Tagesordnung. Mit den damit verbundenen Programmabstürzen. Es ist problemlos möglich, eine Maske im Interface Builder so zu konfigurieren, daß das Programm an einer vollständig irreführenden Stelle einfriert. Nicht falsch verstehen. Das ist alles lösbar, nur würde man seine Zeit gern für andere Dinge verwenden. Im Grunde wird man ständig daran erinnert, daß man nicht wiederverwendbare Fähigkeiten für eine Insellösung aufbaut. So könnte man natürlich auch bei .NET, Java und ähnlichem argumentieren, nur sind die Inseln dort eher.. Kontinente.

Lernen
Wie ein guter Student habe ich mir zunächst ein Buch bestellt. “iPhone SDK Application Development” von Jonathan Zdziarski. Ein ehemaliger iPhone Hacker, ich dachte, das ist ganz sinnvoll. Leider erfüllte es nicht ganz meine Erwartungen. Die API hat sich inzwischen etwas verändert, so daß viele Beispiele etwas veraltet sind. An vielen Stellen hätte ich mir auch etwas mehr Tiefe gewünscht, dafür dann evtl. andere Bereiche wie Audio weggelassen. Auch der Index hilft nur begrenzt bei Problemen. Ein Buch im Sinne eines “Cookbook”, wie es für viele anderen Sprachen gibt ist sicherlich sinnvoller für den Einsteiger. Für Detailfragen muß man ohnehin auf Google zurückgreifen. Ich frage mich inzwischen ernsthaft, ob Bücher in dieser Form überhaupt noch einen praktischen Nutzen haben, außer auf der Biographie des Autors einen äußerst positiven Eindruck zu hinterlassen. (SterneSterneSterneSterneSterne).

Ich mach nicht mit

Und wenn wir schon beim Erfolg sind: Der iPad ist da. Hurra. Die ganze Netzwelt fieberte auf diesen Termin hin (heute morgen habe ich es durch Zufall auch mitbekommen). Steve stellte das neue Gerät vor, an dem er sich wieder dubbelig verdienen wird (hier paßt dieser schwäbische Begriff einfach ausgezeichnet). Jetzt kommt so langsam ein Formfaktor, der auch für mich interessant wirkt. Nur stellte ich sogleich mit Schrecken fest, daß das Softwaremodell genau dasselbe ist wie schon beim iPhone, also über den Apple Store kanalisiert wird. Schreck! Während mir vor Objective-C nicht graust, ist dieser ganze Registrierungs- und Publishing-Blödsinn über den Apple Store einfach nur bescheuert. Der Vorteil ist natürlich ein mehr oder wenig effektiver Vertriebskanal, aber das hilft eigentlich nur Leuten, die ihre Software als “Produkt” für Endkunden herstellen. Ich glaube, man wird über den Apple Store irgendwie automatisch gewerbesteuerpflichtig. Und wer will das schon? :-)
Für mich als Freiberufler mit sehr wenig Kunden und eher spezialisierter Software ist das alles nur ein Ärgernis – obwohl ein iPhone Frontend für manche Anwendungen im Tracking Bereich natürlich richtig praktisch wäre. Aber wenn das einfachste der Welt, einfach ein eigenes Programm hochladen und starten nicht funktioniert, dann ist das ein terminales No Go. Also ist zu erwarten, daß, trotz meiner Sympathie für Züge, dieser ohne mich abfahren wird.

Sudoku ade

Geocaching Rätsel wie dieses da als Sudoku gehen mir so auf die Nerven. Warum? Die Ermittlung der Koordinaten ist eine reine Zeitverzögerung frei jeden “AHA-Effekts”. Ein Traditional mit Wartezeit nur damit man noch einen Difficulty-Stern anhängen kann. Sodele, genug abgelästert. Damit mir das in der Zukunft nicht mehr passiert mußte ich mir ein kleines Helferlein bauen – den Sudoku-Knacker. Mehr dazu auf der Projektseite.

Dicker Hund

Sonntag in einer Woche kann sollte man wieder wählen gehen. Wirklich, es ist wichtig. Wenn ihr keine Partei wählen wollt oder könnt, geht trotzdem hin! Warum? Weil eure Stimme dann zum Wahlergebnis beiträgt, wenn auch keiner Partei angerechnet wird. Also, wenn “politikverdrossen” (was ich gut nachvollziehen kann), dann nur so.
Wer sich bei der Europawahl nicht so recht entscheiden kann, dem sei (wieder einmal) der Wahl-O-Mat ans Herz gelegt. Wer möchte sich schon durch alle Parteiprogramme durcharbeiten?
Ich tat es und.. oh Schreck:

Der dickste Hund von allen

..das kam dabei raus. Ich weiß nicht wie das geschehen konnte. Drum merket auf: Vermutlich wißt ihr auch nicht was in den Parteiprogrammen zur Europawahl steht. Mir war es jedenfalls nicht klar.
Äh.. und nu? ;-)

auto_increment

Heute abend bin ich beinahe an einem ganz bescheuerten Bug verzweifelt der so dämlich ist, daß ich es mir nicht nehmen lasse ihn hier zum besten zu geben:

Vorlauf: Kunde meldet sich, “nix geht mehr”. Ok, schauen wir mal. Tja, Tools laufen, MySQl Tables auch ok, nur.. irgendwie kann man nix mehr inserten!
Wir hax0rn mal sicherheitshalber:

mysql> insert into posreport set mmsi=1;
ERROR 1062 (23000): Duplicate entry ‘2147483647’ for key 1

Hä was ist denn des? Ich pfusche noch eine Weile herum bis klar ist, daß man nur noch was eintragen kann wenn man der auto_increment Spalte definierte Werte gibt. Aber das Schöne an auto_increment ist halt das Auto, ja, teilweise wie im richtigen Leben auch. Der geht nimmer! Warum? Weil auto_increment nicht wieder bei 1 anfängt, wenn er voll ist. Dann gibts ein truncate. Angeblich geht das aus der Doku hervor aber ich bin heute dafür nicht gemacht.

mysql> select max(id) from posreport;
+————+
| max(id) |
+————+
| 2147483647 |
+————+
1 row in set (0.00 sec)

mysql> alter table posreport auto_increment=1;
Query OK, 0 rows affected (0.05 sec)
Records: 0 Duplicates: 0 Warnings: 0

Und ja, das bedeutet daß seine DB bis zum heutigen Tage an die 2,2 Mrd. Positionsmeldungen verarbeitet hat. Manchmal schon praktisch, daß man sowas nicht von Hand machen muß :-)

Fehlerquellen

Nach inzwischen einigen Jahren in der Bearbeitung von Fehlern bei CRM Software beginnen sich ein paar klare Linien abzuzeichnen. Man kann es sicher verallgemeinern, aber das laß ich erstmal. Wenn man für ein etwas größeres Projekt verantwortlich ist, bekommt man natürlich auch alle Fehler mit die der Kunde meldet oder die intern entdeckt werden. Durch unser Anfragesystem werden sie in Gruppen klassifiziert, entsprechend den Softwaremodulen bzw. den logischen Einheiten. Beispiel: Materialverwaltung, Kundenstamm, usw.
In diesen zynischen Zeiten der Gewinnmaximierung steht natürlich immer die Begrenzung der Kosten obenan, das ist bei uns nicht anders. Nachdem das nun eine Zeitlang fröhlich ausgewertet wurde kam heraus, was alle schon längst wußten: Die Dauerbaustellen machen die meisten Probleme. Nichts ungewöhnliches soweit. Jetzt werde ich natürlich oft nach der Ursache dieser Probleme gefragt (das ist der unangenehme Teil mit der Verantwortung). Die Antwort ist entweder kurz das Symptom (Schludrigkeit, Verschlimmbesserung, Funktionalität nicht kapiert, Seiteneffekt übersehen, Inkompetenz (ja, gibt es auch), mehrdeutige Konzeption, Verteilungs- oder Runtimefehler, falsche Versionierung, Altlasten) oder ich versuche mich in einem Vortrag über den Grund, weshalb diese Probleme an besagter Stelle gehäuft auftreten. Im Duell zwischen Konzeption und Entwicklung gibt es natürlich kaum eine Chance, diese Probleme der Konzeption zuzuschieben, so attraktiv es auch erscheinen mag. Aber trotzdem gibt es eine Beziehung zwischen gewissen Konzepten und einem Berg von Programmfehlern. Durch geeignete Konzeptionierung lassen sich diese Engpässe nämlich bedeutend verringern. So könnte man es machen:

  • Abläufe und Verfahren sollten möglichst gleich sein. Das erwartet der Benutzer und erleichtert der Entwicklung die Verwendung von gemeinsamen Code.
  • Der Anwendungsfall sollte so simpel wie möglich sein. Ernsthaft. So simpel wie es geht. Aber wenn es nun mal komplex ist? Dann in primitive Einzelteile zerhacken. Denn die Entwickler sind Simpel, und die Kunden erst recht ;-)
  • Nie, gar nie, einfach nie im Leben sollte eine neue Funktionalität quasi als “Trittbrettfahrer” auf eine vorhandene Funktion “aufgepfropft” werden. Das geschieht etwa so: “Huch, der Kunde will gern eine neue Funktion XYZ, aber hier haben wir ein Modul, das macht schon XY, also machen wir doch eine kleine Erweiterung dafür und basteln eine Markierung rein, mit der man unterscheiden kann, ob das Modul jetzt XY wie gewohnt oder XYZ macht”. Das ist zunächst sicher plausibel, denn die Kosten bleiben im Rahmen. Doch später geht die Entwicklung weiter und bald wird klar, daß hier zwei ein Bett teilen, die nicht zusammen gehören. Nur ist leider in der Zwischenzeit alles viel zu kompliziert geworden, als daß man sie noch mit vertretbaren Aufwand trennen könnte.
    Ich meine das nicht aus Entwicklungssicht (da ist die Lage anders: gemeinsamer Code in die Basisklasse, usw.) sondern aus konzeptioneller: “Die Extrabonuspunkte sind ja so ähnlich wie die Sonderbonuspunkte.. naja, also, dann könnten wir sie ja zusammen in einer Maske anzeigen nur im Falle von XYZ muß dann in der Spalte ZZZ anders gerechnet werden….“. Man ahnt ja, worauf das hinausläuft.

Auf seiten der Entwicklung wird nur zu gern der Fehler gemacht, den Code unter entwicklungsmäßigen Gesichtspunkten in verschiedene Module zu unterteilen. Beispiel: “Diese drei Funktionen verwenden alle die Library XY, von daher müssen sie in ein Modul zusammengefaßt werden”. Natürlich gibt es immer wiederkehrende Elemente, die man gut zusammenfassen kann: Datenbankkonnektivität, Kommunikationsmodule, Standardmasken. Aber nur zu oft passiert es, daß zum Beispiel zur Auflösung des Referenzpfads irgendein Modul hinzugefügt wird, nur weil dort eine Methode ist, die man gerne verwenden würde. Die Lösung hieße eigentlich Refakturierung und wird leider nicht von allen Kollegen verstanden und ausgeführt. Das Ergebnis ist dann, daß auf einmal Abhängigkeiten zwischen Dingen bestehen, die aus Anwendersicht nichts miteinander zu tun haben. Der Kunde versteht dann (zu Recht) nicht, warum z.B. für die Funktion des Wareneingangs das Kundendienstmodul benötigt wird.
Hier gilt einfach, die Abhängigkeiten so gering wie möglich zu halten. Das hat den Vorteil, daß man es leichter hat, wenn z.B. nur einzelne Programmteile portiert werden sollen. Ich hab gut reden! Darf ich doch jeden Tag mit einer Codebasis arbeiten, an der o.g. Probleme zuhauf vorhanden sind. Ein Grund brauche ich halt um das mal loszuwerden ;-)

Software für Bildergalerie: JAlbum

Ich muß hier mal kurz nen Tip loswerden: JAlbum hat mir gestern eine Menge Arbeit erspart. Großartiges Tool, daß das Erstellen einer Galerie für Urlaubsbilder o.ä. ganz einfach macht. Nicht viel Klickerei und zwei entscheidende Merkmale, die mir persönlich ganz wichtig sind:

  1. Relative Pfade und nur Javascript. Die Galerie funktioniert demnach genauso lokal, auf einer Backup-CD und im Web
  2. Skalierung und Bearbeitung nicht im Web. Diesen Weg gehen viele Plugins für Blogs. Falls die Arbeit im Web geschieht, müssen erst die unskalierten Bilder hochgeladen werden was bei den meisten Upstream-Raten nicht besonders dolle ist. Gestern habe ich die fertige Galerie mit 300+ Bilder in einer knappen halben Stunden hochgeladen.

Was mir nicht so gut gefällt ist die relativ unintuitive Art, die Bilderverzeichnisse hierarchisch anzuordnen, der “Top”-Link meines Wurzelverzeichnisses zeigte regelmäßig ins Leere. Das kann man aber durch eine index.html im übergeordneten Verzeichnis wieder einfangen.