Archiv für den Autor: Joscha Krug

Joscha Krug ist Gründer und Geschäftsführer der marmalade GmbH aus Magdeburg. Mit seinem stetig wachsenden Team realisiert er schon seit 2009 E-Commerce Projekte mit OXID eShop und Shopware. Er ist Autor der beiden OXID Bücher, erschienen bei o'Reilly.

share

This week at marmalade – twam #10

Wow, schon die 10. Woche in der wir aus unserem Agenturalltag berichten. Je genauer man hinschaut, desto mehr fällt einem auf, was sich in den 5 Tagen alles bewegt.

Gestartet sind wir mit einer erneuten Veränderung in unserem Puppet-Rezept. Da wir ein neues Projekt beginnen, welches TYPO3 (gleich in Version 7.2, erfordert mindestens PHP 5.5) und eine OXID Enterprise Edition (bisher offiziell supportet bis PHP 5.4) einsetzt, sind wir gezwungen zwei Boxen zu verwenden. Da dies dem späteren Setup nahe kommt, ist dies bereits in der Entwicklung ein realistisches Setup. Allerdings stellte sich heraus, dass es einen Bug des .deb-Paketes für PHP 5.5 gibt. Um unsere Boxen wie geplant weiter einheitlich halten zu können, sind wir komplett auf Ubuntu gewechselt.

OXSEARCH 3.6

Das OXSEARCH-Team hat sich an den letzten Feinschliff gemacht, damit wir morgen, die neue Version 3.6.0 veröffentlichen können. Das Update bringt einige Stabilitätsverbesserungen und vor allem eine Dokumentation. Diese veröffentlichen wir mit GitBook. Die Plattform erlaubt uns ein einfaches Arbeiten und Versionieren in bewährter Weise und ermöglicht viele Ausgabeformate wie HTML, PDF und sofern gewünscht sogar EPUB.

Refactoring TOXID

Wir haben begonnen, TOXID cURL zu überarbeiten und zu ergänzen. Es soll unter anderem das SEO-Snippet entfallen und das Absenden von Formularen über TOXID ermöglicht werden. Nebenbei wurde der Branch mit den vorbereiteten Unit-Tests in den Standard aufgenommen, um neben neuen Features auch weiter an der Qualität der Software zu arbeiten.

Weiterbildung für die Projektmanagerinnen

Gleich ein doppeltes Paket Input gab es für unsere beiden Projektmanagerinnen: Zum einen haben sie in einer Schulung das SEO-Tool von RankingCoach kennegelernt, das wir in der kommenden Zeit testen werden, zum anderen haben wir eine neue Serie gestartet: „Webdevelopment für Projektmanager“. Thema diese Woche: „Domain, IP, DNS und HTML Basics“.

Für mich, Joscha, gab es ebenfalls neues zu entdecken: Im Hackerspace Netz39 bekam ich eine Einführung in den 3D-Druck. Mit dem OpenSource-Tool OpenSCAD habe ich ein erstes Teil konstruiert und gesliced. Die Art des Modellierens kommt mir durch die Programmierweise sehr entgegen und ist schneller verstanden als ich erwartet hätte.

erste OpenSCAD-Schritte

erste OpenSCAD-Schritte

Im Marketing haben wir den Entwurf für das T-Shirt des TYPO3Camps fertig gestellt. Vielleicht findet sich ja ein Entwickler auf der Veranstaltung, der auf der Suche nach einem neuen Team ist. Dediziert ums Recruiting ging es bei der Firmenkontaktmesse in der Hochschule Magdeburg, die Julia sich angeschaut hatte. Vielleicht sind wir im nächsten Jahr dabei.

Was das Netz bewegt

Ein schönes Interview gab es bei t3n: Lars Jankowfsky spricht über Entscheidungen und warum die neuesten Technologien nicht immer die besten sind. Auch wir erleben das immer wieder, dass es abzuwägen gilt, ob man den sicheren Weg geht, oder etwas neues wagt. Manchmal, wie damals, als wir den Shop der Mayerschen und davor „ocelot,“ realisiert haben, blieb uns gar nichts über außer einer mutigen Entscheidung, die von guten Partnern mitgetragen wurde (Mit SysEleven zusammen konnten wir von Elasticsearch 0.20.0 bis heute zur 1.4 migrieren). Ähnliches schreibt auch Tobias Schlitt von Qafoo im Firmenblog: Developers Life is a Trade-Off

