Design Patterns für Framework-agnostische Extensions/Plugins

Meine neue Artikelreihe auf integer-net.com stellt nützliche Design Patterns für entkoppelte Magento Extensions vor, die in zwei Teile geteilt sind: Das Magento Modul und eine Framework-unabhängige (Framework-agnostische) Bibliothek, die für Magento 1 und Magento 2 wiederverwendbar ist. Die selben Prinzipien sind natürlich auch für weitere Frameworks und Anwendungen anwendbar.

Diagramm: Komponenten und Abhängigkeiten

Sie wird nicht den Refactoring-Prozess von bestehenden Extensions hin zu diesem Modell behandeln, das ist ein anderes Thema, das ich beim Developers Paradise 2016 in Kroatien präsentieren werde. Bleibt dran!

Im ersten Teil geht es um den Zugriff auf Konfigurationsdaten mit Configuration Value Objects.

Weiterlesen auf integer-net.com (Englisch)

Retrospektive: Das Blog 2015

Frohes neues Jahr allen Lesern! Genau wie letztes Jahr starte ich das Jahr im Blog mit einem Rückblick auf 2015 in Zahlen und Fakten und einer Vorschau auf das kommende Jahr. Da meine paar Stammleser wohl größtenteils deutschsprachig sind, mache ich mir diesmal allerdings nicht die Mühe, ihn zweisprachig zu verfassen.

Sorry, my non-German friends!

Zahlen

Die Besucheranzahl ist gegenüber 2014 von 12.091 auf 20.713 gestiegen, über die Monate aber verhältnismäßig konstant geblieben:

Visits per month 2015

Die meisten Besucher kommen weiterhin von Google und über Direktzugriffe:

# Herkunft Besucher Besucher 2014
1 Google 10011 4371 (+0)
2 direkt 5997 4289 (+0)
3 StackOverflow 985 754 (+1)
4 Twitter 772 54 (+7)
5 Reddit 516 1357 (-2)

Meine Reichweite auf Twitter hat sich klar erhöht, dafür gab es dieses Jahr kein kontroverses Thema für Reddit 😉

Meistbesuchte Artikel

Die Top Ten 2015 über alle Artikel, inklusive ältere, sieht diesmal so aus:

# Titel Englisch Deutsch Total
1 (+1) PHP: “Mocking” built-in functions like time() in Unit Tests (2011) 3709 214 3923
2 (+10) Magento Bündelprodukte: Staffelpreise der einfachen Produkte nutzen (2014) 957 600 1557
3 (+6) Das Magento buyRequest Objekt – eine Referenz (2014) 1099 231 1330
4 Spryker vs. Magento 259 1025 1284
5 Effizient zufällige Elemente aus großem PHP Array ziehen 544 609 1153
6 Zufällige Produkte in Magento anzeigen 448 639 1087
7 Comparable Interface für PHP 611 124 735
8 (+18) Magento Tutorial: Wie man Increment Models nutzt, um IDs zu generieren (oder SKUs) (2014) 605 112 717
9 (-8) Warum ich aktiv PHP 5.3 Kompatibilität aufgeben werde (2014) 413 291 704
10 Meine Checkliste bei der Analyse von Magento Shops 284 413 697

Nur die Hälfte sind tatsächlich neue Artikel, da sich einige von 2014 dauerhafter Beliebtheit erfreuen.

Hot Topics

Unit Testing

Spryker

Das neue E-Commerce Framework für den Enterprise Bereich war ein spannendes Thema und der Artikel “Spryker vs. Magento”, den ich auch auf magenticians.com veröffentlicht habe, einer der meistgelesenen des Jahres.

Shop Analyse

Ein weiterer Artikel, der auch auf magenticians.com erschienen ist, ist meine “Checkliste bei der Analyse von Magento Shops”. Die zugehörige Toolbox ist mittlerweile mein Projekt mit den meisten Sternen auf GitHub. Beides wurde im Blog Post von Firebear Studio zum selben Thema empfohlen, ergänzt mit anderen hilfreichen Tools.

