Seltsamer Fehler nach Update von Doctrine

Beim Update von Blogscout.de habe ich gerade folgende Fehlermeldung erhalten:
Catchable Fatal Error: Object of class MEINE_KLASSE could'not be converted to string in PFAD/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php line 1211
Bei Google habe ich zu dieser Fehlermeldung nichts gefunden, nach einer Weile bin ich dann aber drauf gekommen, wo der Hase im Pfeffer lag.

So sah der Code aus, der letztendlich zum Fehler führte:

return $this->getEntityManager()
    ->createQuery(
        'SELECT a
         FROM BlogscoutMainBundle:Article a
         WHERE a.blog = :blog
         ORDER BY a.createdAt DESC'
    )
    ->setParameter('blog', $blog);

$blog ist eine Entität, die ich der Funktion übergebe und zwischen einem Article und einem Blog besteht eine Many-To-One-Relation. Bisher hat das so immer funktioniert, seit dem neusten Update erkennt Doctrine aber wohl nicht mehr, dass $blog eine Entität mit entsprechender Relation und Primary-Key ist.

Es kann sein, dass das nur ein vorübergehender Fehler ist (ich bin auf dem dev-Branch), folgendes brachte aber die Lösung:

->setParameter('blog', $blog->getId());

Vielleicht stösst der eine oder andere ja auch auf den Fehler und weiß erst einmal nicht, wie damit umzugehen ist.

Aufruf zu mehr Mitarbeit

Jeder Entwickler kennt Stackoverflow. Wer es noch nicht kennt, sollte es sich schleunigst anschauen. Aber eigentlich gibt es kaum eine Chance, bei Fragen zur Entwicklung an Stackoverflow vorbei zu kommen. Bei fast jeder Googlesuche zu entsprechenden Fragen tauchen Suchergebnisse von Stackoverflow (zurecht) ganz weit oben auf.

Bislang war ich ein passiver Nutzer: kein Benutzerprofil, keine Fragen, keine Antworten. Gestern Abend habe ich das mal geändert (stackoverflow.com/users/2096166/dirk-olbertz) und ich kann jedem nur empfehlen, es auch zu tun. Nicht nur helft ihr damit anderen, aber man lernt selbst sehr viel.

Zum Beispiel bei dieser Frage hier und meiner Antwort dazu: string position and substring get in php. Meine Antwort war soweit korrekt (ein Beispiel für preg_match_all), aber fast zeitgleich ging eine Antwort ein, die statt dessen DOMDocument nutzt. Ich kenne diese Methoden und nutze sie selbst, allerdings wäre ich nie auf die Idee gekommen, die Frage so zu beantworten. Obwohl sie die schönere war. Vielleicht war sie sogar für den Fragenden zu komplex, aber im Sinne eines guten PHP-Programmierers war meine Antwort maximal die zweite Wahl.

Und noch ein Beispiel, zu dem ich jetzt leider keinen Link habe, da ich meine Antwort nicht eingeschickt habe. Denn während ich meine Antwort formulierte, kam eine wesentlich bessere Antwort zu Frage rein. In der Frage ging es grob darum, dass jemand das letzte Element eines Arrays bekommen wollte (PHP). Er hatte sich etwas unglücklich ausgedrückt und dazu noch Beispielcode mit einer foreach-Schleife angegeben, so dass man eh nicht genau wusste, was man antworten soll. Ich hatte dann angefangen zwei Alternativen aufzuschreiben. Eine mit array_pop() und dann noch eine mit $element = $array[count($array)-1]; und den Anmerkungen, was die beiden Lösungen jeweils für Einschränkungen haben. Und dann kam die Antwort mit dem simplen Hinweis auf die Methode end(). Die kannte ich gar nicht und habe mich selbst immer mit meinen umständlichen Lösungen beholfen. Wieder was gelernt!

Insgesamt ist es nicht leicht Fragen zu beantworten. Oft sind die Fragen unvollständig und vage formuliert, oder man möchte eigentlich ganz davon abraten etwas so zu machen, wie es der Fragende gerade vorhat. Zum Beispiel bei den ersten Gehversuchen von PHP-Neulingen, die eine view.php und eine insert.php haben und fragen wie sie es vermeiden können, dass Leute die insert.php immer wieder aufrufen. Der möchte hier eine simple Antwort auf eine sehr komplexe Frage haben. Wie soll man so etwas beantworten?

Ich werde jetzt jedenfalls regelmäßig abends mal reinschauen, welche „Low-Hanging-Fruits“ ich beantworten kann. Und dann gibt es noch ein paar Fragen, für die Belohungen in Form von Erfahrungspunkten vergeben werden. Hier ist klar, dass es meist keine einfache Lösung gibt. Auch hier will ich mich mal öfter umschauen und mich mit einer Frage vielleicht auch länger beschäftigen.

Für alle Nicht-Entwickler gibt es das selbe Prinzip von Stackoverflow auch für dutzende andere Themengebiete: stackexchange.com/sites – einfach mal reinschauen. Vielleicht ist ja etwas für euch dabei. Für mich ist das nicht nur zum Helfen, sondern auch zum Lernen. Und damit soll man ja bekanntermaßen nie aufhören.

YouTube wird 8. Mein erster Kontakt war kurz nach der Geburt.