Und zu guter Letzt hat Marco Steinhäuser eine ganze Reihe neuer Termine der OXID Usergroups veröffentlicht. Gut verteilt über ganz Deutschland muss kaum jemand weit fahren. Wir werden sicher auf dem Gründungstreffen in Hannover dabei sein.

share

Twitter einfach in TYPO3-Template einbinden.

Vorstatz für’s neue Jahr wie üblich „Weniger aufschieben“. Gesagt getan, auf unserer Website hat sich einiges angesammelt gehabt an Kleinigkeiten, die ich immer schon mal angehen wollte. Eines davon war der defekte Twitter-Feed im Footer unserer Seite. Nachdem das einfache einbinden nicht mehr möglich war, haben wir einige Zeit auf den Inhalt verzichtet. Dafür wieder ein PlugIn / Extension bemühen?

Zugegeben, mein erster Versuch ging wieder in diese Richtung. Nachdem ich zwei Extensions (beide noch alpha laut Entwickler) ausprobiert hatte, dachte ich, das muss doch auch einfacher gehen. Schließlich soll einfach von Twitter ein JSON abgefragt und formatiert wieder ausgegeben werden.

Nach kurzer Suche habe ich in der Doku die ContentObjects „USER“ und „USER_INT“ gefunden. USER_INT ist im Gegensatz zu „USER“ ungecacht und daher das gesuchte, schließlich soll der Inhalt von Twitter jedesmal neu geladen werden. Mit beiden lässt sich der Content aus eigenen PHP-Scripten im TypoScript verwenden.

Auf GitHub habe ich dann eine schöne schlanke Klasse gefunden, mit der sich die Twitter-API ansprechen lässt.

Damit habe ich mit dann ein entsprechendes Scriptchen gebaut und in die Seite eingefügt. Hier die kurze Schritt-für-Schritt-Anleitung

1) Twitter API freischalten

Die Twitter-API-Credentials müssen im eigenen Konto aktiviert werden. Diese benötigen wir gleich für den Zugang. Das ganze findet ihr im App-Bereich. Dort legt ihr eine neue App an und erhaltet die entsprechenden Daten.

2) Script erstellen

Erstellt das PHP-Script, dass ihr in eurem Template aufrufen wollt. Einfach als PHP-Datei auf dem Server ablegen, am besten dort, wo ihr auch euer Template liegen habt.

Der Inhalt besteht zum einen aus zwei Funktionen für den Aufruf aus dem TypoScript und am Ende aus der Klasse von GitHub.


<?php
function getTweets()
{
$settings = array(
'oauth_access_token' => "YOUR_OAUTH_ACCESS_TOKEN",
'oauth_access_token_secret' => "YOUR_OAUTH_ACCESS_TOKEN_SECRET",
'consumer_key' => "YOUR_CONSUMER_KEY",
'consumer_secret' => "YOUR_CONSUMER_SECRET"
);

$url = 'https://api.twitter.com/1.1/statuses/user_timeline.json';
$getfield = '?screen_name=marmalade_web&count=5';
$requestMethod = 'GET';

$twitter = new TwitterAPIExchange($settings);
$response = $twitter->setGetfield($getfield)
->buildOauth($url, $requestMethod)
->performRequest();

return $response;
}

function getTweetsInHtml($content, $conf)
{
$json = getTweets();
$array = json_decode($json);

$html = '<ul>';
foreach($array as $tweet)
{
$html .= '<li>';
$html .= '<p>' . $tweet->text;
$html .= ' <span class="tweetTime"> ' . date('d.m.Y H:i ',strtotime($tweet->created_at)) . '</span>';
$html .= '</p>';
$html .= '</li>';
}
$html .= '</ul>';

return $html;
}
[HIER KOMMT DIE KLASSE VON GITHUB]

 

3) Ausgabe im TypoScript-Template

Nachdem wir die Datei erstellt und auf unserem Server abgelegt haben, könne wir im TypoScript-Template darauf zugreifen.

includeLibs.time = Pfad/zu/eurem/Script.php
lib.twitter = USER_INT
lib.twitter {
userFunc = getTweetsInHtml
}

 