Ziele erreicht?

Anfang des Jahres schrieb ich:

Für 2015 ist der Plan, die Geschwindigkeit mit im Schnitt mindestens einem echten Blog Post alle zwei Wochen beizubehalten.

Den Schnitt habe ich mit 28 Artikeln insgesamt gehalten, wenn ich die Kurz-Tipps zum Testing mitzähle, aber zugegeben in der zweiten Jahreshälfte etwas nachgelassen.

Jan Feb Mär Apr Mai Jun Jul Aug Sep Okt Nov Dez
3 4 8 1 4 2 1 🙁 2 1 1 1

Weiterhin möchte ich einige der alten Artikel übersetzen, die immer noch gefragt aber nur in einer Sprache verfügbar sind.

Das war dann einfach nicht wichtig genug für den Aufwand den es gekostet hätte. Blöder Vorsatz, wird auch nicht in 2016 übernommen 🙂

Ich erweitere das mal um ein paar verifizierbare Vorsätze für 2015:

  • Blogging wie geplant fortsetzen

Check, abgesehen von den Übersetzungen, siehe oben.

  • Auf einer Konferenz sprechen

Check, mein erster Vortrag vor größerem Konferenzpublikum: Pragmatisches Unit Testing (Meet Magento DE, Link geht zu Youtube).

  • Mehr zu Open Source Software beitragen

Mein Github Account zeigt zumindest einige Pull Requests und ich habe ein paar eigene Tools veröffentlicht:

  • DebugErrors: Liefert mehr Informationen zu einigen unspezifischen Fehlermeldungen von Magento
  • AclReload: Fügt einen “Reload ACL” Menüeintrag zum Magento Admin Panel hinzu, der das aus- und wieder einloggen nach dem installieren von Extensions ersetzt
  • TranslationHints: Zeigt Herkunft von Übersetzungen in Magento
  • Comparable PHP Package: Eine alte Bibliothek, die ich komplett nach modernen Methoden neu geschrieben habe, und die ein Comparable interface für PHP bereitstellt, mit Sortier und Vergleichs-Funktionen. Addons: comparable-filesystem, comparable-arrays. Vermutlich benutzt es niemand außer mir, aber es war eine gute Fingerübung
  • SGH_JsonRpc: Ein JSON-RPC API Adapter für Magento
  • IntegerNet_AttributeOptionPager: Ein Magento-Modul, das die Verwaltung von Attributen mit sehr vielen Optionen ermöglicht
  • Eine neue Version des IntegerNet_Anonymizers, noch ohne stable release.
  • Hackathon_DerivedAttributes: Ebenfalls noch kein stable release und vor allen Dingen undokumentiert, für einige Spezialfälle aber schon im Produktiveinsatz. Definitiv noch ein TODO für 2016
  • Einen neuen Service auf den Markt bringen

Das war wohl nichts, um das Thema hülle ich lieber den Mantel des Schweigens.

So, jetzt ist es öffentlich und ich muss mich in einem Jahr rechtfertigen.

3 von 4 Punkten erfüllt, damit kann ich leben.

Und 2016?

Mit meiner Firma SGH bin ich still und heimlich ins Magento Extension Business eingestiegen. 2016 soll zeigen, ob es sich lohnt, dafür fehlt allerdings noch Website, schöne Bilder und Marketing Content.

Im April bin ich in Kroatien auf dem Developers Paradise mit einem Vortrag zu Magento 2 im weitesten Sinne vertreten. Das Thema wird 2016 auf jeden Fall mit beherrschen, und ich werde mich intensiver damit befassen als bisher.

Mit Vorsätzen für 2016 halte ich mich ansonsten etwas zurück, wer weiß was das Jahr noch bringt.

Nur eins noch: Beim Aachener Firmenlauf im Oktober bin ich wieder mit integer_net dabei, dieses Jahr dann die 9,6 km Runde. Bis dahin heißt es: Mehr Sport!


