mijane Blog - Kommentare

Anonym: Versteckte SVN Ordner löschen

nospam@example.com () — Mon, 27 Sep 2010 08:40:15 +0200

find /pfad/zum/git/repository/ -type d -name ".svn" -exec rm -rf '{}' \;

Gecko: Magische Methoden

nospam@example.com (Gecko) — Sun, 28 Mar 2010 15:13:17 +0200

Kurz & knackig - Schöne Zusammenfassung.

Ein sehr ausführliches Tutorial zu den magischen Methoden von PHP und dessen Verwendung findet man zudem unter:

http://www.freaky-scripts.de/2010/03/27/tutorial-magische-methoden-in-php-klassen-interzeptoren/

Toby: Singleton sucks

nospam@example.com (Toby) — Wed, 25 Nov 2009 23:21:19 +0100

Das gravierendste Problem am Singleton: Es ist nicht anständig unit-testbar. Unit tests basieren darauf, dass einzelne Testfälle ganz und gar unabhängig von einander ausgeführt werden. Ruft dabei eine Methode das Singleton an, kann hier weder Code als Mocking injiziert werden, noch ist es möglich das Singleton-Objekt selbst in 2 Testfällen unabhängig von einander zu testen. Um mit einem Singleton halbwegs anständig zu testen, muss immer eine statische Methode ala setInstance() eingeführt werden, mit deren Hilfe sich das Singleton-Objekt austauschen lässt. Damit ist es aber kein Singleton mehr sondern letztendlich schon eine Registry. Ergo sollte man direkt auf Singletons verzichten und auf Registries setzen, sollte der Fall wirklich gegeben sein nur eine Instanz von einem bestimmten Objekt haben zu wollen. Damit bleiben auch OOP-Grundsätze wie Erweiterbarkeit gewahrt, denn in der Registry kann auch ein erbendes Objekt eingetragen werden.

Dominik Jungowski: Singleton sucks

nospam@example.com (Dominik Jungowski) — Wed, 25 Nov 2009 22:51:02 +0100

Naja, sofern man keine Klone oder dergleichen braucht, kann man Singleton-Funktionalität auch mit einer statischen Klasse erreichen (ich hoffe ich red grad kein Bullshit, aber es ist schon spät )

Philipp: Fluent Interface

nospam@example.com (Philipp) — Thu, 22 Oct 2009 08:41:53 +0200

Hi Peter,

ein solches Fluent Interface wie du es im Beispiel zeigst sieht auf den ersten Blick einfach aus zu realisieren aber schaut man genauer hin wird es schon ein wenig schwieriger. Was ist wenn du den Aufruf einer Methode wie z.B. "year()" nur einmal zulassen willst. Andernfalls könnte der Benutzer des Fluent Interface die Methode mehrfach in der Methodenkette aufrufen was dazu führt, dass wir uns nicht mehr sicher sein können welcher der Aufrufe am Ende im Ergebnis landet. Das ist nur ein Beispiel von vielen.

Wie du bin ich der Meinung, dass dieses Pattern die Benutzung von APIs enorm vereinfachen kann. Aber nur dann, wenn das Fluent Interface die Autovervollständigung soweit nutzt, dass nur die Methoden angezeigt werden die zu einem bestimmten Punkt in der Methodenkette erlaubt sind. Um das zu ermöglichen, muss du nach jedem Methodenaufruf einen neuen Typen zurückliefern, der auch nur die entsprechenden Methoden anbietet. Wir benötigen also ein Netzwerk von Typen um eine Art Grammatik zu realisieren und das kann je nach Fluent Interface sehr aufwendig sein.

Für meine Bachelorarbeit habe ich mich damals sehr intensiv damit auseinander gesetzt und ein Plugin (für Eclipse) erstellt mit dem es möglich ist diese Netzwerke als Diagramme zu modellieren, um daraus sofort den nötigen Code generieren zu können. Damit vereinfacht man das Erstellen von Fluent Interfaces enorm.

Schau mal einfach unter http://www.fluent-interfaces.com nach.

Der Philipp

Peter Rother: Spike-Solution des OXID eShops + Zend Framework verfügbar

nospam@example.com (Peter Rother) — Sat, 26 Sep 2009 19:36:25 +0200

Hallo Werner,

das sehe ich genau so wie du. Natürlich sollte OXID nicht probieren, auf biegen und brechen alle verfügbaren Komponenten mit aufzunehmen. Ich glaube die von mir bereits angesprochenen Teile sollten schon einmal vieles von dem was benötigt wird abdecken. Ich werde mir mal ein paar Gedanken dazu machen, was noch nützliches von dem Zend Framework, Einzug in den OXID Shop finden könnte.