Das wars auch schon. Ziemlich simpel. Oder? Für unsere Zwecke allemal gut genug. Das ergebnis seht ihr am Ende dieser Seite.

share

Spryker – eine erste Einschätzung

Wie auf Twitter zu lesen war, habe ich mich heute auf den Weg nach Berlin gemacht, um mir in den Räumen von Project A den aktuellen Stand von Spryker zeigen zu lassen.

Zum Überblick: Spryker ist der Name einer E-Commerce Software-Lösung, mit der man „Yves&Zed“, das Shopframework von Project A Ventures, kaufen kann. Auf Basis dieses Systems wurden bereits einige Startups des Unternehmens umgesetzt, so zum Beispiel Tirendo.

Zur Technik

Das System ist, wie schon auf dem Blog vorgestellt, in drei Bestandteile aufgesplittet:

Yves, das Frontend

basiert auf dem Microframework Silex aus dem Hause SenioLabs (den Machern von Symfony) und ist ausschließlich für die rasante Auslieferung der Seite zuständig. Als Tempalting kommt hier passenderweise die Twig-Templatingengine zum Einsatz, ebenfalls von SensioLabs. Schnell wird das ganze, weil hier keinerlei Anbindung und Logik implementiert sind. Die Daten kommen ausschließlich aus einem KeyValue-Store (default: Redis) sowie, wenig überschend, Elasticsearch. Zusätzlich werden die Sessions in einem zentralen Speicher vorgehalten, ebenfalls gerne Redis.

Dies unterstützt den Ansatz, das System äußerst skalierbar zu halten. Project A bevorzugt Rackspace als Hoster und hat entspechend auch die Technologien gewählt.

Zed für die Logik

Geht es um Logik, also das Absetzen einer Bestellung, erfolgt dies über die Backend-Komponente Zed. Entgegen der im Blog angelegten Grafik, basiert auch Zed inzwischen auf Silex, beziehungsweise soll dies das ZendFramework ablösen, doch dazu gleich noch mehr.
Zed spricht mit der MySQL-Datenbank und enthält sämtliche Berechnungen der Anwendung. Der Austausch zwischen den beiden Komponenten erfolgt mittels einer einfachen JSON-API. Zudem ist Zed dafür zuständig, die oben erwähnten Datenspeicher (Elasticsearch und Redis) zu füllen und zu aktualisieren.

Die Zahlen der beiden Komponenten sind beeindruckend: 50ms für die Berechnung einer Seite sind der Benchmark für Yves und Zed sollte in 100ms bis maximal 150ms antworten – wohlgemerkt ohne Cache!

DWH

Die dritte Komponente ist das Datewarehouse (ohne spannenden Titel, einfach DWH), was für das ganze Reporting und die Auswertungen zuständig ist.
Es basiert auf einigen OpenSource-Komponenten und ist, obwohl ein für das Skalieren von Geschäftsmodellen sehr spannender Part, leider ein wenig zu kurz gekommen während der Präsentation.

Das Kernsystem ist sehr schlank und lose gekoppelt, so dass sich einzelne Komponenten möglichst einfach austauschen lassen sollen. Die einzelnen „Bundles“ werden per Composer installiert und können damit nach Bedarf integriert werden.

Man sieht, was Fabian Wesner, CTO und Architekt von Spryker sich vorgenommen hat, wird hier konsequent umgesetzt: Best Practices der PHP-Webentwicklung sind an allen Stellen zu finden. Dies soll neben einer möglichst lange hoch bleibenden Entwicklungsgeschwindigkeit auch das OnBoarding neuer Entwickler vereinfachen.

Pricing

Natürlich sind Zahlen diskutiert worden, Aus dem Gefühl heraus würde ich sagen: Man ist noch auf der Suche nach einer tragenden Lösung. Spannend ist, dass man eben nicht wie die etablierten Hersteller die Lizenz an die Skalierung binden möchte. Benötigt man mehr Server oder übersteigt künstlich gezogene Umsatzgrenzen, muss nicht neue lizensiert werden. Damit läuft es auf eine Jahresgebühr hinaus. Diese soll pro Kunde einen Entwickler finanzieren, wie auch hier schon erwähnt. Zugegeben ein ziemlich gut bezahlter Entwickler. Dies ist für große Kunden sicher kein Problem, wenn sich dadurch eben auch einen Entwickler pro Jahr weniger mit dem Basissystem beschäftigen muss.