Titelbild: Ellen Steiof (CC BY-NC-ND 2.0)

Warum ich meine Cloud Server zu gridscale umgezogen habe

Seit fast einem Jahrzehnt entwickele ich im Kundenauftrag Software. Meistens handelt es sich um Web-Anwendungen, heute hauptsächlich Online Shops mit Magento.

Lagen meine Online-Entwicklungsumgebungen früher auf dedizierten Rootservern, habe ich vor einigen Jahren zu AWS gewechselt. Wenig verwunderlich war die Flexibilität höher, als die der dedizierten Server von Anbietern wie z.B. hetzner oder server4you.

Continue reading “Warum ich meine Cloud Server zu gridscale umgezogen habe”

EcomDev PHPUnit Tipp #13

Seit Jahren ist das Test-Framework EcomDev_PHPUnit quasi-Standard für Magento Unit Tests. Die aktuelle Version ist 0.3.7 und der letzte Stand der offiziellen Dokumentation ist Version 0.2.0 – seitdem hat sich viel getan, was man leider im Code und GitHub Issues selbst zusammensuchen muss. Diese Serie soll praktische Tipps zur Verwendung sammeln.

Tipp #13: EAV Fixtures beschleunigen

Nutzt man die EAV Fixtures, um Produkte, Kategorien und Kunden für Tests anzulegen, macht der Fixture Processor von EcomDev_PHPUnit vor jedem Test ein Backup der jeweils bestehenden Tabellen und spielt es anschließend wieder zurück. Da die “magento_unit_tests” Test-Datenbank standardmäßig als Kopie der aktuellen Magento-Datenbank angelegt wird, kann das sehr viel unnötiger Overhead sein.

Die EAV-Tabellen in der Test-Datenbank einmalig zu bereinigen, kann Tests, die sonst mehrere Minuten laufen um ein vielfaches beschleunigen. Dazu löschen wir in der Test-DB alle Datensätze in den Main Tables (die verknüpften Attribute etec. werden über Trigger automatisch gelöscht), mit Ausnahme der Standard Root Kategorie:

delete from catalog_product_entity;
delete from catalog_category_entity where entity_id > 2;
delete from customer_entity;

EcomDev PHPUnit Tipp #12

Seit Jahren ist das Test-Framework EcomDev_PHPUnit quasi-Standard für Magento Unit Tests. Die aktuelle Version ist 0.3.7 und der letzte Stand der offiziellen Dokumentation ist Version 0.2.0 – seitdem hat sich viel getan, was man leider im Code und GitHub Issues selbst zusammensuchen muss. Diese Serie soll praktische Tipps zur Verwendung sammeln.

Tipp #12: Cache

Man kann Caches pro Test an- und abschalten, mit den folgenden Annotations:

/**
 * @test
 * @cache on all
 */
public function testWithCache()

/**
 * @test
 * @cache off all
 */
public function testWithoutCache()

/**
 * @test
 * @cache off all
 * @cache on layout
 * @cache on block_html
 */
public function testWithSomeCachesTurnedOn()


/**
 * @test
 * @cache on all
 * @cache off translate
 * @cache off config
 */
public function testWithSomeCachesTurnedOff()

Die Annotations werden in der angegebenen Reihenfolge ausgeführt, wenn man also “all” benutzt, sollte es immer vor allen anderen @cache Annotations stehen.

EcomDev_PHPUnit Tipp #11

Seit Jahren ist das Test-Framework EcomDev_PHPUnit quasi-Standard für Magento Unit Tests. Die aktuelle Version ist 0.3.7 und der letzte Stand der offiziellen Dokumentation ist Version 0.2.0 – seitdem hat sich viel getan, was man leider im Code und GitHub Issues selbst zusammensuchen muss. Diese Serie soll praktische Tipps zur Verwendung sammeln.

Tipp #11: Minimal-Fixtures für Produkttypen

