mthie spaces

Nachtaufnahmen - ein tolles Spielzeug

03.03.2015 21:45

Vor einigen Wochen war ich Abends spontan mit Lars los, um ein paar Nachtaufnahmen zu machen. Es gab kein festgelegtes Ziel, wir stiegen ins Auto und ließen uns einfach mal führen.

Am Ende landeten wir in Hamburgs Speicherstadt. Es war kalt, leicht neblig und wir hatten beide schon einen vollen Arbeitstag hinter uns. Das Ende vom Lied: Ein paar traumhafte Nachtshots. Hier auf dem Foto sieht man im Übrigen im Hintergrund die Kirche St. Katherinen und einen Löwen mit dem HHPA-Logo.

Zur Galerie »

Die Kinder lernen ja nix!

16.01.2015 10:01

Diese Diskussion. Ein Mädchen beschwert sich auf Twitter:

Grundsätzlich geb ich ihr Recht. Viele Dinge, die ich in der Schule gelernt habe, brauchte ich danach nie wieder und ich bin auch immer noch der Meinung, dass es für einige Fächer keine Zensuren geben darf (Musik, Kunst und Sport - entweder man kann es oder nicht, Benotung ist sinnlos).

Ich möchte jetzt auch nicht so klingen, als würde ich unbedingt sagen wollen: "Man muss die Eltern mehr einbeziehen", aber grundsätzlich läuft heutzutage eher in der Erziehung der Kinder etwas falsch. Die Eltern haben heute kleine Prinzessinnen und Prinzen zu Hause, teilweise werden die Kinder durch die Eltern angebetet und in Watte gepackt. Man beschützt sie vor all diesen bösen Einflüssen der Außenwelt. Von der Windel bis zum Auszug.