Zielgruppe

Das bringt uns zur Frage der Zielgruppe, die selbstverständlich auch in Berlin aufkam: „Für wen ist Spryker gedacht und interessant?“ Die Antwort wurde leider zuerst vor allem mit dem Budget gegeben. Schade eigentlich. Ich finde die Zielgruppe ist sehr klar zu definieren:

Unternehmen, die einen wirklich agilen Ansatz haben oder wollen UND mittelfristig in der Lage sind, ein eigenes Team aufzubauen, dass das nötige Know-How aufbringen kann um solche eine Plattform stabil zu halten, zu warten und weiter zu entwickeln.
Denn wie haben die Kollegen von hmmh schön gesagt: „Mit Entwicklern ohne das entsprechende Rüstzeug ist auch dieses System in kürzester Zeit klein zu bekommen.“

Im Gegensatz zu den bisher am Markt verfügbaren Lösung hat Spryker eben keine Konfigurationsoptionen in einem Backend. Wenn ich so auf unsere Projekte schaue, dann begrüße ich den Ansatz sehr. Dies kann der Software nur gut tun – aus Sicht eines Technikers.

Statemachine und Stand der Software

Im zweiten Teil des Nachmittags teilte sich die Gruppe in „Sale“ und „Technik“. Nicht schwer zu erraten, wohin ich gegangen bin.

Fabian Wesner hat uns in kleiner Runde Detailfragen beantwortet und uns den aktuellen Stand in einem Stagesystem erklärt.

Sehr spannend fand ich die Statemachine, mit der sich Bestellstatus sehr transparent darstellen und umsetzen lassen. Dies habe ich noch in keinem System so gut umgesetzt gesehen. Zum einen wirkt es den oft sehr undurchsichtigen Codeteilen mit unmengen von if-Statements entgegen, zum anderen ist auch für den Support äußerst transparent nachvollziehbar, warum eine Bestellung welchen Status hat. Laut eigenen Aussagen lassen sich damit auch shop mit 1.000 Bestellungen / Tag mit einem Team von 2 Personen im Support betreiben.

Was in diesem zweiten Teil aber auch klar wurde: Yves&Zed kam bisher nur bei Project A zum Einsatz. Die Aufgaben und Anforderungen, die an eine Produktlösung gestellt werden (müssen), sind noch nicht richtig erkennbar. Viele der Features müssen nochmal überarbeitet, korrigiert und angefasst werden. So ist zum Beispiel Zed derzeit noch in ZendFramework umgesetzt und soll wie oben erwähnt auf Silex portiert werden.
Der Umbau soll bis Ende Februar abgeschlossen sein. Dann sollen auch erste Agenturen mit der Implementierung beginnen können. Sie werden dabei eng mit Project A zusammenarbeiten (müssen).

Dies ist aus meiner Sicht sinnvoll, da man mit Spryker neben der Software auch viel Know-How was den Ausbau und die Skalierung der eigenen Online-Strategie betrifft mitbekommt und mitbekommen muss. Sonst wird man damit nicht glücklich werden.

Fazit

Mit Spryker kommt eine Lösung auf den Markt, die, einmal einen stable-Status erreicht, sicher etwas für Unternehmne wie uns, die eine agile Entwicklungsweise schätzen und leben und schnell auf Änderungen am Markt reagieren wollen, darstellen kann. Massentauglich wird sie erstmal nicht werden und soll sie ja auch nicht. Es wird daher aber immer die Note „Nischensystem“ bleiben, bei er man sich der Frage stellen muss:
Wie lange trägt das ganze und wie zukunftssicher kann ich damit agieren.

Die Macher haben neben den Technischen Feinheiten vor allem die Aufgabe, Features (Bundles genannt) zu beschreiben, so dass klar ist, auf welche Komponenten zurück gegriffen werden kann. Derzeit gibt es noch keinen Importer für Daten und auch das Thema „PIM“ ist konsequent ausgeklammert.

Was mir persönlich vor allem fehlt ist das wirklich „Neue“. Wer sich moderne Marketingkomponenten auf die Fahnen schreibt, muss sich fragen lassen, ob ein klassischer Kategoriebaum wirklich dem gerecht werden kann, oder ob es mit Elasticsearch an Bord nicht spannendere, flexiblere Ansätze gibt.