Es folgen einige Beispiel Fixtures für verschiedene Produkttypen. Sie sind so minimal gehalten, dass die Daten gerade ausreichen, um die Produkte und ggf. Produktbeziehungen anzulegen. In den meisten Fällen wird man zusätzliche Attribute wie Name, Status, Sichtbarkeit, Preis und Lagerbestand benötigen.

Continue reading “EcomDev_PHPUnit Tipp #11”

EcomDev_PHPUnit Tipp #10

Seit Jahren ist das Test-Framework EcomDev_PHPUnit quasi-Standard für Magento Unit Tests. Die aktuelle Version ist 0.3.7 und der letzte Stand der offiziellen Dokumentation ist Version 0.2.0 – seitdem hat sich viel getan, was man leider im Code und GitHub Issues selbst zusammensuchen muss. Diese Serie soll praktische Tipps zur Verwendung sammeln.

Tipp #10: Defekte Übersetzungen

Es kann passieren, dass Übersetzungen in Unit Tests nicht funktionieren, wenn man einen Helper mit einem Helper-Mock ersetzt (mit mockHelper() und replaceByMock()), insbesondere im Developer Mode, wo Übersetzungen nur funktionieren wenn sie für das richtige Modul definiert wurden.

Der Modulname wird in Mage_Core_Helper_Abstract mit $this->_getModuleName() ermittelt, also schauen wir uns die Methode einmal an:

/**
 * Retrieve helper module name
 *
 * @return string
 */
protected function _getModuleName()
{
    if (!$this->_moduleName) {
        $class = get_class($this);
        $this->_moduleName = substr($class, 0, strpos($class, '_Helper'));
    }
    return $this->_moduleName;
}

Wenn Deine Helper Klasse Your_Awesome_Helper_Data ist, wird die Klasse des Helper-Mocks Mock_Your_Awesome_Helper_Data heißen. Weil ein Modul namens Mock_Your_Awesome nicht existiert, gibt es keine Übersetzungen.

Lösung

Um Helper Unit-Test-sicher zu machen (und als Nebeneffekt auch Rewrite-sicher), definiere _moduleName explizit:

class Your_Awesome_Helper_Data extends Mage_Core_Helper_Abstract
{
    protected $_moduleName = 'Your_Awesome';
}

Zuerst beschrieben hier: http://magento.stackexchange.com/questions/46255/ecomdev-phpunit-translation-not-working-with-mocked-helper

Meine Checkliste bei der Analyse von Magento Shops

Der erste Schritt vor der Arbeit an einer bestehenden und mir unbekannten Magento Installation, ist bei mir immer eine Shop Analyse, nicht nur um die Anforderungen und Prozesse des Händlers besser zu verstehen, sondern auch und vor allen Dingen, um die Qualität einzuschätzen und mögliche Probleme frühzeitig zu erkennen. Denn leider sind viele Shops ohne Kenntnis von Konventionen und Best Practices “zusammengebastelt”, was dazu führt, dass:

  1. Die Performance leidet
  2. Sicherheitslücken entstehen
  3. Updates unmöglich werden
  4. Der Code nicht wartbar ist

Punkt 1 und 2 können den Händler ganz direkt schmerzhaft treffen, Punkt 3 und 4 führen mit der Zeit dazu, dass Bugs sich anhäufen, neue Änderungen häufig zu neuen Fehlern an anderer Stelle führen, die immer schwerer zu lösen sind.

Das ist dann häufig der Punkt, an dem eine neue Agentur oder ein neuer Entwickler gesucht wird, also ist es kein Zufall, dass Shops meist in solch degeneriertem Zustand auf meinem Tisch landen. Umso wichtiger ist die Analyse als erster Schritt, noch vor einem Angebot für Weiterentwicklungen, um nicht blind in die selbe Falle zu laufen wie die Vorgänger, und von Vorneherein für Klarheit auf beiden Seiten zu sorgen.

Continue reading “Meine Checkliste bei der Analyse von Magento Shops”