Auf Wunsch und zur Frustbewältigung eines einzelnen hier nicht genannten Freunds der Familie und glühenden St. Pauli Verehrers: http://www.schubert-raus.de

Für mich mit dem angenehmen Seiteneffekt, mal Bootstrap und Silex einem Praxistest zu unterziehen und auf ihre RAD Fähigkeiten hin zu überprüfen. Den Test hat das Gespann auf jeden Fall bestanden, einmal Lübeck – Hamburg und zurück mit der Bahn und fertig.

Und wer weiß, vielleicht baue ich dem Herrn Yildirim, seines Zeichen Trainer beim VfB Lübeck, auch gleich eine Seite, da siehts im Moment auch nicht besser aus :-).

Fussball, die zweitschönste Nebensächlichkeit der Welt.

Ich weiß, das wissen wir alle schon länger, aber ich durfe gerade eine svn Workingcopy unter Linux auschecken, nur um einen Symlink anlegen zu können und diesen anschließend auch ins Repository commiten zu können.

Darüber ob Symlinks im svn gut sind läßt sich sicher streiten, aber manchmal muss es eben doch sein und frei nach Monty Python möchte ich einfach die prinzipielle Möglichkeit haben Babies zu bekommen, äh ich meine natürlich Symlinks anlegen zu können.

So, jetzt geht’s mir schon ein wenig besser :-)!

Auch wenn es gestern Abend in dem Vortrag von Pierre Minnieur bei der Symfony Usergroup Hamburg im wesentlichen um das Thema „Bundles are not Plugins“ ging, hab ich dort für mich einen ganz anderen Aspekt mitgenommen, der meiner Meinung nach häufig von Entwicklern vergessen wird, die sich im wesentlichen in einer Frameworkwelt, sei es Symfony, Zend, Flow3 oder was auch immer, bewegen.

Routiniert packt man seine Funktionen in z.B. Symfony Bundles, nutzt die dort vorgegeben Methoden der Vererbung, Strukturierung, etc. und verwendet bestenfalls diese Bundles sogar in mehr als einem Projekt. Bis hier hin eine schöne Welt! Aber was passiert, wenn ich wesentliche Funktionalitäten aus meinem Bundle nun in einem Zend Projekt verwenden will?

Man merkt, eigentlich haben wesentliche Codebestandteile aber so gar nichts in einem Bundle zu suchen, sondern sind für eine gute Wiederverwendung viel besser in einer eigenständigen Library aufgehoben. Nun ist lediglich ein schlanker „Wrapper“, im Falle Symfony ein Bundle, nötig, welches die Funktionalität der Library in den Kontext des Frameworks hebt. Der Code, der sich an ein spezielles Framework bindet, ist deutlich reduziert und die Library wird hoffentlich häufiger wiederverwendet, da diese mit geringem Aufwand auch in anderen Frameworks einfach eingebunden werden kann.

Wesentlicher Grund gegen so ein Vorgehen mag in der Vergangenheit das Fehlen, bzw. die fehlende Akzeptanz von Werkzeugen wie Composer gewesen sein. Mit Composer und Packagist scheint sich in der PHP Welt so langsam eine Entsprechung von Maven und Apache Commons durchzusetzen, so dass zu hoffen bleibt, dass wir bald alle einfach und schnell tolle Libraries in unseren Lieblingsframeworks benutzen können.