Ich bin der Meinung, man könnte die von Naina genannten Probleme lösen, wenn die Eltern aufhören, alle schädlichen Einflüsse von ihren Kindern fernzuhalten. Warum beziehen Eltern die Kindern nicht z.B. in die Finanzplanung mit ein? Warum fragt man nicht, sobald das Kind 14 ist, einfach mal am Ende des Monats: "Wir haben XXXX Euro im Monat, davon geht Miete etc. ab. Dann bleibt folgendes übrig, was machen wir damit." Und wenn dann das Kind der Meinung ist, man müsse Geld für irgendwas "lebensnotwendiges" (also für's Kind) ausgeben, auf was es dafür denn dann verzichten wollen?

So bekommt man Jugendliche nämlich auch an (über-)lebensnotwendige Alltagsprobleme herangeführt. Auch an Versicherungen und Steuern. So etwas haben Kinder damals™ ganz automatisch und eher auf die harte Tour gelernt. Heutzutage müssen Kinder da herangeführt werden - also, es muss halt gemacht werden. Letzteres ist wahrscheinlich eines der größten Probleme: Die Eltern können es auch nicht.

Wir leben in einer Gesellschaft, in der das Nicht-Wissen anerkannt ist. Das führt dazu, dass Menschen dann halt lieber nicht dazulernen, da "jemand es schon wissen wird".

Traurig.

Ach ja, aber liebe Naina, die kleines Sprachgenie: Respekt dass du Gedichtanalysen in 4 Sprachen schreiben kannst. Ich konnte so einen Quatsch nie so richtig. Meine Aufsätze waren zwar ohne Rechtschreibfehler, dafür inhaltlicher Blödsinn. Aber ich wollte auch nie Dichter werden.

Amazon Echo - und die Deutschen schieben Panik

06.11.2014 21:49

Amazon hat Echo vorgestellt:

Ich möchte jetzt nicht direkt um Geld wetten, aber ich schätze schon, dass die Boulevard-Presse sofort den Panik-Modus schieben und die Deutschen davon überzeugen wird, dass Echo den ganzen Tag den Haushalt belauscht und 100% der gesprochenen Worte an die NSA weitergibt.

Ich find das Produkt echt großartig und hoffe, dass es schnell nach Deutschland kommt, denn ich muss gestehen, dass die Sprachsuche der Fire TV schon fantastisch funktioniert und wenn Echo eine Weiterentwicklung dessen ist, kann es nur großartig werden.

PHP - das Ende einer Ära

20.09.2014 13:06

Vorweg: Ich habe in den letzten 12 Jahren mein Geld mit PHP verdient. Ich war immer der Meinung, es handle sich dabei um "echte Programmierung". Oh Mann, ich war jung und brauchte das Geld.

Vor ein paar Jahren kam dann Python hinzu, die Versuche zuvor mit diversen anderen Sprachen wie Ruby lass ich jetzt mal weg. Python war für mich wie die Erlösung. Python war schneller, Python war strukturierter. Python hat eine Einrückvorgabe gegen lazy Entwickler, die der Meinung sind, dass man jede Zeile anders einrücken und damit Übersichtlichkeit verhindern kann. Es ist eine tolle Sprache. Für mich als Google-Fanboy war die Nutzung auf der Google-AppEngine anfangs auf Python (oder Java, aber mal ehrlich!) beschränkt.

Ich war in der Scriptsprachen-Welt. Man sagte immer, damit könne man am Schnellsten mal eben was hinzaubern. Das stimmte. Das war meine Welt. Ich hab immer Arbeit bekommen. Das war okay so.

Dann kam Go.

Es war keine Liebe auf den ersten Blick. Go sah komisch aus. Der Typ steht bei der Definition hinter dem Namen. Was für 'ne schräge Syntax. Dachte ich. Aber wie lernt man eine Sprache am Besten? Man liest anderen Quelltext danacht macht man es dann einfach mal selbst.

Was mir recht schnell auffiel: die Quelltexte verschiedener Entwickler sahen gleich aus. Alles war irgendwie schön strukturiert. Das Zauberwort heisst "gofmt". Die Programmiersprache bringt seine Coding-Conventions mit. Wie geil ist das denn?

Bei PHP gibt es für jedes Framework seine eigene Coding-Convention.

Hä? Ach ja! Und es gibt auch PSR (1 und 2 sind für Style da). PSR ist Scheisse! Bei Klassen und Funktionen werden die öffnenden geschweiften Klammern in die nächste Zeile gerückt. Bei ifs und Schleifen in die gleiche Zeile. Bei Funktionsaufrufen macht man die oeffnende Klammer ohne Leerzeichen hinter dem Funktionsnamen. Bei ifs und Schleifen (egal ob for, foreach, while) macht man ein Leerzeichen vor die öffnende Klammer. Was für ein inkonsistenter und unübersichtlicher Mist! Konfiguriert nur ein Kollege in der Firma seinen Editor falsch, hat man Chaos. Und dieses soziale Problem technisch zu lösen, ist sehr nervig.

Und dann ist da noch die Sprache PHP selbst. Ursprünglich entwickelt als Template-Sprache, wurde inzwischen so viel an der Sprache rumgefummelt um sie irgendwie professioneller zu machen.

Man konnte in dieser Template-Sprache plötzlich auch auf Datenbanken zugreifen.

Und dann kamen die Jungs von Zend.

Zeev und Andi dachten sich, dass es scheinbar eine total tolle Idee sei, den eh schon laxen Programmierern das Leben zu erleichtern. Sie dachten sich, dass man den alten Funktionsnamen, die alle klein und mit Unterstrichen geschrieben wurden, eine CamelCase-Syntax für die objektorientierten Sachen hinzufügen könnte. Die Funktionsparameter waren eh schon in einer zufälligen Reihenfolge, also hat man dann mit einer neuen Version diese Fehlentscheidungen gar nicht erst behoben, sondern einfach weitergemacht wie bisher.

Namespaces

Wer zur Hölle war da eigentlich besoffen als die Namespaces auf der Tagesordnung standen? Bei Java setzt man einfach noch einen weiteren Punkt vor den Namen (namespace.localname). Das ist eh deren Syntax. Bei C++ nimmt man ähnlich wie beim statischen Methodenaufruf noch einen weiteren doppelten Doppelpunkt (namespace::localname). Aber ein Backslash? Ein typisches Escaping-Zeichen? Echt mal!

Model, Controller und View in einem

Hier macht PHP meines Erachtens die meisten Fehler. Für so manchen Entwickler sind ja Design Patterns (nein, ich meine keine Photoshop-Vorlage!) ein Fremdwort. Andere halten es für veraltete Weisheiten. Aber MVC gehört zu den Dingen, bei denen mir oft die Nackenhaare hochstehen, wenn ich mir so manchen PHP-Code anschaue: Da werden in der einen Zeile Datenbank-Abfragen gemacht und in der nächsten Zeile nach der for-Schleife steht direkt HTML. Danach kommt dann wieder ein if mit Abfragen, ob im $_GET oder $_POST irgendwelche Werte stehen - man also Controlling-Mechanismen abbildet.

Die Pflege eines Projekts in solcher Form möchte niemand übernehmen, der bei klarem Verstand ist.

Die Datenbank-Konnektoren sind doof

Wenn ich mich in PHP mit einer Datenbank verbinden will, brauche ich viel Hoffnung. Nehmen wir mal MySQL als beliebteste PHP-Datenbank. Es gibt diverse Möglichkeiten, mich damit zu verbinden:

  • mysql_* Methoden: sind seit PHP 5.5 als deprecated markiert und werden irgendwann ganz entfernt. Alte große Projekte, die darauf aufbauen, werden zukünftig also ihre PHP-Version nicht upgraden können
  • mysqli_* Methoden: man hat irgendwie versucht, die mysql_* Methoden objektorientiert zu bekommen und pflegt dann diesen Baum weiter. Aber auch nicht ausschließlich objektorientiert. Wäre ja echt uncool, mal etwas richtig zu machen
  • ODBC: Oh mein Gott, muss ich wirklich schreiben, warum das keine schnafte Idee ist?
  • PDO: Nachdem ODBC ja so ein Windows-Ding war, musste man was plattformübergreifendes haben, mit dem man angeblich transparent die Datenbank wechseln kann. So es denn Konnektoren gibt. Mit MySQL ist es recht einfach. Das wurde alles implementiert, aber will ich mein PHP selbst kompilieren um eigene Konnektoren hinzuzufügen und es dann auf 100 Server verteilen?

Schauen wir uns doch mal an, wie es Go macht:

	import (
	  "database/sql"
	  _ "github.com/go-sql-driver/mysql"
	)

	db, err := sql.Open("mysql", "user:password@/dbname")

Was machen wir hier? Wir importieren zuerst mal das SQL-Paket, welches Go grundsätzlich mitbringt. Danach importieren wir den Konnektor, eine in Go geschriebene Version des Konnektors - am Ende reden wir hier ja auch nur von ein paar Binärdaten, die da durch eine Connection geschoben werden. Wenn mir der Konnektor nicht zusagt, importiere ich einen anderen. Ich muss ja nichts weiter ändern als diese Import-Zeile. Der Rest wird durch das SQL-Package geregelt.

Wenn man die Datenbank ändert, hat man in jeder Sprache den Aufwand, dass die SQL-Statements anders sind. Das kann man nicht anders lösen, aber die Einbindung einer Datenbank geht einfacher.

Alles wird immer wieder wiederholt

Bei jedem Start, bei jedem Request - es wird immer alles von vorne gemacht. So ist das mit Scriptsprachen, die nicht kompiliert sind. Nicht nur bei PHP. Man stelle sich vor, man hat einen wirklich schlimmen Wulst aus XPath-Anweisungen. So um die 300+ Stück.

In Script-Sprachen wird der XPath-Ausdruck mit jedem Aufruf neu geparsed und kompiliert, um angewandt zu werden. Hat man nur Prozesse einer Software, die die Anfragen beantwortet (z.B. einen Server lokal, dem über FCGI die Anfragen weitergeleitet werden), wird das Parsen und die Kompilierung einmal gemacht und nur angewendet. Am Ende kann man damit ca. die 10- bis 10.000-fache Menge an Requests verarbeiten.

RAM-Management ist eine Seuche

Möchte man große Datenmengen verarbeiten und gerne auch mal was im RAM behalten, ist vor allem PHP wirklich schlimm. Da wird bei der DOMisierung eines 500 MB XML-Files auch mal 4 GB RAM verbraucht. Und man kann eben nicht alles mit Stream-Parsern erledigen.

Der schlechte Einfluss durch Java

Meist findet man ja in einer Firma Programmierer für Java und für PHP. Die Javaner werden besser bezahlt (weil man Java an der Uni lernt und nicht im Keller). Die PHPler wollen dann auch soviel Geld also schreiben sie wie Java, statt die Stärken ihrer Sprache zu nutzen.

Damit kombinieren Sie dann die Nachteile beider Sprachen. Also langsam UND kompliziert statt schnell und simpel.

Siehe dazu diverses Tooling, dass nochmal Annotations und Kommentare live nachverarbeitet: Das macht den langsamen Interpreter mittels Reflection gleich noch eine Ecke langsamer. Java braucht sowas, weil es nicht dynamisch typisiert ist. PHP eigentlich nicht.

Komplexe Anwendungen für Admin-Tätigkeiten

Wenn man in einem Verzeichnis und all seinen Unterverzeichnissen mal alle Dateien umbenennen möchte und keine Shell-Scripte bauen kann und schon ein PHP-CLI installiert ist, dann mag das alles noch okay sein. Mir begegnen aber immer häufiger Scripte, die dann unzählige Abhängigkeiten zu ganzen Frameworks haben. Da ist dann alleine schon das Deployment ein Schlag ins Gesicht. Diese Eigenschaft teilt sich PHP aber mit sehr vielen anderen Scriptsprachen.

Ein Single-Binary ist da schon ein Segen.

PHP muss und will mithalten

Anfangs von Entwicklern anderer Sprachen eher belächelt, hat PHP immer mehr User bekommen. Das ist natürlich auch der heutigen Kultur geschuldet, dass alles irgendwie schnell gehen muss und man mal eben kurz was hinkotzen muss. "Wir müssen da ein System auf die Beine stellen. Das muss nächste Woche fertig sein. Wie, in ProgrammierspracheX dauert das 14 Tage? Kannst du das nicht mal eben in PHP machen? Wir machen das dann irgendwann ordentlich."

So oder ähnlich läuft es oft. Und aus irgendwann wird nie. Und aus hingeflanschten Systemen werden nach Jahren Projekte, bei denen es nur 2 von 25 Entwicklern gibt, die da komplett durchsteigen. Und wenn dann doch jemand mal den Hammer in die Hand nimmt, wird die nächste Version völlig over-engineered, da PHP ja inzwischen viel mehr Möglichkeiten bietet.

Das Problem der meisten PHP-Entwickler: Sie hören auf Userwünsche statt die Sprache schneller und stabiler zu machen. Da werden nämlich dann Wünsche nach anonymen Funktionen laut, die man von JavaScript kennt. Oder Traits, weil jemand mal gehört hat, dass man Mehrfachvererbung braucht.

One language to rule them all! Not.

Das alles in einer Templatesprache. Vor 15 Jahren, als die erste große Dotcom-Blase kam, nannten sich Leute, die HTML geschrieben haben "Programmierer". Danach hat man Templates geschrieben, um HTML dynamisch auszugeben. Die nennen sich heute Programmierer. Jede Sprache hat seine Vorteile und seine Einsatzgebiete. Man versucht PHP zu einer Universalsprache zu machen und die Entwickler der Sprache leiden unter Featuritis.

Was ich versuche auszudrücken: PHP ist eine gute Sprache, wenn man HTML dynamisch ausgeben/generieren möchte. Aber diese Fähigkeiten gilt es zu optimieren und kein halbes Betriebssystem drumherum zu schrauben.

Warum ich das Error-Handling in Go mag

06.09.2014 15:12

Immer wieder lese oder höre ich, dass Go-Anfängern dieses ständige

if err != nil

nicht gefällt. Selbst auf dem sehr lustigen Vergleich If programming languages were weapons kam dieser Punkt auf:

Ich bin da eher der Meinung, dass man falsch an die ganze Sache ran geht, wenn man das so sieht. Fangen wir doch mal an, mit anderen Lösungsansätzen zu vergleichen.

try-catch-Blöcke

Seit es PHP5 gibt, sind try-catch-Blöcke in PHP möglich und erfreuen sich großer Beliebtheit. In Java gibt es das natürlich schon länger und selbst Python hat Exceptions.
Leider gibt es grad in der Scriptsprachen-Welt sehr viele Hohlbirnen, die der Meinung sind, es sei total knuffig, einfach um alles in der main()-Methode ein try mit entsprechend generischem Catcher zu setzen.
Einfach alles abzufangen und in den eigentlichen aufrufenden Methoden immer davon auszugehen, dass sich schon der äußere Catch drum kümmern wird, dass zumindest eine Fehlermeldung ausgegeben wird, kann man schon so machen, ist aber leider sehr kurz gedacht und führt z.B. bei Web-Applikationen dazu, dass man nicht eine spezifische Meldung sieht, was grad gegen die Wand gefahren ist, sondern ein Error 500 oder ein "An error occurred" - das führt dann gerne dazu, dass Menschen Bescheid sagen, dass die Webseite nicht funktioniert.

$ok-Variablen

Es geht natürlich noch besser. Ganz ohne spezielle Fehlerbehandlung. Man schleift einfach durch die gesamte Software ein $ok (mit oder ohne Dollarzeichen hängt jetzt einfach mal von der Sprache ab). Sobald ein Fehler auftritt, setzt man diese dann auf false und schon weiss der Rest des Programms, dass er so nicht weiterarbeiten darf. Warum genau nicht und was vielleicht noch zu tun ist (DB-Connection schließen, Schreibvorgänge finalisieren), hat dann den Rest auch nicht zu interessieren.

if err != nil

Ich muss gestehen: Als ich mit Go anfing, fand ich das ziemlich komisch. Die Methoden hatten multiple Rückgabewerte und oft war der zweite vom Typ error.
Go beschwert sich selbstverständlich auch, wenn man multiple Rückgaben hat, aber nur eine Variable zuweist.

Nehmen wir also folgende Beispielmethode:

func Foo() (string, error) {
	return "bar", errors.New("My Error")
}

Was also nicht geht:

func main() {
	bla := Foo()
}

Es muss lauten:

func main() {
	baz, err := Foo()
	if err != nil {
		// Error Handling
	}
	fmt.Print(baz)
}

Oder man entscheidet sich wirklich explizit dafür, den zurückgegebenen Error zu ignorieren:

func main() {
	baz, _ := Foo()
	fmt.Print(baz)
}

Aber genau das ist der Punkt: Man muss sich explizit dafür entscheiden, genau diesen Fehler zu ignorieren oder ihn eben weiter zu verarbeiten, zurückzugeben oder was auch immer. Das zwingt den Entwickler dazu, sich aktiv damit auseinanderzusetzen, was als nächstes passiert oder was passieren könnte.

Ich mag das.

1