Samstag, Januar 31, 2009

böse Finanzwelt

Ich sehe mir seit kurzem jede Folge des Colbert Reports und der Daily Show an.
Und so langsam bekomme ich das Gefühl, dass uns (ebenso wie den USA) ein paar Gesetze zur Haftung von finanziellen Brandstiftern fehlen.


Wir erinnern uns an den Zusammenbruch des amerikanischen Immobilienmarktes und insbesondere der spekulativ gehandelten Darlehen.

Problem Nr. 1:  schlecht gesicherte Darlehen wurden in Bündeln weiterverkauft und als Investmentmöglichkeit angeboten. Nicht zuletzt sogar an Kleinanleger.

Problem Nr. 2: Ratingagenturen haben den nahezu ungedecken Darlehen ein hervorragendes Rating bescheinigt. Auf welcher Grundlage? Viel schlechter kann man seinen Job ja nicht machen.

Durch die Menge der geplatzten Kredite und verpufften Investitionen gingen ein paar Banken Pleite und fast alle gerieten in Bedrängnis.

Problem Nr. 3:
Manche Bankmanager (bekannt geworden in den USA - unsere Manager haben etwas mehr Fingerspitzengefühl) geben sogar noch königliche Beträge aus, nachdem sie durch ein Millardendarlehen vom Staat vor dem Ruin gerettet wurden. Z.B. für Privatjets, Büroeinrichtungen oder Dividendenausschüttungen.
Wobei letzteres sich vermutlich darüber erklärt, dass man die Aktienbesitzer nicht verprellen will, weil die eigenen Einlagen zu einem Teil aus eigenen Aktien bestehen. Und im Falle sinkender Kurse stünde man wieder kurz vor der Insolvenz.

Und was ist mit Münteferings Heuschrecken, deren System ich bisher nur schemenhaft verstanden habe:
Problem Nr. 4: Ein Investmentfond kauft ein Unternehmen. Da Investmentfonds nie genügend Geld flüssig haben, nehmen sie dafür einen Kredit auf. Den Kredit wälzt man dann auf das Unternehmen ab, so dass der Fond ohne großen Einsatz in den Besitz des Unternehmens gekommen ist.
Da der Fond aber gleichzeitig das eigentliche Geschäft nur notdürftig instand hält, geht langsam alles den Bach runter und man gerät in Schwierigkeiten den Kredit zu bedienen.
D.h. effektiv streicht das Kreditinstitut den Gewinn für einen Kredit ein, den das Unternehmen gar nicht nötig hatte, und der Investmentfond verkauft das Unternehmen weiter, bevor sich die desolate Lage bilanziell negativ bemerkbar macht. Und nicht selten gehen wenig später die so ausgenommenen Unternehmen pleite. Manchmal werden sie zuvor noch zerteilt, fusioniert oder einfach nur ein paar Werte verschoben.

Zu letzt gab es erst das Beispiel Hertie wo ein anderes Unternehmen des gleichen Investmentfonds so überzogene Mieten genommen hat, dass das Kaufhaus an den meisten Orten nicht mehr wirtschaftlich war.

Liegt da wirklich kein einziger Straftatbestand vor? Betrug? Wucher? Was ist mit "Eigentum verpflichtet"? Das müsste doch doppelt gelten, wenn am Eigentum noch Arbeitskräfte hängen.
Wenn Manager nicht mehr im Sinne der Firma agieren und langfristigen Schaden für kurzfristige Gewinne in Kauf nehmen, schreit es Ungerechtigkeit. Aber ohne entsprechende Gesetze wird das nur schlimmer werden.

Freitag, Januar 23, 2009

Kaffeetrinker

In unserer Firma gibt es vermutlich Heinzelmännchen, die immer die Kaffeekannen leer machen.
Oder es sind die Mitarbeiter. Und davon haben wir verschiedene Typen:

Der Eifrige
"Ich muss weg."
Nimmt sich die letzte Tasse, läßt den Deckel locker auf der Kanne und geht.

Der Grobsensoriker
"Da war noch was drin."
Nimmt sich die letzte Tasse und verschließt die Kanne mit der letzten Pfütze wieder ordentlich.