Also jedenfalls relativ kurz danach, nämlich am 15. Juni 2005 :) Denn wenn man sich die Geschichte von YouTube anschaut, stellt man fest, dass das erste Video erst im April 2005 online ging.

Etwa zur gleichen Zeit hatte ich mit meinem Projekt Taggling.com (Link zur WayBack-Machine) begonnen, sozusagen ein Tag-Aggregator. Und YouTube hatte zu dem Zeitpunkt noch keine Feeds zu Tags. Also schrieb ich die Jungs an und bekam im kürzester Zeit eine Antwort von Steve Chen. Ein paar E-Mails später gab es dann funktionierende Feeds zu einzelnen Tags von YouTube!

Mein Lieblingszitat aus den Mails von Steve ist übrigens das hier:

So I’m still a bit of a novice on the technical side of RSS. While I’ve been using RSS readers to get my news for over a year now, I haven’t done much on the publishing side.

Mein erstes YouTube-Video stammt vom 14. Juni 2005 und zeigt das Öffnen eines der Tore bei der Eröffnung von „The Gates“ von Christo:

Eine unglaublich schlechte Qualität, aber damals eine Sensation. Videos im Internet! Heute nicht mehr ohne vorzustellen.

Sollte man target=“_blank“ noch mal eine Chance geben?

Ich weiß, das ist ein heisses Pflaster auf das ich mich da begebe. Zum einen ist das Attribut nicht XHTML-Strict und zum anderen ist es ja in der Tat sehr lästig, wenn man beim Surfen andauernd neue Fenster/Tabs aufgemacht bekommt. Besonders ärgerlich ist das bei so Müllseiten, die sogar interne Links mit target="_blank" versehen haben.

Die Begründungen sind einleuchtend und für den versierten Internetbenutzer geht das „Öffnen in einem neuen Tab“ genauso leicht von der Hand wie ein normaler Klick auf einen Link. Aber wie sieht das bei mobilen Browsern aus? Ich glaube, ich kann die Zahl der länger halten bis das PopUp aufgeht und dann „In neuem Tab öffnen“ antippen locker an einer Hand abzählen.

Je nach Zielgruppe einer Website (mobile und nicht so internetaffin) sehe ich da ein target="_blank" gar nicht als das schlimme Übel an. Es kann tatsächlich für beide Seiten ein Gewinn sein: den Seitenbetreiber und den Surfer.

CSS-Frameworks: Bootstrap / Foundation

Ich bin kein Designer. Ich habe zwar ein ästhetisches Empfinden, kriege es aber nicht auf die Reihe mittels HTML und CSS irgendwas halbwegs anständiges auf die Beine zu bringen. Zu meiner Rettung gibt es CSS-Frameworks wie Bootstrap und Foundation.

Bootstrap war das erste CSS-Framework, dass ich genutzt habe. Und wie es bei so vielen Sachen ist: wenn man zu viel davon benutzt, wird es irgendwann langweilig. Ich habe mich einfach satt daran gesehen. Denn wie ich schon sagte: ich bin kein Designer und kann leider nicht mit ein paar handvoll Zeilen CSS das ganze so anpassen, dass es nicht mehr nach Bootstrap aussieht. Deshalb habe ich mich jetzt für ein neues Projekt mal an Foundation gewagt. Meine Erfahrung mit Foundation ist also noch recht klein, aber für einen ersten Vergleich reicht es.

Bootstrap Fluid

Bootstrap kommt mit einer großen Anzahl an verschiedenen Elementen daher, wobei im Vergleich zu Foundation eher die Zahl der Variationen überwiegt. Und die Dokumentation ist besser. Bei Foundation muss ich immer mal wieder rätseln, wie ein in der Doku angesprochenes Feature wohl umgesetzt wird.

Dafür kommt Foundation mit wesentlich weniger Klassen im Markup aus. So wenigstens mein Eindruck bei der Anpassung des vorher in Bootstrap gebauten Layouts.

Foundation, Rapid-Prototyping

Beide Frameworks basieren auf Grids und sind auf responsive Design ausgerichtet, wobei Bootstrap 3 „mobile-first“ sein wird. Bislang habe ich mich nicht übermäßig mit Anpassungen für mobile Endgeräte gekümmert, aber auf den ersten Blick scheint mir Foundation hier expliziter und damit klarer zu sein, was die Klassennotationen angeht.

Der Umstieg von dem einen Framework zum anderen ist nicht so schwierig, zumindest so lange man noch keine eigenen CSS-Anpassungen vorgenommen hat. Bootstrap scheint mir einfach verbreiteter zu sein, so findet man schneller Beispiele für die Verwendung in diverse PHP-Frameworks. Bei Symfony2 fällt da insbesondere das Form-Theming ins Gewicht. Andererseits sehen meine Formulare beim Foundation-Projekt auch ohne ein spezielles Theme im Moment ganz OK aus.

Verwirrend bei Foundation ist auf jeden Fall, dass deren Website selbst Komponenten benutzt, die nicht im Framework enthalten sind. Ich fand ein paar Elemente der Website nämlich ganz cool und habe versucht diese nachzubauen, bis ich dann feststellen musste, dass die gar nicht in Foundation enthalten sind.

Ich werde das Projekt aber auf jeden Fall mal in Foundation durchziehen. Mal abwarten, auf welche Überraschungen und Probleme ich noch treffen werde.