Ich hoffe bald wieder von diesem System zu hören und würde mir wünschen das Team im März beim eCommerceCamp in Jena zu sehen.

share

Pull Requests – Fluch und Segen

Die Zusammenarbeit bei OpenSource-Projekten auf GitHub oder GitLab ist großartig. Ich freue mich immer wie ein Schneekönig, wenn jemand eine Erweiterung für eines unserer OpenSource-Projekte macht und über einen Pull Request zum Mergen übergibt.

TOXID ist so über die Jahre gewachsen, dass es inziwschen in großen Enterprise-Projekten zum Einsatz kommt, das cleartmp-Modul aus dem Kochbuch ist erweitert worden und kommt viel zum Einsatz und für viele andere Module bekommen wir Feedback.

Was jedoch –  und damit zum „Aber“ – das mergen, also das Zusammenführend des Codes unglaublich schwer macht, ist das automatische Ändern von Code-Style durch die Entwicklungsumgebungen.

Was passiert, ist, dass große Codeblöcke und teilweise ganze Dateien als geändert markiert werden, weil die IDE Methoden umsortiert, andere Einrückungn hat, etc.

Man sitzt also vor einem riesigen Block Änderungen und muss sehr mühsam suchen, was denn nun wirklich geändert wurde. Das kostet Zeit, Nerven und ist nicht mal so eben nebenher zu machen.

Wie sieht ein guter Pull Request aus?

  1. Es werden neue Funktionen hinzugefügt
  2. Sind Code-Style-Änderungen unbedingt nötig, werden die in einem separaten Commit gemacht, der entsprechend markiert ist.
  3. Umsortieren kompletter Methoden findet nicht statt.
  4. Code-Style-Änderungen gehen immer in Richtung des betroffenen Projekts.

Inzwischen gibt es ja einen de Facto Standard für Codestyle, den alle großen Projekte die wir einsetzen verfolgen: PSR-2

Wir werden daher alle Module auf PSR-2 wechseln. Doch seht es uns nach, wenn das nicht immer klappt, weil wir unseren alten Style noch gewöhnt sind.

Um Energie zu sparen, werden wir bei folgenden Änderungen nur sehr selten mergen:

  • Pull Requests die NUR Codestyle ändern. Das ist kein Update bei allen Usern wert!
  • Pull Requests, die Funktions-Änderung und Code-Style-Änderungen an bestehendem in einem Commit enthalten.

Pull Requests, die Codestyleänderungen an bestehendem Code enthalten die nicht PSR-2 sind.

Ich freue mich, auf die nächsten gemeinsamen Projekte und gerne eine anregende Diskussion!

share

OXID Datenbankdump ohne Views

OXID nutzt für die Mehrsprachigkeit die Views von MySQL. Bei einigen Hostern machen diese jedoch Probleme, wenn man die Datenbank per mysqldump sichern möchte.

Glücklicherweise beginnen die Views alle mit „oxv_“, so dass man diese auschließen kann.

Hier das Entsprechende Script für den Aufruf auf der Commandline:

mysql [dbname] -u [username] -p[password] -e 'show tables where tables_in_[dbname] not like "oxv\_%"' | grep -v Tables_in | xargs mysqldump [dbname] -u [username] -p[password] > [dump_file]

Es werden alle Tabellen ausgelesen, welche nicht mit oxv_ beginnen und ein Dump mit allen anderen erzeugt.

Nachdem man den Dump in die neue Datenbank importiert hat, im Backend unter „Tools“ einfach die Views neu erzeugen.

In manchen Versionen ist jedoch ohne Views gar kein Login ins Backend möglich. Hier hilft das setzen des entprechenden Eintrags in der config.inc.php

$this->blSkipViewUsage = true;


EDIT:

Bei Profihost müssen noch die Pfade für MySQL5 angepasst werden:

/usr/local/mysql5/bin/mysql [dbname] -u [username] -p[password] -e 'show tables where tables_in_[dbname] not like "oxv\_%"' | grep -v Tables_in | xargs /usr/local/mysql5/bin/mysqldump [dbname] -u [username] -p[password] > [dump_file]