Die Vorausschauende
"Du musst nur den Knopf drücken."
Bereitet schon mal die nächste Kanne vor, wenn sie die vorletzte Tasse genommen hat.

Der Controller
"Was sollte das denn?"
Stellt den geistigen Gesundheitszustand der Vorausschauenden in Frage, weil in der Zwischenzeit der Eilige da war und die nächste Kanne nicht angestellt hat.

Der Spontane
"Ich will Kaffee. Jetzt!"
Zieht die halbvolle Kanne aus der Maschine, während sie noch läuft. Das restliche Wasser füllt dann den Filter bis zum Rand und bleibt so stehen, bis der Raumpfleger kommt.

Ich bin mir sicher dass es noch mehr Typen gibt, aber wir haben eine kleine Firma, in der die Mitarbeiter nicht einmal einen Kasten Sprudel bedienen können.

Mittwoch, November 05, 2008

Hilfe gesucht

Ich habe eine interessante Idee für ein online Spiel.
Da ich aber immer wenn ich an einem größeren Projekt alleine arbeite bald die Lust verliere, brauche ich noch

1 Programmierer mit Erfahrungen mit Hibernate. Angepeilte Umgebung ist Java mit JSF und oder JSP (wenn sich keiner findet auch PHP).

1 Menschen mit guten musiktheoretischen Kenntnissen. Es geht um maschinell erzeugte Melodien.

Nicht dass wir uns missverstehen - es handelt sich um ein Hobbyprojekt und Geld gibt's nicht.
Falls wider erwarten irgendwann einmal Geld dabei herausspringt, wird fair geteilt, aber daran denke ich jetzt noch nicht.

Donnerstag, Oktober 02, 2008

Mixtape

Ich habe gerade mein erstes Mixtape seit mehr als 10 Jahren gemacht.

Samstag, September 27, 2008

The Pragmatic Programmer (Ruby Teil 2)

Ich habe mir jetzt das erste Kapitel einer online Version des Pragmatic Programmers angetan. Dieses Buch scheint die Bibel der Ruby Programmierer zu sein.

Von den Grundlagen gefallen mir die vereinfachten Initialisierungen von Arrays und Maps (Hash) sehr gut. Damit kann man sich viel Mühe und stupide Arbeit sparen.
Beispiele:
[3.1415, "Pi", 2008] erzeugt einen Array
{ 'a' => 'Einleitung', 'b' => 'Grundlagen', 'c' => 'Objekte' } erzeugt eine Map

Vielversprechend sind auch die ominösen Closures, bei denen junge Programmierer, die gerade von Schweinecode-Skriptsprachen umsteigen, feucht werden.

