Archives » Allgemein



Weitere PostProcessings im Fatchip Artikel Exporter

Ich gehöre in der Regel zu den OXID-Entwicklern, die eigentlich keine verschlüsselten Module einsetzen. Meine Shops sind meistens so stark angepasst, dass ein blindes Integrieren nicht in Frage kommt. Solange der Modulanbieter keinen Mist baut, interessiert mich nicht, wie der Quellcode qualitativ aussieht oder ob ich das Modul auch selbst hätte machen können. Ich möchte aber im Voraus wissen und/oder selbst kontrollieren können, welche Seiteneffekte es mit einem Modul geben könnte, wie das Modul angepasst werden kann und/oder gemergt werden muss. Und auch wenn ich Bugs vermute, möchte ich diese vorher sauber recherchieren, um Fehler bei mir auszuschließen und dass der Modulanbieter direkt ordentlich mit der Behebung starten kann.
Daher habe ich mich besonders gefreut, dass die Fatchip GmbH alle Module seit kurzem quelloffen vertreibt.

Passend zu dieser Source-Meldung hatte ich nämlich auch eine Nachfrage zu diesem Modul, und zwar wie weiteres Feld-Post Processing hinzugefügt werden kann. Dieses Post Processing sorgt dafür, dass bei einem Artikel-Export Feldwerte nachträglich noch geändert werden können. In der Dokumentation sind dafür leider keine Infos zu finden. Ich nutze aktuell die Version 1.12.7 des Moduls und hier gibt es nur zwei Callbacks zum Post-Processing, nämlich für eine URL-Encodierung und eine nachträgliche Umwandlung in UTF-8, sollte der Feldwert noch nicht so codiert sein.

Ich benötige aber noch einen Callback, um Smarty-Tags z.B. in der Langbeschreibung zu evaluieren, denn ein Marketplace kann mit diesen internen Smarty-Tags eigentlich nichts anfangen. Ich hoffe euch mit diesem Posting Hilfestellung für eigene Post Processings geben zu können.
(mehr …)

WBL Konzept sagt “Danke!” für die #oxcom12

So die OXID Commons 2012 ist am Freitag mit der Unconference zu Ende gegangen und wir möchten Danke für die gute Veranstaltung und die tolle Party danach sagen. Wir haben für euch natürlich ein paar privatere Impressionen auf  Foto gebannt und möchten mit diesem Posting auch ein paar, für uns wichtige Infos der Sessions festhalten.

SysEleven spielte das Lied vom Bottleneck

Marc Korthaus, Geschäftsführer der SysEleven, ging zuerst auf einen vorherigen Beitrag der Continum AG ein, dass Full Page Caching natürlich sinnvoll ist und auf jeden Fall gemacht werden sollte! Trotz Caching wird es aber immer Seitenaufrufe geben, die größere Last verursachen, also z.B. die Checkout-Requests die bei gr0ßem Aufkommen Datenbankserver auslasten können. Man könne dieses Problem aber abschwächen, wenn man dafür sorgt, dass man zusätzlich die Datenbank entsprechend mitskaliert. Datenbankabfragen aber zwischen Servern zu verteilen hilft gemäß Marc Korthaus aber eben primär nicht bei der Perfomance, es ist einfach eine Hilfe um vertikal zu skalieren und somit die mögliche Gesamtlast des Systems  zu steigern. Ich stimme aus eigener Erfahrung auch diesen Punkten zu, der einzelne Shopuser wird in einer normalen Situation nicht viel davon mitbekommen, ob das Script von einem oder mehr Servern zur Verfügung gestellt wird, in Hochlastsituation kann er dann aber hoffentlich, wie gewohnt weiter einkaufen.

Hendrik Bahr  besprach drei Säulen der Performance

Hendrik Bahr, Geschäftsführer der Fatchip GmbH, nannte drei Säulen guter Performance: Das ist zum Ersten natürlich die Hardware und zum Zweiten die Software. Aber selbst wenn man bei diesen zwei Säulen bereits gut aufgestellt sei, gibt es einen Faktor der vieles beeinflusst und mit dem vielleicht relativ kosteneffizient die Performance gesteigert werden kann, die Datenhaltung. In diesem Zusammenhang gibt es eine eigentlich einfache Fragestellung, welche meiner gespeicherten Daten brauche ich wirklich? Was man nicht braucht, sollte nach Möglichkeit aus dem Shop raus. Auch dem kann ich uneingeschränkt zustimmen, braucht man z.B. wirklich abermillionen Gutscheine, auch von abgelaufenen Aktionen?

