Ich suche Dich! WBL Konzept sucht Verstärkung.

Heute mal was rein Dienstliches. Die WBL Konzept hat ein schönes neues Büro im Herzen von Düsseldorf und noch mindestens einen Platz an meiner Seite zu vergeben. Wir suchen jemanden, der mich beim Programmieren unterstützt. Anstellung sofort, “Titel” ist nicht so wichtig, Hauptsache Du bist fit in PHP und hast schon einmal was von PHPUnit gehört. Ein Praktikum (oder bald eine Ausbildung) kannst Du bei uns natürlich auch machen. Praktika – aber klaro! – sind bezahlt. Bitte bewerben oder weitersagen ;)

OXID Update für AJAX-Listen

Wer bei OXID in der Vergangenheit versucht hat, die AJAX-Listen des Backends zu überschreiben, wird leider gemerkt haben, dass es doch mit mehr Arbeit als sonst bei OXID üblich verbunden ist.

Mit dem heute erschienen 4.6.2 Patch soll sich das nun erledigt haben.

Wo bisher mit globalen Variablen und Includes “außerhalb” des OXID-Frameworks gearbeitet wurde:

Wird nun ein imho deutlicherer sauberer Include mit oxNew ausgeführt:

Ich möchte sagen, endlich ;).

Auf der Entwickler-Mailingliste – die ich nur jedem empfehlen kann – hatten wir über einen Bug diskutiert, dass die neue Modullogik kein “Modul-Include” für diese Backendfunktionalität erlauben würde.  Wie man aus meinen Kommentaren zu dem Thread entnehmen kann, habe ich das in meiner Modulentwicklung eigentlich immer für gegeben hingenommen, daher war es für mich kein Bug. Aber die Entwickler von OXID haben das als schlechten Stil erkannt und sofort gefixt. Danke dafür!

Jetzt auf Github, Fortsetzung für den WBL Autoloader

Wer Module nicht wie bei OXID normalerweise üblich pflegen möchte:

Sondern lieber auf solch einen Stil steht:

der ist bei meinem Autoloader genau richtig. Ich persönlich finde, die bisherige Modulpflege verlangt leider einige Redundanzen die auf Grund der API-Sicherheit nun seit Jahren beibehalten werden.
Warum macht man das so? OXID bietet updatesichere dynamische Modulketten – oder besser, einen IoC-Container für Module der Core-Klassen – nämlich bereits seit Jahren an. Manch einer hatte dieses Konzept anfänglich nicht für sinnvoll erachtet doch ich finde es toll. Ich versuche euch mit meinem Autoloader eine Möglichkeit zu bieten, den OXID-Styleguide weiter an andere berühmte Styleguides, wie dem des Zend Frameworks mit Magento, anzugleichen und so eure Projekte intern weiter zu harmonisieren.

Da die Updates für OXID 4.6 abgeschlossen sind, ist der Autoloader nun auch ein OXID Projekt-Fork auf Github. Hier könnt Ihr es downloaden, einsehen oder auch mit mir weiterentwickeln.
(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 auf der OXID Commons 2012

Ich muss mich für meine kurze Abwesenheit entschuldigen. Wer der Facebook-Chronik der WBL Konzept  folgt, hat vielleicht mitbekommen, dass wir ein neues Büro in der Düsseldorfer Carlstadt bezogen haben. Außerdem befinden wir uns grad in den Vorbereitungen auf die OXID Commons 2012, bei der wir an beiden Tagen als Sponsor vertreten sein werden. Also wer uns mal kennen lernen möchte, wir würden uns freuen.

Ich persönliche freue mich bereits auf einige Vorträge, z.B. zu Payment-Systemen, der Modulentwicklung ( besonders ab OXID 4.6.0) und Social Commerce.

Viel Spaß bei der OXID Commons und bis Übermorgen.

Björn

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!

Datenbank-Master/Slave Vorbereitung in OXID 4.6.0

Lastverteilung ist bei großen Internetseiten ein sensitives Thema. Bei gut besuchten Shops natürlich sowieso, denn jeder von uns möchte in Geschäften an der Kasse nicht lange anstehen und sofort bedient werden. Aktuell ist für viele Shops eine Hochlastzeit, denn Muttertag steht vor der Tür und Muttertagsgrüße  möchten verschickt und Geschenke verteilt werden.

Bei typischen Webanwendungen gibt es mehrere Möglichkeiten und Schichten der Lastverteilung. Eine Schicht ist auf der Datenbankseite einer Webanwendung zu finden. Und mit OXID 4.6.0 hat sich hier anscheinend einiges getan.
(mehr …)

WBL Autoloader und OXID 4.6.0

Falsche Modulansicht

Falsche Modulansicht

Vor OXID 4.6.0 musste man sich seine Modulketten im Backend selbst zusammenstellen. Nun hilft einem das Backend dabei. Unser Autoloader durchkreuzte da ein bisschen die Pläne seitens OXID. Er funktionierte weiterhin wunderbar, aber die Aussage im Backend waren für den Benutzer nicht einleuchtend.

  • Module werden unter unserem Kürzel in der Liste gruppiert.
  • Warnmeldung im unteren Frame zur Deaktivierung.

Diese “Probleme” haben wir nun behoben:

  1. Wir haben die metadata.php für den WBL_Modules -Ordner angelegt.
  2. Das Modul WBL_Modules_ModuleList sorgt dafür, dass der Autoloader in der Liste als aktiv angezeigt wird und die “Entfernen”-Warnmeldung im unteren Frame nicht mehr erscheint. (Leider auf den ersten Blick n kleineren OXID-Bug gefunden.)
  3. Und die vendormetadata.php im WBL-Ordner sorgt dafür, dass der WBL-Ordner nicht mehr als direkter Modulordner verstanden wird. OXID schachtelt jetzt noch eine Ebene tiefer und versteht den WBL-Ordner nur noch als Hersteller-Ordner. Dies muss für alle “Hersteller”-Ordner gemacht werden, wobei die  vendormetadata.php dabei noch leer sein darf.
  4. Unittests sind auch aktualisiert worden. Unser Modul für die oxModuleList schließt natürlich auch mit 100% Codeabdeckung ab.
Moduldarstellung

Korrekte Moduldarstellung nach 4.6.0 Update

>> Unseren Autoloader downloaden

Datenbankverbindung beim Unittesting reloaded

Ich musste in meinem Posting Datenbankprobleme beim OXID-Unit-Testing ja bereits von kleinen Komplikationen mit meiner Testumgebung berichten. Bei OXID 4.6.0 ist es nach Tagen ohne Probleme hier plötzlich auch aufgetreten. Irgendwo verschluckt sich meine VMWare.

Mein alter oxDB::getDb() – Fix ist bei OXID 4.6.0 tot und führt zu einer Endlosschleife, daher sieht meine Empfehlung für OXID 4.6.0 diesmal so aus:

Beste Grüße
Björn

Facebook Shop Modul

Ich habe es in der Vorstellung angedroht, ab und zu kommt auch ein bißchen Werbung. Ich habe euch das Autoloader 4.6.0 Posting versprochen. Ja, der Autoloader wird gerade mit “oxModule” verknüpft und zwar im 4.6.0 Update unseres Facebook-Shop-Moduls, daher braucht das Posting noch ein bißchen.

Unser WBL Facebook Shop Modul ermöglicht euch die Implementierung eures Shops im Facebook-Kontext ohne weitere Schnittstelle. Das gleiche Backend, der gleiche Artikelbestand, die gleichen User-Daten und mit OXID 4.6.0 funktioniert hoffentlich der Facebook Connect auch wieder besser.