Und die direkte Einbindung von regulären Ausdrücken (mittels =~ und // ) ist auch eine feine Sache.

Aber es ist mir unerträglich mit welcher Selbstverständlichkeit Fakten zurechtgebogen werden, um Ruby im Gegensatz zu anderen Programmiersprachen gut aussehen zu lassen. Da werden die blödesten Rückfälle in alte Zeiten garniert mit den Prädikaten "einfacher", "besser" und ganz wichtig "eleganter". Damit will man doch nur unerfahrene Leser über den Leisten ziehen.

Eine Freude war mir, wie die Möglichkeit Klammern in allen Varianten wegzulassen erst als Feature verkauft wird - und dann im Nachsatz darauf hingewiesen wird, dass man sie lieber setzen sollte, weil man sonst durcheinander kommt.
Der Compiler, den ich verwende, warnt generell davor Klammern bei Methodenaufrufen wegzulassen, um "mit zukünftigen Versionen kompatibel zu sein".

Und wer denkt sich heute noch eine Sprache aus bei der das Ende der Zeile das Ende des Befehls darstellt? Will man damit erreichen, dass man alle Aktionen freiwillig so klein und überschaubar hält, dass das nicht stört?
Aber das stimmt nicht so ganz, denn man kann nach bestimmten Zeichen ( . , ) anscheinend in die nächste Zeile umbrechen.

geht:
[1,
2]

geht nicht:
[1
, 2]

Zitat aus dem Pragmatic Programmer:
Allerdings gab es bis Ruby eine Unterstützung für reguläre Ausdrücke nur in den sogenannten Script-Sprachen wie Perl, Python und awk.
... und Ruby ist keine Skriptsprache? Und Ruby hat nicht seine ganze RegExp Syntax bei Perl abgekupfert? Und andere objektorientierte Sprachen haben keine RegExp Bibliotheken?
Eine "nicht-Skriptsprache" würde wohl kaum einen Unterschied machen, ob der Aufruf oder die Deklaration einer Methode zuerst in einer Datei steht.

Donnerstag, September 25, 2008

Kleinste gemeinsame Obermengen

Heute hatte ich bei der Arbeit ein interessantes Problem.
Es fing ganz harmlos mit "Business Logik" an und reduzierte sich je mehr ich darüber nachdachte auf schlichte Mengenlehre.

Das Kernproblem ist folgendes und sei dem geneigten Leser zur Implementierung überlassen:

Man hat eine Gesamtmenge A von Mengen B.
Diese Mengen B enthalten eventuell gleiche Elemente.
Aufgabe ist es nun "kleinste gemeinsame Obermengen" zu finden. D.h. wenn zwei Mengen gleiche Elemente enthalten, müssen sie vereinigt werden.

Beispiel:
a: [1]
b: [2, 3]
c: [4, 5, 6]
d: [7, 8]
e: [9]
f: [1, 3, 4, 5]

=>
[1, 2, 3, 4, 5, 6], [7, 8], [9]
d.h. a, b, c und f werden vereint. d und e bleiben separat.

Ich habe das ganze mit Maps, Sets und einer Rekursion gelöst. Und irgendwie habe ich das Gefühl, dass es eine einfachere Lösung geben muss.
Vor allem ist mir auf dem Nachhauseweg aufgefallen, dass ich die ganze Aktion vermutlich auch noch für eine andere Gruppierungsebene machen muss...

Ruby

Ich habe jetzt angefangen mir die Programmiersprache Ruby anzusehen.
Koryphäen wie Martin Fowler schwärmen davon. Und das will etwas heißen, denn er hat ein paar wunderbare Bücher über Programmierung geschrieben. Vor allem den Klassiker "
Refactoring: Improving the Design of Existing Code".
Außerdem ist es die Modesprache des Tages.

Und mein erster Eindruck ist: furchtbare Hackersprache. Javascript reloaded.

* Man kann abkürzen wo man will. D.h. Methodenaufrufe brauchen nicht einmal die sonst üblichen Klammern, wenn man keine Parameter hat.
* Membervariabelen werden nicht zwingend deklariert. Sie entstehen quasi bei Benutzung.
* Methodendeklarationen sind arschhäßlich und erinnern mich an 70er Jahre Sprachen. Anstelle von Klammern wird mit "end" gearbeitet. *schauder*
* Überhaupt scheinen die Entwickler eine Allergie gegen Klammern gehabt zu haben, was bei if und ähnlichen Kontrollstrukturen eher zur Verwirrung beiträgt.

Viele Blogs, in denen Ruby gelobt wird, pochen darauf, dass andere Sprachen viel zu unflexibel seien, zu viel Tipparbeit erfordern und den Blick auf das Wesentliche durch zu viel Ballast ("boiler plate code") verschleiern.

Man kann den Code in Ruby zwar durch diverse Umdefinitionen klein halten, aber m.E. leidet die Lesbarkeit sehr darunter. Vermutlich soll der Name von einer gewissen Verwandtschaft mit Perl zeugen. Sozusagen Perl x C++ mit syntaktischen Anlehnungen an Pascal.
Und ich kann mir wirklich nicht vorstellen, wie man da bei einem größeren Projekt noch durchblicken soll. Sobald die ersten Umstrukturierungen kommen, verliert man den Durchblick.

Ich finde Ruby noch unleserlich und verwirrend, aber so ging es mir mit Java 1.1 anfangs auch.
Mal sehen ob sich der Eindruck ändert, wenn ich erst mal etwas damit gemacht habe.