Performance-Recherche des Senior-Developers Mazvydas Skuodas

Die Performance des Shops hängt primär von den Detailfülle der Aktionen eines Shop-Views ab. Mazvydas Skuodas hat dafür mehrere Benchmarkergebnisse gezeigt und z.B. auch offen gelegt, dass Smarty wie von einigen Entwicklern angeführt, anscheinend keinen nennenswerten Einbruch in der Performance bringt. Aber die klare Ansage war, Performance holt man raus, indem man sich klar macht, welche Features man braucht und sich wirklich auf diese beschränkt und konzentriert.

Erik Kort zur Verbesserung des Cores in 4.6.0

Ein Beispiel wie sich der Core verbessert hat ist die Anzahl der Datenbankabfragen. Seit OXID 4.4.8 bis OXID 4.6.0 hat sich die Anzahl der Abfragen der gezeigten Beispiele um rund ein Drittel reduziert, indem man Abfrageergebnisse vermehrt per Cache-Datei im tmp-Ordner ablegt. Dies sei im Gegensatz zu den Includes-Pfaden von oxAutoload kein Problem, da die Dateien nicht so oft geschrieben werden würden. Die 4.5.8 sei auch schneller geworden, da man aus den 4.6.0 Betas einige Dinge zurück portieren konnte. Während der Session fand ein reger Austausch über diese Zahlen statt, so dass einige Partner wie z.B. SysEleven und Fatchip die Idee hatten, auch einmal die OXID EE 2.7.0.3 und PE 3 mit der 4.6.0 auf der von Erik Kort genutzten Plattform zu vergleichen, es bleibt bei diesen Themen also spannend.

Module seit OXID 4.6.0 und Ausblick

Rimvydas Paskevicius und Alfonsas Cirtautas haben ausgiebig über das neue Modulsystem gesprochen. Abgesehen von den Dingen die hier auch bereits von mir verlinkt wurden, wie z.B. die vendor- und metadata.php hat man besprochen was noch ansteht. Besonderes Highlight sind hier für mich  z.B. die Installation- und Deinstallationsroutinen für Module, um z.B. Datenbankänderungen mit einem Modulsetup vorzunehmen. Erik Kort sprach hier aber leider erst von Version 5.

Worauf man beim Unittesting achten sollte

Rania Tarazi, Project Manager von OXID eSales AG, hat gezeigt, welche Softwaremetriken kontrolliert werden, wenn ein Modul die Zertifierung von OXID erhalten solle. Zusätzlich hat man betont, selbst wenn es imho nicht im OXID-Wiki dokumentiert ist, dass eine Methode im Optimalfall 80 Zeilen nicht überschreiten sollte. Etwas mehr ist auch noch OK, aber an dieser Zahl sollte man sich orientieren.
Worauf man gemäß OXID natürlich auch noch achten sollte, ist die Kompatiblität zwischen Modulen indem man z.B. die oxException verwendet, ein Präfix vor Datenbankfelder stellt und nach Möglichkeit immer den parent-Aufruf ausführt.

Interessant war auch, was man nicht testen würde und zwar ist das die eigentliche Funktion einer Methode, Bugs würden nicht kontrolliert und Frontends würden ignoriert.

Mit OXID 4.6.0 hat OXID meiner Meinung nach ein tolles Produkt erhalten. Man darf dabei bloß nicht vergessen, OXID – aber auch Magento, Typo 3 und andere Systeme – sind Lösungen, die möglichst viele Wünsche befriedigen sollen, und dies auf möglichst bestem Wege. Da man per se nicht jeden möglichen Wunsch  erfüllen kann, gehen Individualwünsche manchmal unter. Aber die Community, die sich auf der OXID Commons 2012 gezeigt hat, komplettiert dieses Produkt mit Ihrer Vielfältigkeit ganz wunderbar.

Bis zum nächsten Jahr.

Danke!

WBL Konzept ist nun OXID Certified Solution Partner

OXID Partner SiegelMal wieder eine erfreuliche Meldung in eigener Sache.

Vielleicht hat es einen von Euch über meine Vorstellung zu meinem XING-Profil geführt und dort ein paar Qualifikationen gesehen, ansonsten ist mein Arbeitgeber die WBL Konzept nun auch OXID Certified Solution Partner.

Wir freuen uns auf eine erfolgreiche Partnerschaft!