Ein großer Vorteil bei einer Umstellung wäre natürlich auch, dass third Party Entwickler auf ein großes Spektrum an bereits vorhanden Komponenten zurück greifen könnten. Somit würde die Entwicklung neuer größerer und komplexerer Module mit Sicherheit um einiges leichter.

Für mich wäre auch noch wichtig, dass man eine vernünftige API zur Verfügung stellt, um auch von anderen Systemen aus mit dem Shop kommunizieren zu können.

Werner: Spike-Solution des OXID eShops + Zend Framework verfügbar

nospam@example.com (Werner) — Fri, 25 Sep 2009 23:58:35 +0200

Eine Entwicklung von kommerzielle sowie Open Source Software in Richtung Zend Framework befürworte ich sehr und finde es auch sehr interessant. Das ZF ist in vielerlei Hinsicht zum führenden Framework in der kommerziellen Entwicklung von Webanwendungen geworden.

Ich denke dass sich da OXID eShop sich selber und den Entwicklern von Modulen und Komponenten einen großen Gefallen tut. Habe selbst nun einige Applikationen mit ZF entwickelt, und kann nur sagen dass die Entwicklung mit ZF wirklich Freude bereitet. Dadurch dass es komponenten-basiert ist, kann man viele Klassen auch in kleineren Projekten einsetzen ohne gleich das ganze Anhängsel mitbenutzen zu müssen.

Die Gefahr die ich darin sehe ist dass das zu einem Mammut-Projekt wie Magento mutieren könnte. Die Idee den Shop auf einem bestehenden, soliden Framework aufzubauen, welches die Arbeit den Entwicklern erleichtern soll ist gut, aber bitte auch gut dokumentiert, ressourcen-schonend und einfach in der Handhabung.

Peter Rother: 20 Tips für schnelleren PHP Code

nospam@example.com (Peter Rother) — Wed, 15 Jul 2009 12:46:17 +0200

Hi Sebastian,

erstmal sorry das ich deinen Beitrag erst jetzt frei schalte, ich war aber die letzten Tage Privat nicht vor dem Rechner. Da ich gerade im Büro sitze, und hier noch einiges zu tun habe, werde ich dir die Fragen gerne heute Abend beantworten.

-Sebastian-: 20 Tips für schnelleren PHP Code

nospam@example.com (-Sebastian-) — Sun, 05 Jul 2009 04:18:21 +0200

Hi,
bin gerade auf die Seite gestoßen und will erstmal ein Lob loswerden, hab doch ein paar interessante Sachen gefunden.
Zu deiner obigen Liste und zu dem Kommentar von unset hab ich allerdings doch noch ein paar Fragen, hoffe der Artikel ist noch nicht zu alt, das die auch jmd. mitbekommt.

Bin noch nicht lange im Thema PHP drin, daher schonmal ein 'Tut mir Leid' vornweg, wenn einige Anfängerfragen dabei sind

zu 3. Sind damit generell alle Variablen gemeint? Angenommen ich durchlaufe eine for Schleife und habe dafür den Index $i, sollte ich diesen am Ende der Schleife zerstören? Was genau macht PHP langsamer wenn ich ihn nicht zerstöre, belegt die Variable nicht nur den Speicher? Wie siehts bei Beendigung des Skriptes aus? Werden dann alle Variablen automatisch zerstört?

zu 6. Kann mir grad kaum vorstellen wie durch den relativen Pfad die Geschwindigkeit nach unten gehen soll?! Bringt das tatsächlich signifikante Unterschiede?

zu 12. Baue die Verbindung am Anfang des Skriptes auf, wird dann auch direkt gebraucht, und zwischendurch auch immer wieder und erst am Ende des Skriptes schließe ich sie (wobei ich nicht weiß ob sie nicht auch automatisch nach Ablauf des Skriptes geschlossen würde). Macht es Sinn die zwischendurch zu schließen/öffnen, nur weil dazwichen mal ne Schleife etc. pp. steht?

bzgl. dem Kommentar von unset:
Die Verwendung von Delimitern in Arrays, wie genau ist das zu verstehen. Benutze eigentlich nur numerische Indizes, brauch ich die da auch? Also nicht $array[0] = 1 sondern $array['0'] = 1 ?

Peter Rother: Friend of a Friend

nospam@example.com (Peter Rother) — Thu, 18 Jun 2009 14:46:19 +0200

Hallo Ludwig,

ich werde spätestens am Wochenende mal den Return Wert hier einstellen, ist momentan ein bißchen Stressig.
Wäre aber super wenn man hier noch etwas optimieren könnte. Schon einmal Danke für den Hinweis.

Gruß
Peter