Da kommt die PHP-UnConf doch genau richtig, oder? Moment. Aber das ist ja nur PHP? Stimmt nicht mehr. Denn die PHP-Unconf findet unter neuer Flagge statt: Web Engineering unconference Europe.

Nachdem in den letzten Jahren die Themen ohnehin sehr Web-Tech-Lastig, und somit häufig PHP unabhängig, waren ist der Schritt alle spannenden Techniken in einer Conference zu vereinen nur naheliegend.

Mit den Erfahrungen aus dem E-Commerce Camp in Jena, welches immerhin schon Shop-System unabhängig ist, viel es uns dann am Ende leicht zu entscheiden: Ja, wir sind dabei und bringen natürlich unser Team mit.

Achso, hatte ich erwähnt dass das Ticket nur 60€ kostet und der ganze Spaß auch noch in der Sonne auf Malle stattfindet?

This year we filled the "Türchen"-list so fast as never before, thank you very much for all your help, great blog posts and sharing your knowledge. that is so awesome!

Short review about all xmas-posts from 2016

• Türchen 01: Profiling is the key
• Türchen 02: Automated Deployment with deployer.org
• Türchen 03: Solving the hardest problems
• Türchen 04: PDF Generierung in Magento 2
• Türchen 05: ImportExport-Schnittstelle unter Magento2
• Türchen 06: A riddle, a self-help group and Klebchen at the MageUnconference 2017...
• Türchen 07: Magento 2 API - where to start and what has changed
• Türchen 08: Simultaneous deployment to multiple nodes with PHP (deployer.php)
• Türchen 09: Building an IT team
• Türchen 10: Frontend-Testing mit Codeception für Magento
• Türchen 11 : Schmalspurentwicklung von Magento 1 Shops (ohne geiles Deployment und so)
• Türchen 12: You Can Sit With Us.
• Türchen 13: How to mess up talking on stage.
• Türchen 14: Understanding the blank theme of Magento 2
• Türchen 15: How to calculate a project
• Türchen 16: What Happens When a Community Works Together
• Türchen 17: Better organize your dependencies and even your source code with composer
• Türchen 18: Magento 2 for Magento 1 Developers
• Türchen 19: Worst Magento Practice
• Türchen 20 : How to create a custom Lizards & Pumpkins REST API endpoint
• Türchen 21: Die Transformation vom Entwickler zum Unternehmer
• Türchen 22: Blackhat.Design: Weapons of Social Seduction
• Türchen 23: Easytemplate - eine kurze Vorstellung
• Türchen 24: Frohe Weihnachten & Merry Christmas

Viele Themes bringen teilweise echt gut gestaltete Seiten mit, die aus einzelnen Komponenten zusammengesetzt sind und im Idealfall auch einfach adaptiert und wieder verwendet werden können. Schaut man sich in einem solchem Theme die betreffende Seite im Editor und die teilweise endlosen Zeilen HTML-Codes an, bedarf es einer gehörigen Portion Wissen um die HTML-Syntax und des Baukastensystems des Themes um die Seite zu verändern und/oder neue Seiten anzulegen.

Dies zu vereinfachen und so uns und den Kunden in der Lage zu versetzen, schnell Seiten zu erstellen und Inhalte zu pflegen war der Ansporn für Easytemplate.

Easy template im Überblick

Easy template ist ein Baukastensystem aus unterschiedlichen, endlos erweiterbaren Bausteinen aus dem der Shopbetreiber wählen kann, um Inhalte zu pflegen.

Klickt man auf den neuen Reiter 'Easy template' gelangt man zum neuen Inhaltsbereich.

Hier kann man gut erkennen, dass die Inhalte modul gepflegt werden, gekapselt und übersichtlich vorliegen.

Ein neuer Baustein kann über 'Neue Vorlage' eingefügt werden.Aus einer kategorisierbaren Liste kann der entsprechende Baustein ausgewählt werden, welcher dann am Anfang der Seite eingefügt wird.

Die Bausteine können einfach per Drag'n Drop verschoben werden, des weiteren können einzelne Bausteine deaktiviert oder auch nur für einen Zeitraum aktiviert werden. So lassen sich z.b. Inhalte im Voraus planen und nicht immer manuell eingeriffen werden.

Diese Maske wird durch eine XML-Datei erzeugt, in der alle Bausteine definiert sind.

...
                <productlisting_as_multiple_carousel template="easytemplate/home/product_list.phtml" type="easytemplate/template_product_skulist" translate="label,comment">
                    <enabled>1</enabled>
                    <label>Produktliste als Karussell</label>
                    <sort_order>40</sort_order>
                    <fields>
                        <global_headline translate="label,comment">
                            <label>Überschrift</label>
                            <input_renderer>easytemplate/input_renderer_text</input_renderer>
                            <sort_order>10</sort_order>
                            <required>0</required>
                        </global_headline>

                        <global_headline_type translate="label,comment">
                            <label>Titel-Typ</label>
                            <comment />
                            <input_renderer>easytemplate/input_renderer_select</input_renderer>
                            <input_renderer_source>easytemplate/input_renderer_source_values</input_renderer_source>
                            <values>
                                <h1>H1</h1>
                                <h2>H2</h2>
                                <h3>H3</h3>
                                <h4>H4</h4>
                                <h5>H5</h5>
                            </values>
                            <sort_order>15</sort_order>
                            <default_value>h2</default_value>
                            <required>0</required>
                        </global_headline_type>
                        <skus translate="label,comment">
                            <label>Artikelnummern</label>
                            <input_renderer>easytemplate/input_renderer_text</input_renderer>
                            <sort_order>20</sort_order>
                            <comment>Kommagetrennte Angabe mehrerer Artikelnummern</comment>
                            <required>0</required>
                        </skus>
                        <background-color translate="label,comment">
                            <label>Hintergrundfarbe</label>
                            <input_renderer>easytemplate/input_renderer_text</input_renderer>
                            <sort_order>30</sort_order>
                            <required>0</required>
                        </background-color>
                    </fields>
                </productlisting_as_multiple_carousel>
...

An diesem Beispiel kann man erkennen, dass es unterschiedliche Renderer gibt, die die Anzeige in Magento steuern und nahezu alle erdenktlichen Fälle abbilden können.

In der ersten Zeile wird dem Baustein das entsprechende Template zugewiesen.

Das Template des Baustein ist wie folgt aufgebaut:

<?php /** @var $this Webguys_Easytemplate_Block_Template_Product_Skulist */ ?>

<?php $uniqid = uniqid(); ?>

<div class="easy-module product_list" style="background-color: <?php echo $this->getData('background-color');?>">

    <div class="main-container">
        <div class="row">
            <div class="col-xs-12-12">

                    <?php if ($this->getData('global_headline')) : ?>
                        <<?php echo $this->getData('global_headline_type');?> class="h2">
                            <?php echo $this->getData('global_headline'); ?>
                        </<?php echo $this->getData('global_headline_type');?>>
                    <?php endif; ?>

                <?php if ($skus = $this->getData('skus')): ?>

                    <div class="easytemplate_product_carousel_container">
                        <?php echo $this->getProductListBlock($skus)->setTemplate('easytemplate/products/list.phtml')->toHtml(); ?>
                    </div>

                <?php endif; ?>
            </div>
        </div>

    </div>
</div>

Die atomaren Eingaben in der Pflegemaske werden einfach über den im XML eingegeben Bezeichner angesprochen und die Werte können ausgegeben und/oder weiter verarbeitet werden.

$this->getData('global_headline');

Das ist schon mal ein toller Anfang, aber es wird noch besser. Die Felder der Maske werden über die XMl-Datei festgelegt. Spätestens wenn man jedoch einen Slider für einen Kunden baut und diese auf z.B. drei Bilder begrenzt, wird sich der Kunde vertrauensvoll an euch wenden, weil er gerne min. vier Bilder präsentieren möchte.

Hier können wir sehen, dass der Baustein 'Headvisual' keine Eingabefelder für die Slides bietet, sondern die Möglichkeit eröffnet, Sub-Bausteine hinzuzufügen. Somit lässt sich die Übersichtlichkeit signifikant erhöhen, ebenso wird der Shopbetreiber nicht von unzähligen Eingabefeldern erschlagen.

Easy template im Laufenden Betrieb

Während der Arbeit erleichert die Anlage einer Arbeitskopie die Arbeit ungemein. Möchte man eine Seite verändern, so wissen wir aus der täglichen Arbeit mit Magento, dass die Änderungen nach Klick auf 'Speichern' sofort online sind. Das macht die Arbeit nicht unbedingt besser. Den Workaround, eine Test-Seite anzulegen und dort die Änderungen vorzunehmen, ist auch nur bedingt komfortabel. Aus diesem Grund gibt es die Funktion 'Arbeitskopie anlegen' - diese legt eine temporäre Kopie der Seite an.

Man hat jetzt genügend Zeit Änderungen vorzunehmen bis man zufrieden ist.

Ist der Status der Glückseligkeit erreicht, reicht ein Klick auf 'Arbeitskopie veröffentlichen', um die Änderungen zu übernehmen. Dies geschieht ohne, das der Besucher im Shop etwas von den Arbeiten sieht.

Easy template im Deployment

Nicht selten kommt es vor, dass ein Update, welches auf einem System vorbereitet wird, über optische Änderungen verfügt, welche neben dem anderen Änderungen übertragen werden müssen. Bei technischen Änderungen ist dies kein Problem, über Versionierung und entsprechende Setup-Skripte lässt sich das meiste schnell in den Griff bekommen.

Anders sind hier jedoch Inhalte, die in Seiten oder Blöcken benötigt werden, hier kann man schneller mal den Überblick verlieren. Aus diesem Grund bietet Easy template die Möglichkeit die kompletten Bausteine einer Seite oder eines Blockes als Zip herunter zu laden und im Live-System wieder einzufügen - mit allen Inhalten selbstverständlich.

Open-Source auf Github

Natürlich gibt es EasyTemplate frei auf Github unter https://github.com/webguys-de/EasyTemplate - die Portierung zu Magento 2 hatten wir schon einmal angefangen - ist dann aber ins Stocken geraten. Aktuell haben wir uns noch keinen genauen Zeitplan gesetzt. Aber vlt. hat der eine oder andere Lust und Zeit sich an einer Portierung zu beteiligen.

A “Blackhat.Design” is a UI intentionally designed to ‘trick’ people into making choices that benefit the company, but are (usually) bad for the customer.

In my work as a psychologist and conversion optimization specialist I help webshops implement these persuasion tactics in online marketing campaigns. But there is also an ethical responsibility to give the audiences of these organisations the tools to guard themselves against these techniques for when they are misused.

If you want a more elaborate introduction: Read this on Blackhat.Design first.

In this post, I’m going to give you 3 examples of common tactics to help you recognize them and make better choices. In other words: to give you some Counter Persuasion Tactics (CPT).

Easy too get in, hard to get out

One trick called ‘Roach Motel’ is to make it really easy to sign up for a commitment, but REALLY HARD to get out. Some examples from nature:

Take Texture, selling digital magazine subscriptions. This is all you need to sign up:

So far so good. Now let’s see what it takes to unsubscribe:

Really? I wonder why they didn’t go with the morsecode option…

There is no technological reason to not make unsubscribing just as easy as signing up. This is pure evil to keep people subscribed.

Limited rooms available (Scarcity)

When there is not much left of something, we want it even more.
Originally Dutch booking site Booking.com got called back by a judge for mis/overusing this tactic.

Sentences like “Only 2 rooms left” make you think that there are only 2 rooms left in the whole hotel, while it just meant that there were only 2 rooms left on booking.com (that day…). If you’d call the hotel, you might find out that a lot more rooms were actually available.

Hiding important information

At Euroflorist some of our usability research showed that users could hardly find the delivery fee and when they did said it came across untrustworthy as it looked like we were hiding it:

Original on the left, improved version on the right.

(Technically not a Blackhat.Design because it wasn’t intentional in our case, but a lot of companies try to hide information in the fine print that they think might not be beneficial for the purchase.)

Not coming across as trustworthy is not a good long-term strategy. In this case, it’s even a very bad short-term strategy: the version on the right (where the delivery fee was placed directly below the product price) had a conversion rate increase of over 12%.

Want more Counter Persuasion Tactics?

Subscribe to blackhat.design, I’ll be posting more next year, including an overall defence plan you can use for you next big purchase! (:

Definition der Formen einer Selbstständigkeit

Für mich gibt es in unserer Branche 2 relevante Formen der Selbstständigkeit, die der selbstständigen Fachkraft und die des Unternehmers. Doch wie unterscheiden sich die beiden?

Die selbständige Fachkraft (Freelancer)

Ein Freelancer muss sich um alle Bereiche im Unternehmen kümmern (auch wenn dieses nur aus ihr selbst besteht) und muss sich so ein breites Wissen über das eigentliche Fachwissen hinaus aneignen. Zumeist handelt es sich um eine Person, die das Arbeiten in ihrem Fachbereich liebt und niemals aufgeben möchte.

Der Unternehmer

Der Unternehmer arbeitet nicht als Fachkraft im Unternehmen, sondern am Unternehmen selbst. Er beschäftigt sich mit der langfristigen Planung und strategischen Ausrichtung des Unternehmens und trägt i.d.R. das Gesamtrisiko. Der Unternehmer wird in den unterschiedlichen Bereichen seines Unternehmens von seinen Mitarbeitern unterstützt.

Wie alles begann

So begann auch ich gemeinsam mit meinem Bruder Jonas 2012 mit der Gründung unserer Internet Agentur die Reise. Du diesem Zeitpunkt waren wir 2 junge Magento Entwickler, die sich in Form einer Agentur zusammengeschlossen hatten und klassische selbstständige Fachkräfte waren. Für uns war jedoch von Anfang an klar, dass wir uns zu Unternehmern weiterentwickeln möchten und eine erfolgreiche Agentur aufbauen möchten.

Tipps

• Bevor Du Dich selbstständig machst solltest Du Deine Ziele definieren (Das muss kein kompletter Businessplan sein)
• Wenn möglich: Suche Dir einen Partner, dessen Interessen sich mit Deinen ergänzen
• Probiere es einfach aus, meist hast du nichts zu verlieren

In dieser ersten Phase entstehen meist noch keine Probleme. Man hat ein paar Kunden, kann seiner Leidenschaft nachgehen und erhält dafür eine gute Entlohnung.

Das Wachstum

Auf diese erste Phase folgen die ersten Rückschläge und Zweifel. Diese können vielfältig sein, der große Kunde ist weggefallen, neue Projekte sind gerade nicht in Aussicht, die ersten schlechten Erfahrungen mit Mitarbeitern entstehen ... - was mache ich nun?
Zunächst einmal: Ruhe bewahren und reflektieren was schiefgelaufen ist? Fehler erkennen, korrigieren und nach vorne schauen.

Mit diesem ersten Wachstum kommt meiner Meinung nach auch die erste große Entscheidung. Möchte ich Unternehmer werden oder Fachkraft bleiben?

Tipps

• Gehe in Dich und frage Dich selbst: Was sind meine Stärken, Schwächen und Ziele?
• Möchtest Du selbst das Fachwissen deiner Tätigkeit haben (Fachkraft)?
• Möchtest du Dein Fachwissen Deiner Tätigkeit an Mitarbeiter weitergeben/abtreten und Dich aus den Fachaufgaben zurückziehen (Unternehmer)?
• Sprich mit Leuten, die diesen Weg bereits gegangen sind

In dieser Phase kommen neben/nach den oben beschriebenen Problemen meist mehr Aufträge auf einen zu, sodass man diese nicht mehr selbstständig bewältigen kann. Somit beginnt man das Unternehmen auszubauen, Mitarbeiter einzustellen oder mit Freelancern zusammenzuarbeiten.

Und plötzlich machst du etwas ganz Anderes

Bis zu einer gewissen Größe kann man dieses Wachstum auch als Fachkraft durchziehen, doch plötzlich spürt man eine gewisse Unzufriedenheit, die man gar nicht so genau definieren kann. Die Mitarbeiter sind fleißig, die Projekte erfolgreich und es kommen genug neue Anfragen.

Zu diesem Zeitpunkt steht man vor der ersten Transformation. Die eigentliche Fachtätigkeit rückt immer stärker in den Hintergrund und man ist hauptsächlich damit beschäftigt, seine Mitarbeiter und die Projekte zu koordinieren.
Dies ist der Zeitpunkt, um wieder eine Entscheidung zu treffen, denn trifft man diese nicht, arbeitet man gegen sich selbst, da man als Fachkraft und Manager verschiede Ansichten und Ziele vertritt. Wenn Du mehr zu diesem Thema erfahren möchtest, empfehle ich das Buch "Der Weg zum erfolgreichen Unternehmer" von Stefan Merath.

Genau diese Phasen (sie kommen nicht von heute auf morgen) zeichnen den Punkt, an dem einige scheitern oder sich bewusst dazu entscheiden, sich wieder auf ihren ursprünglichen Fachbereich zu konzentrieren. Denn, wenn man immer in einem Zwiespalt zwischen Fachkraft, Manager und Unternehmer steckt, wird man auf Dauer nicht glücklich und fragt sich oft: was mache ich hier eigentlich?

Tipp

• Versuche frühzeitig einzulenken, wenn Du merkst, dass Dein Weg Dich nicht erfüllt
• Entscheide, ob Du Dein Unternehmen anpasst oder suche Dir Mitarbeiter, die Dich unterstützen
• Triff eine Entscheidung, sonst treffen sie andere für Dich

Es gibt viele Möglichkeiten diesen Weg weiter zu gehen, ich habe Menschen kennengelernt, die wieder zurück in ihren Fachbereich gegangen sind und die Führung ihren Partnern überlassen haben, denen das Unternehmer-Dasein mehr zusagte. Andere haben sich entschlossen ihre Agenturen zu verkaufen oder auf eine Größe zu reduzieren, in der sie als Fachkraft mitarbeiten können.

Einen falschen Weg gibt es letztendlich nicht, die Entscheidung, welcher der Richtige ist, kannst Du nur alleine treffen.

Mein Weg

Ich persönlich habe mich dazu entschieden, Unternehmer zu werden. Ich sehe es als neue Herausforderung in meinem Leben und eine Chance neue, spannende Dinge kennenzulernen. Noch stecke ich mitten in der Wachstumsphase und bin Fachkraft, Projektmanager und Unternehemer.
Durch diese doch sehr unterschiedlichen Aufgaben, kenne ich das Gefühl "Was habe ich jetzt eigentlich genau heute gearbeitet?" sehr gut. Hier ist mein Tipp, ein klares Ziel vor Augen zu haben und auf dieses hinzuarbeiten.

Ein hilfreiches Werkzeug, das während des ersten Wachstums gerne vergessen wird ist der Aufbau von Prozessen und Standards. Langfristig sind diese jedoch die einzige Möglichkeit eine Agentur, die wächst erfolgreich zu führen und eine gleichbleibende Qualität zu gewährleisten.
Wer nur wächst und abarbeitet wird irgendwann an einen Punkt kommen, an dem im besten Fall das Wachstum nur stagniert, im schlimmsten Fall aber das gesamte Unternehmen zusammenbricht.

Wir selbst haben dieses Jahr unsere Prozesse stark optimiert und unserem Wachstum angepasst, diese sind an der ein oder anderen Stelle aktuell noch etwas "zu groß", noch ist eine Prozesseinführung leicht durchzuführen und wirkt sich positiv auf ein kontinuierliches und gesundes Wachstum aus.

Wenn Du Dich entschieden hast, Unternehmer zu werden, habe ich noch ein paar Tipps wie Dir Dir das Leben leichter machen kannst.

Tipps

• Setze Dir klar definierte Ziele
• Priorisiere Deine Aufgaben
• Lerne Aufgaben abzugeben und diese nicht irgendwann selbst zu übernehmen (egal wie oft Du sie zurückgeben musst)
• Suche Dir gleichgesinnte und lerne von Menschen mit Erfahrung (Aufbau eines Netzwerks)
• Probiere Dinge aus, mache Fehler und lerne daraus

Ich hoffe, ich konnte Dir einen Einblick in die Transformation geben und bei einer vielleicht anstehenden Entscheidung helfen. Solltest Du Fragen haben oder noch mehr wissen wollen, kannst Du mich gerne anschreiben.

Native REST API of Lizards & Pumpkins already provides a rich set of endpoints. However for some very implementation specific functionality you may want to create a custom endpoint. Bestsellers or some custom cross-sells are first that comes to mind. Luckily implementing custom REST API endpoint is extremely easy in Lizards.

Service

The first thing to do is to create a service which will return a requested data. Let’s call it BestsellersService. It will have just one public method getBestsellers which will return an array of bestselling product data.

So let’s start with most degenerative test:

final protected function setUp()
{
   $this->mockDataPoolReader = $this->createMock(DataPoolReader::class);
   $this->stubProductJsonService = $this->createMock(ProductJsonService::class);

   $this->bestsellerService = new BestsellerService($this->mockDataPoolReader, $this->stubProductJsonService);

   $this->stubContext = $this->createMock(Context::class);
}

public function testReturnsAnEmptyArrayIfNoProductsMatchBestsellingCriteria()
{
   $this->mockDataPoolReader->method('getProductIdsMatchingCriteria')->willReturn([]);
   $this->assertSame([], $this->bestsellerService->getBestsellers($this->stubContext));
}

For the sake of readability the property declarations are omitted.

As you can see our service will take a DataPoolReader and ProductJsonService as constructor arguments. The later will create a JSON representation of product IDs returned by the former.

The Context stub will be used in every test so let’s also put into a class property. The Context is a nifty bastard that holds information about the current store, language, currency, customer group or whatever else can be request specific.

Now to the test. It is simple as The Beatles. If the DataPoolReader returns an empty set of product IDs matching our bestselling criteria the service should also return an empty array.

Now let’s make this test pass.

public function __construct(DataPoolReader $dataPoolReader, ProductJsonService $productJsonService,)
{
    $this->dataPoolReader = $dataPoolReader;
    $this->productJsonService = $productJsonService;
}

public function getBestsellers(Context $context) : array
{
    return [];
}

Property declarations are again omitted. Constructor is not doing anything as every good constructor shouldn’t. And the getBestsellers method is returning an empty array so the only test passes.

The next test will not be much more complicated. Simplicity is the key, you know.

public function testReturnsArrayOfBestSellingProductData()
{
   $stubProductIds = [$this->createMock(ProductId::class), $this->createMock(ProductId::class)];
   $expectedProductData = [['Dummy product A data'], ['Dummy product B data']];

   $this->mockDataPoolReader->method('getProductIdsMatchingCriteria')->willReturn($stubProductIds);
   $this->stubProductJsonService->method('get')->with(stubProductIds)->willReturn($expectedProductData);

   $this->assertSame($expectedProductData, $this->bestsellerService->getBestsellers($this->stubContext));
}

So if DataPoolReader returns us a set of product IDs and then those are passed to ProductJsonService it will then return some fake JSON representation for each of them.

This will fail of course as getBestsellers so far always return an empty array so let’s make it pass.

public function getBestsellers(Context $context) : array
{
   $productIds = $this->getBestsellingProductIds($context);

   if ([] === $productIds) {
       return [];
   }

   return $this->productJsonService->get($context, ...$productIds);
}

private function getBestsellingProductIds(Context $context) : array
{
   $searchCriteria = SearchCriterionGreaterThan::create('bestselling_score', '10');
   $sortBy = new SortBy(
       AttributeCode::fromString('bestselling_score'),
       SortDirection::create(SortDirection::DESC)
   );
   $rowsPerPage = 12;
   $pageNumber = 0;

   return $this->dataPoolReader->getProductIdsMatchingCriteria(
       $searchCriteria,
       $context,
       $sortBy,
       $rowsPerPage,
       $pageNumber
   );
}

No magic here too. First get bestselling product IDs, if there’s none return an empty array in order to satisfy the first test, otherwise pass them to ProductJsonService and return obtained product data to caller.

Actual business logic resides in getBestsellingProductIds utility method.

An important concept here is the search criteria. As the name suggests it is a rule or set of rules for querying products out of the data pool. In our example we use SearchCriterionGreaterThan rule. For the whole set check SearchCriteria interface implementations. One of them deserves a special note. CompositeSearchCriterion allows combining two or more criteria with AND or OR condition. One of those criteria could be CompositeSearchCriterion itself which allows building criteria with unlimited levels of sub-criteria. This however deserves a separate article. To keep our example as simple as possible let’s assume our products have an attribute bestselling_score and we want to pull top 12 with score higher than 10.

The search criteria is then passed to DataPoolReader along with desired sort order, number of results and offset and an array of marching product IDs is returned.

Request Handler

This is it about the service class. The next thing that must be implemented is the REST API request handler. When Lizards & Pumpkins gets a REST API request it loops through all registered REST API request handlers trying to find a matching one.

All REST API request handlers must extend the abstract ApiRequestHandler class. Let our first test assure this.

final protected function setUp()
{
   $this->mockBestsellerService = $this->createMock(BestsellerService::class);
   $this->stubContextBuilder = $this->createMock(ContextBuilder::class);

   $this->requestHandler = new BestsellerApiV1GetRequestHandler(
       $this->mockBestsellerService,
       $this->stubContextBuilder
   );

   $this->stubRequest = $this->createMock(HttpRequest::class);
}

public function testIsApiRequestHandler()
{
   $this->assertInstanceOf(ApiRequestHandler::class, $this->requestHandler);
}

The class will need the service we have just implemented and a ContextBuilder. ContextBuilder is just a simple builder class which in our case will create an instance of a Context from given HTTP request. Once again, the Context is an object that encapsulates information of current store, currency or whatever else can be different from one HTTP request to another.

I also created a stub request here as it will be used by every upcoming test.

Now let’s make it pass.

class BestsellerApiV1GetRequestHandler extends ApiRequestHandler
{
   /**
    * @var BestsellerService
    */
   private $bestsellerService;

   /**
    * @var ContextBuilder
    */
   private $contextBuilder;

   public function __construct(BestsellerService $bestsellerService, ContextBuilder $contextBuilder)
   {
       $this->bestsellerService = $bestselerService;
       $this->contextBuilder = $contextBuilder;
   }
}

This will force us to implement the canProcess(HttpRequest $request) : bool method of the HttpRequestHandler interface and the abstract getResponse(HttpRequest $request) : HttpResponse template method of the ApiRequestHandler class. The first one must evaluate request and decide if our endpoint is responsible for handling it. The second will return the actual response for the request. But for now we will just place dummies in order to satisfy PHP interpreter.

public function canProcess(HttpRequest $request) : bool
{
   return true;
}

final protected function getResponse(HttpRequest $request) : HttpResponse
{
   $body = '';
   $headers = [];

   return GenericHttpResponse::create($body, $headers, HttpResponse::STATUS_OK);
}

The next test must be a most degenerative one. How about we test that the request handler will not be able to process other request types but GET?

/**
* @dataProvider nonGetRequestMethodProvider
*/
public function testCanNotProcessNonHttpGetRequestTypes(string $nonGetRequestMethod)
{
   $this->stubRequest->method('getMethod')->willReturn($nonGetRequestMethod);
   $message = sprintf('%s request should NOT be able to be processed', $nonGetRequestMethod);
   $this->assertFalse($this->requestHandler->canProcess($this->stubRequest), $message);
}

/**
* @return array[]
*/
public function nonGetRequestMethodProvider() : array
{
   return [
       [HttpRequest::METHOD_POST],
       [HttpRequest::METHOD_PUT],
       [HttpRequest::METHOD_DELETE],
       [HttpRequest::METHOD_HEAD],
   ];
}

To make it pass all we have to do is to switch the returned value of our canProcess() dummy from true to false.

public function canProcess(HttpRequest $request) : bool
{
   return false;
}

That’s it. Yeah, dumb. But we are only allowed to write a productive code which will make test pass. And this change proves our test to work correctly, so it isn't actually all that dumb. We now need a test which will force us to write the real logic.

public function testCanProcessHttpGetRequest()
{
   $this->stubRequest->method('getMethod')->willReturn(HttpRequest::METHOD_GET);
   $message = 'GET request should be able to be processed';
   $this->assertTrue($this->requestHandler->canProcess($this->stubRequest), $message);
}

To make it pass we just need to check a request type.

public function canProcess(HttpRequest $request) : bool
{
   return $request->getMethod() === HttpRequest::METHOD_GET;
}

Our request handler should only be able to process requests to the given endpoint (let’s name it “bestseller”). Let’s test it also.

/**
* @dataProvider nonMatchingRequestPathProvider
*/
public function testCanNotProcessNonMatchingGetRequests(string $nonMatchingRequestPath)
{
   $this->stubRequest->method('getMethod')->willReturn(HttpRequest::METHOD_GET);
   $this->stubRequest->method('getPathWithoutWebsitePrefix')->willReturn($nonMatchingRequestPath);
   $message = sprintf('GET request to "%s" should NOT be able to be processed', $nonMatchingRequestPath);
   $this->assertFalse($this->requestHandler->canProcess($this->stubRequest), $message);
}

public function nonMatchingRequestPathProvider() : array
{
   return [
       ['/api/'],
       ['/api/foo/'],
       ['/api/bestseller/foo/'],
   ];
}

Quite straightforward. The request path must be /api/bestseller and the rest must be rejected. There is no need to evaluate /api part of request path as this is already done in the ApiRouter. So let’s make this test pass.

public function canProcess(HttpRequest $request) : bool
{
   if ($request->getMethod() !== HttpRequest::METHOD_GET) {
       return false;
   }

   $parts = $this->getRequestPathParts($request);

   if (count($parts) !== 2 || self::ENDPOINT_NAME !== $parts[1]) {
       return false;
   }

   return true;
}

/**
* @param HttpRequest $request
* @return string[]
*/
private function getRequestPathParts(HttpRequest $request) : array
{
   return explode('/', trim($request->getPathWithoutWebsitePrefix(), '/'));
}

Now PHPUnit doesn’t like my testCanProcessHttpGetRequest anymore. I’d like to change it into something like this:

public function testCanProcessMatchingRequest()
{
   $this->stubRequest->method('getMethod')->willReturn(HttpRequest::METHOD_GET);
   $this->stubRequest->method('getPathWithoutWebsitePrefix')->willReturn('/api/bestseller');

   $this->assertTrue($this->requestHandler->canProcess($this->stubRequest));
}

All we have to do is to check that after the change all is green again. And it is!

I guess this is it for canProcess() method. Now to getResponse(). Let’s first test that if someone will pass a non matching request it will throw an exception.

public function testThrowsAnExceptionDuringAttemptToProcessInvalidRequest()
{
   $this->expectException(UnableToProcessBestsellerRequestException::class);

   $this->stubRequest->method('getMethod')->willReturn(HttpRequest::METHOD_POST);
   $this->stubRequest->method('getPathWithoutWebsitePrefix')->willReturn('/api/bestseller');

   $this->requestHandler->process($this->stubRequest);
}

Important thing to note here is the method that we are calling on the SUT. process() is a method of the ApiRequestHandler class we extend and it will call getResponse() in its turn. The creation of the exception class is omitted to keep this post focused on the relevant steps.

In order to make this test pass all we have to do is to call the canProcess() method we just created and throw the exception if it returns false.

final protected function getResponse(HttpRequest $request) : HttpResponse
{
   if (! $this->canProcess($request)) {
       throw new UnableToProcessBestsellerRequestException();
   }

   $body = '';
   $headers = [];

   return GenericHttpResponse::create($body, $headers, HttpResponse::STATUS_OK);
}

There’s one last test we are missing. The response body must contain the actual data. The data comes from the service class we have already created so all we have to test is a delegation:

public function testDelegatesFetchingProductsToBestsellerService()
{
   $testProductData = ['total' => 1, 'data' => ['Dummy data']];

   $this->stubRequest->method('getMethod')->willReturn(HttpRequest::METHOD_GET);
   $this->stubRequest->method('getPathWithoutWebsitePrefix')->willReturn('/api/bestseller');

   $this->mockBestsellerService->expects($this->once())->method('query')->willReturn($testProductData);

   $stubContext = $this->createMock(Context::class);
   $this->stubContextBuilder->method('createFromRequest')->with($this->stubRequest)->willReturn($stubContext);

   $response = $this->requestHandler->process($this->stubRequest);

   $this->assertSame(json_encode($testProductData), $response->getBody());
   $this->assertSame(HttpResponse::STATUS_OK, $response->getStatusCode());
}

And here is the final version of our getResponse() method:

final protected function getResponse(HttpRequest $request) : HttpResponse
{
   if (! $this->canProcess($request)) {
       throw new UnableToProcessBestsellerRequestException();
   }

   $context = $this->contextBuilder->createFromRequest($request);
   $data = $this->bestsellerService->getBestsellers($context);

   $body = json_encode($data);
   $headers = [];

   return GenericHttpResponse::create($body, $headers, HttpResponse::STATUS_OK);
}

Factory

The last class to implement is the BestsellerFactory. It will contain two methods instantiating each of the classes created above plus the REST API endpoint registration. As this is quite a trivial thing and I’m sure you are already bored reading, so I will just print out the BestsellerFactoryTest class entirely:

class BestsellerFactoryTest extends \PHPUnit\Framework\TestCase
{
   /**
    * @var BestsellerFactory
    */
   private $factory;

   final protected function setUp()
   {
       $masterFactory = new SampleMasterFactory();
       $masterFactory->register(new CommonFactory());
       $masterFactory->register(new RestApiFactory());
       $masterFactory->register(new UnitTestFactory($this));

       $this->factory = new BestsellerFactory();

       $masterFactory->register($this->factory);
   }

   public function testFactoryInterfaceIsImplemented()
   {
       $this->assertInstanceOf(Factory::class, $this->factory);
   }

   public function testFactoryWithCallbackInterfaceIsImplemented()
   {
       $this->assertInstanceOf(FactoryWithCallback::class, $this->factory);
   }

   public function testBestsellerApiEndpointIsRegistered()
   {
       $endpointKey = 'get_bestseller';
       $apiVersion = 1;

       $mockApiRequestHandlerLocator = $this->createMock(ApiRequestHandlerLocator::class);
       $mockApiRequestHandlerLocator->expects($this->once())->method('register')
           ->with($endpointKey, $apiVersion, $this->isInstanceOf(BestsellerApiV1GetRequestHandler::class));

       $stubMasterFactory = $this->getMockBuilder(MasterFactory::class)->setMethods(
           ['register', 'getApiRequestHandlerLocator']
       )->getMock();
       $stubMasterFactory->method('getApiRequestHandlerLocator')->willReturn($mockApiRequestHandlerLocator);

       $this->factory->factoryRegistrationCallback($stubMasterFactory);
   }
}

The first test ensures the Factory interface is implemented. Each factory must implement it.

The second test checks that our factory also implements the FactoryWithCallback interface. It will force our factory to have a factoryRegistrationCallback method which is an entry point into a factory.

Last test checks that once this entry point is called and our REST API endpoint is registered.

Here is the productive code:

class BestsellerFactory implements Factory, FactoryWithCallback
{
   use FactoryTrait;

   public function factoryRegistrationCallback(MasterFactory $masterFactory)
   {
       $apiVersion = 1;

       /** @var ApiRequestHandlerLocator $apiRequestHandlerLocator */
       $apiRequestHandlerLocator = $masterFactory->getApiRequestHandlerLocator();
       $apiRequestHandlerLocator->register(
           'get_bestseller',
           $apiVersion,
           $this->getMasterFactory()->createBestsellerApiV1GetRequestHandler()
       );
   }

   public function createBestsellerApiV1GetRequestHandler() : BestsellerApiV1GetRequestHandler
   {
       return new BestsellerApiV1GetRequestHandler(
           $this->getMasterFactory()->createBestsellerService(),
           $this->getMasterFactory()->createContextBuilder()
       );
   }

   public function createBestsellerService() : BestsellerService
   {
       return new BestsellerService(
           $this->getMasterFactory()->createDataPoolReader(),
           $this->getMasterFactory()->createProductJsonService()
       );
   }
}

The factoryRegistrationCallback() method receives a master factory. It gets an ApiRequestHandlerLocator from it and registers new REST API endpoint. Very straightforward.

That’s all. Right?

No. Let’s write an integration test which will ensure all we just wrote works in real life.

class BestsellerApiTest extends AbstractIntegrationTest
{
   public function testEmptyJsonIsReturnedIfNoProductsMatchTheRequest()
   {
       $httpUrl = HttpUrl::fromString('http://example.com/api/bestseller');
       $httpHeaders = HttpHeaders::fromArray(['Accept' => 'application/vnd.lizards-and-pumpkins.bestseller.v1+json']);
       $httpRequestBody = new HttpRequestBody('');
       $request = HttpRequest::fromParameters(HttpRequest::METHOD_GET, $httpUrl, $httpHeaders, $httpRequestBody);

       $factory = $this->prepareIntegrationTestMasterFactoryForRequest($request);
       $factory->register(new BestsellerFactory());

       $implementationSpecificFactory = $this->getIntegrationTestFactory($factory);

       $website = new InjectableDefaultWebFront($request, $factory, $implementationSpecificFactory);
       $response = $website->processRequest();

       $this->assertEquals(json_encode([]), $response->getBody());
   }

   public function testProductDetailsMatchingRequestAreReturned()
   {
       $httpUrl = HttpUrl::fromString('http://example.com/api/bestseller');
       $httpHeaders = HttpHeaders::fromArray(['Accept' => 'application/vnd.lizards-and-pumpkins.bestseller.v1+json']);
       $httpRequestBody = new HttpRequestBody('');
       $request = HttpRequest::fromParameters(HttpRequest::METHOD_GET, $httpUrl, $httpHeaders, $httpRequestBody);

       $factory = $this->prepareIntegrationTestMasterFactoryForRequest($request);
       $factory->register(new BestsellerFactory());

       $implementationSpecificFactory = $this->getIntegrationTestFactory($factory);
       $this->importCatalogFixture($factory);

       $website = new InjectableDefaultWebFront($request, $factory, $implementationSpecificFactory);
       $response = $website->processRequest();

       $this->assertGreaterThan(0, count(json_decode($response->getBody(), true)));
   }
}

As you can see the test class extends AbstractIntegrationTest which is just a set of helper methods shared across integration tests. We will use just 3. I believe their names clearly reveal the intent:

• prepareIntegrationTestMasterFactoryForRequest
• importCatalogFixture
• getIntegrationTestFactory

So as the importCatalogFixture is only called in the second test the first one deals with an empty catalog so bestsellers REST API call must return an empty JSON and for the second it mustn’t be empty.

This is it. A REST API call is ready. Of course the use case is very simplified, but it all comes down to the logic which the service class uses to select matching products. But as to the REST API endpoint, it is just implementing a service class, a request handler and their factory.

Security

Unfortunately, most merchants, most agencies and most developers only take it seriously once they have been affected
by a hacked store directly. This is what can happen:

• Customer Data stolen
• Access Data stolen
• Payment Data stolen
• Site taken offline

Each of those incidents can mean costs high costs - there are statistics saying that the average cost is about 150 $ per
lost or stolen record (see www.ibm.com/security/data-breach/).

Example

Just one example which happened to me a year ago: during a shop analysis I found a modified core file lib/Varien/Object.php.
At the beginning of the file, one line of code was added:

This line of code stores all data entered in the checkout process and in the admin area in a single hidden text file which everyone
could download and decode. The exploit was active for 6 months and contained:

• 5,628 datasets (email address, name, telephone)
• 1,612 passwords (a part of them could probably have been used for other services like PayPal)
• All admin usernames and passwords.

The line of code was probably added by using a security hole.

Counter-Measures: The Obvious

There are a few things which should be respected by every developer and every shop manager:

• Keep your Magento updated
• At least apply security patches
• Keep PHP and other server software up to date
• Don't use the default admin username / password
• Don't use common usernames and passwords

If you are following this advice, you should be safer than 90% of all Magento stores online worldwide which will make
attacking your shop relatively hard and not worthwile for most attackers. Though, if you make any of the following
mistakes, you'll have a problem:

Top 10 Worst Magento Practices

10: Downloadable Code

Don't put your whole code on GitHub - unprotected! Also, if you have your .git directory in your main directory, make sure
noone can access it through the browser - otherwise your whole repository can be downloaded and scanned for security issues.

Top 9: Downloadable Data

Don't put your database dumps anywhere where they can be accessed by browser, especially not in the main directory.
Not having any links to the file doesn't help much - the files can be found anyways. You don't want anyone to get all your
customer data including password hash.

Top 8: Unprotected Executables

Those files can be called via the browser by anyone. Depending on the script, calling them can cause importing or exporting
data or doing any other operation, possibly severely messing up your system. For example: if a reindexing script is called
several times in a row, it can block the whole system.

Top 7: Unprotected Database Credentials

Depending on your server configuration, having your app/etc/local.xml open to access via browser can mean anyone can
have access to your database server. Having database access, they can for example read or delete all your customer data or
create new admin accounts.

Top 6: Unsecured Admin

Change your admin URL from /admin/ to anything else. If an attacker can't find the location of your admin area easily,
he will likely go on to another shop which is easier to hack.
The same goes for the /downloader/ URL. You can't change that easily so it's best to deactivate it completely.

Top 5: Unsecured Tools

If you have any external tools for your store, make sure they can't be accessed without authentication. The image shows
Magmi, a tool for importing data into Magento. I found this tool through a simple Google search and
would have been able to take over the whole system with that. The installed Magmi version allows to install a newer
version of itself up update but doesn't check the source, so I could download any version, add some backdoor code and
upload it via the web interface.

Nearly every external tool can be misued, so please be extra careful about that. I have seen unprotected external tools
which allowed to change appearance of a configurator or access all order data.

Top 4: Patches not applied

If you don't install security patches released by Magento or install the latest Magento version, you are vulnerable
to attacks. Example: the Shoplift bug which was patched by Magento in Febuary 2015. In April 2016, still
50,000 out of 250,000 Magento shops were not patched and thus vulnerable to it (Source: byte.nl).
That makes 50,000 easy targets. Don't let your store be one of them.

In order to get to know about security issues, I recommend subscribing to the official Magento Security Alert Registry.

Top 3: Insecure Modules

Hmm, do I want to install this module?
"return base64_encode(base64_encode(base64_encode(..." #realmagento

— Andreas Mautz (@a_v_o_g_t) 20. Mai 2015

If you don't know the developer of a module well, you can never know if there isn't some malware or security issue included.
To be sure, you need to do a review of every module you are installing to your store.

Important: If you are serious about security, never install a module which is encrypted (i.e. with Ioncube) or obfuscated.

Top 2: Database Tools

I found this database management tools during a store review. You should never install database management tools
(like PhpMyAdmin or Adminer) on your store without additionally protecting them as security issues are found in them
regularly.

In this case it was even worse: you don't even need MySQL credential as they have been pre-filled. So you have full
access to the database if you know the (simple) filename which can be guessed or found out otherwise.

Top 1: Backdoors

I also found this file in the store review I mentioned above. An input field with the output of the path of the file?
Well, looking into the sourcecode made the purpose of that file clear:

You can run any server command through this simple web interface. No authentication, no protection, and the power to
do everything on the server you want, depending on the server configuration. Don't do that!

Conclusion

Those have been the most hair-rising issues I found in the last years working with Magento. I am sure there are more;
probably every experienced Magento developer can add his/her own examples.

It's hard to impossible to make a Magento store (or any online store) 100% secure, but it's not too difficult to make
it hard enough for attackers so they choose different targets. If you avoid the above mentioned mistakes, you will
have reached that goal.

To check your goals, I suggest using MageReport by byte.nl. It will scan your store and tell you
if there are severe security problems left on your store. It will even email you about new issues found if you
register (for free).

Like Magento 1, the core of a Magento 2 is PHP MVC framework. And just like Magento 1, Magento, Inc. use the architecture and conventions of the underlying framework to create the base digital commerce application, which is available as a free "Community Edition" and a licensed "Enterprise Edition" which adds functionality, scaling capacity, and enhanced core integrations appropriate for enterprise businesses.

Magento 2 offers new features and improvements over Magento 1 in the following areas:

• Architecture & Conventions
• Modularity
• Configuration
• Customization
• Performance & Scaling
• Systems Integration

As a Magento 1 developers review the Magento 2 filesystem and application, they will have two broad reactions:

"That Looks Familiar…"

• Tons of out-of-the-box commerce and framework functionality
• Multisite capability
• Internationalization features
• Shared themes
• Two distinct frontends: one for customers, one for administrators
• Modular architecture
• MVC with proprietary ORM, powerful blocks & PHP+HTML templates, and thin controllers
• User-configurable entities via EAV
• Powerful layout XML for composing views
• Configuration XML

"…What is That?!?"

• Developer documentation
• New module registration & activation conventions
• Configurable dependency Injection
• Plugins, a system for focused customization of core and community functionality; think of every public method as consumable event
• Composer, a (the) PHP dependency manager
• Tests: unit, integration, and functional
• Native CLI component, an extensible tool for performing developer and ops tasks
• Service layer, an architecture for defining extension points
• UI components, an approach which ensures consistent design and enables efficient client-side rendering

I'll go through some of these topics below. If there is interest in other topics, please let me know via comments here, on Twitter, or at ben@magento.com.

Installation

While Magento 1 had only one official way to install (via archive), there are three methods for installing Magento 2. Most developers will want to create a project via Composer. If you want to contribute to the Magento 2 core via pull request, then you will use git clone. Another option is direct download of the metapackage, but this has limited applicability for developers. The best place for complete information on Magento 2 installation is the DevDocs section on installation. DevDocs is our developer documentation hub, which is open for contribution via pull request.

Given that Magento 2 has different system requirements for its Web stack compared to Magento 1 (especially PHP 7), and due to additional technologies used by the core (such as Varnish and Redis), many developers are turning to virtualization for their developer environments. We have an official Docker setup for developers coming out soon (email me if you want early access). There are also several community-maintained Vagrant and Docker projects. I personally use MageScotch from Joshua Warren on my MacBook Pro, and find it to be responsive and easy to maintain.

Architecture & Conventions

Magento 1 originated in 2006-07, with roots planted before Composer - before testing was in vogue, and before other cultural shifts which have given us modern PHP. In fact, some parts of Magento 1 go all the way back to the days of PHP 4, as there was originally some concern about hosting adoption of PHP 5 at the time (who remembers those days?). Magento 1's architecture was sophisticated when it was born, but these days evinces its age.

Magento 2 architecture seeks to simplify modification and integration by emphasizing true modularity via the following conventions: federated, constructor-based DI which displaces the so-called Mage god class from Magento 1; Composer-based dependency management along with semantic versioning; and an injected framework association which allows core concerns such as rendering to be replaced with the smallest footprint possible. This is by no means a complete list, nor does it describe current state for all components. The Magento 2 approach sees us more closely following the principles of SOLID, though there is still much refactoring to be done.

Versioning

In order to facilitate Composer usage in Magento 2, we employ two version numbers. There is the so-called metapackage version (e.g. 2.1.3) which is used as a marketing version. We use metapackage versions in our communications around functional, security, and bug releases. Underneath this is the so-called platform version (e.g. 102.x.x), for which we follow semantic versioning. This approach allows for extensions and customizations to better target core module versions.

Dependency Management

Composer, Composer, Composer! PHP's dependency manager is an essential tool when working with Magento 2. Core modules and libraries are associated via Composer, and Marketplace - our new extension app store - relies on Composer as well.

Modularity

Magento 2 modules have all code, configuration, and theme assets under one main folder. This is different from Magento 1, which confusingly have both PHP classes and configuration underneath a root module folder, but theme assets under a separate path. Another couple of changes from Magento 1 to Magento 2 is the loss of codepools (core, community, local) under ./app/code/, and the ability to store modules under ./app/code/ or in the ./vendor/ folder.

Regarding the two roots for Magento core code: if you are planning to contribute to the Magento 2 core, you will clone from GitHub and therefore have Magento core modules under ./app/code/; if you are doing anything else then you will likely have Magento core modules under ./vendor/. Framework code is similarly variable in location.

Decoupling & Dependency Injection

Coupling is a pervasive issue in Magento 1. Coupling comes in many forms and is a bane to both extensibility and testability. For Magento 2 we removed the Mage god class, as its global scope complicates testing and binds code into context. We've almost totally removed direct class instantiation, replacing it instead with constructor-based dependency injection and an object manager which saves us from the insidious implicit coupling that can plague constructor-based DI.

It is worth noting that the MVC framework of Magento 2 is almost entirely abstracted away from the application modules via dependency injection. The last main vestige of coupling between application and rendering framework is the abstract block class, and there is work underway to remove this dependency. There are also plans to move away from model-based CRUD in a future release of Magento 2; see our lead architect's explanation about this on Magento SE.

Configuration

Like its forebear, Magento 2 is a primarily configuration-based system (as opposed to convention-based), and the mechanism of configuration is still XML. However, there are two major improvements to Magento 2's config XML: use-based organization in multiple files and schema definitions (XSD). In Magento 1 the main module configuration file (config.xml) is a wide-open DOM for mixed multiple concerns, such as store-scoped configuration data, class name mapping, route configuration, module-specific settings, email settings. This unrestricted, unstructured approach has been a constant source of confusion while learning and cause of errors while developing. A further complication is that the execution-scope version of some parts of the DOM is derived from both the filesystem and the database!

In Magento 2 we still make ample use of XML for configuration, but to improve usability and reduce developer errors we separate XML into different files which indicate the XML's usage. For example, acl.xml contains permission node configuration only. Try to add a functionally-unrelated node to your module's acl.xml and your IDE should indicate the error. Another good example is config.xml, which now only contains default store-scoped values, all the more important given that these values are merged with DB-stored configurations.

Another dimension of improvement in config XML organization is the separation of config XML file types by area. This can typically be seen in route, event, and DI configuration. While the associated XSDs are the same, the directives in these files can be scoped according to functional areas, typically global (etc/*.xml), customer/public (etc/frontend/*.xml), and admin (etc/adminhtml/*.xml) - note that other areas exist and additional areas can be defined. This removes another level of hierarchy from the DOM structure. An additional benefit of this approach is more granular caching and in-memory performance of these structures.

Layout XML

Layout XML has evolved in Magento 2 to better serve its purpose. In addition to being covered by an XSD, it is more intuitive to understand what each element does. In Magento 1, the concept of a page is just another block, but in Magento 2 pages are now a separate element with better encapsulation of the things which are relevant to a page, such as how many columns there are. Structural blocks such as the left and right columns are similarly differentiated from functional blocks. Going up a level, the storage of these directives is now broken out by layout handle per file, which improves both overall readability and ease of determining what a given module is doing to the view in a given view scope.

Customization

An essential feature of commerce applications is the ability to be customized based on merchant requirements. One of the most exciting things about Magento 2 are the many customization mechanisms. Just like Magento 1, Magento 2 has events which the observer system which can consume in multiple scopes. Replacing one class with another still exists as well. In Magento 1 these are called rewrites and are declared in configuration XML. In Magento 2 these are called preferences and are effected via the DI system. What makes Magento 2 more extendable is the plugin system. Magento 2's plugin architecture is inspired by Aspect-Oriented Programming. It allows to declare in di.xml some class and method which will be executed before, after, or around any public Magento method. The complete syntax and explanation for Magento 2 plugins is available on DevDocs.

The benefit of plugins cannot be understated: they facilitate focused addition to or (if necessary) override of application code (whether local, core, or third-party). Magento 1 developers who have ever wanted an event where one did not exist have experienced the problem that plugins solve - especially if a class rewrite was out of the question.

Testability

Thanks to the tireless work of luminaries like Sebastian Bergmann, Chris Hartjes, and others - along with the ever-sophisticating trend of PHP development - software testing is now de rigueur in PHP. Core testability is therefore an essential concern for Magento 2 (a reality which simply doesn't exist for Magento 1). Our initial and current architectural approach is driven by the need to make classes and components testable, and you can find multiple test types in the Magento 2 core: unit, integration, and functional. Given that fact, covering your custom code with tests is not really an option anymore. While testing may be new to many Magento 1 developers, fortunately there are a number of resources to learn PHP testing in general. There are also Magento 2-specific testing resources; Vinai Kopp's Mage2katas series is a great place to start.

Contribution

Magento 2 is the ability to contribute via pull request, which was not possible in Magento 1. This took considerable retooling of how we engineer, but it has been an important part of the Magento 2 story. 2.0 was released with numerous PRs as part of mainline, and we have many, many more waiting review & merging. It is not ideal to make PRs sit in queue for so long, so we are currently putting substantial effort into both our ability to process PRs and our ability to release more frequently, so that contributions can make it into Magento 2 more quickly.

Conclusion

There is a lot more to the Magento 2 story. As mentioned earlier in the post, I am eager to hear which of the topics listed (or even additional topics) you might like me or my colleagues to write about. I hope you will take a look at Magento 2 and join this next phase in Magento's evolution.

But do you really know how to use composer? Let me give you some tips and tricks to help you to organize the source code of your projects.

Note: I will consider that you already have composer and git installed on your machine.

Composer allows you to manage your dependencies. We often use a git repository behind each dependency. Also, if your dependency is packaged, it becomes possible to use the archive ball instead of the sources.

Git is there to help you organizing your developments. Yes! It is not only a versioning tool. You can use it like me, every day, as a powerful tool, helping me organizing my commits and my git trees and branches.
And composer doesn't work without git (in fact it does, but I can't recommend it during development).

By using both of them at the same time we can go so far in industrialization and code maintainability.

So, following are few things I wanted to share.

Managing versions, even during development

When you ask composer to include a dependency without specifying its version, it will try to install the latest available version. In other words the last tag in the git repository, or maybe not the last, but always the higher.

You can indicate a multitude of methods of resolution depending on how you name the required version.

If your dependency doesn't have any tag (which means no version) then you can use the @dev version which indicates to take the last commit in the main branch.

If you want to use a specific state of your project, using the commit hash, you can do it by specyfiyng it in the require node in the composer.json like "jacques/foo": "dev-master#5538b1e".
In that case the version 5538b1e of the master branch will be used.

I prefer to use the dev-master notation for our internal modules because we know that their master branch is always stable.
But be careful! Never use an unstable version (like @dev or dev-branchname) outside your project. So, no unstable dependencies into a module which will be distributed.
You can do it but the composer.json should also contain any unstable dependencies required by your dependencies! Does it make sense to you?

In other words, if you require a dependency A which has itself a dependency to B version @dev, composer will stop you as it's impossible to install an unstable package.
If you still want to do it, you'll also have to require the B package version @dev. In that case, it's ok, because all de development releases (or unstable versions) are specified in your own composer.json.

If your tag is name v1.0.1 then the version to use in your composer.json will be 1.0.1. Composer making itself the prefix removal.

You can use the tilde ~ sign to specify that only the minimum minor version can change.
As examples:

• ~1.2.3 as >=1.2.3 AND <1.3.0.
• ~1.2 as >=1.2.0 AND <2.0.0. In that case the 2.0.0-beta1 version which is considered as <2.0.0 won't be used because the major version is updated. Which is forbidden by the tilde "rules".

In other case it's the ^ symbol which allows you to install any version before any BC break.
Example:

• ^1.2.3 as >=1.2.3 AND <2.0.0

You should always prefer to use a strict version number to define your dependencies. You'll avoid a lot of headaches.
By fixing the commit hash or directly with a strict version number, as you prefer.

In your libraries or modules, prefer ^ because the theory says that still a version doesn't have any BC break, it's compatible with your code.
In practice it's not always the case. But you can have hope and chance! And maybe all your dependencies follow the semantic versioning rules. Like you of course!

Composer alias to fix conflicts or only to change the version of a dependency

Composer is a powerful tool. But it doesn't know how to resolve conflicts between two versions of the same package.

Let us take the example of the world wide known library jacques/yolo, which has Hoa\Zombie version ^2 (same as ~2.0, >=2.0,<3.0) as a dependency.

But what if you really need a version greater than 3.0 in your project?

Houston, we've had a problem.

Should composer use the version 2 (required by a dependency) or 3 (required by you) of your dependency?

If you require the version 3 (the latest version available) in your own composer.json you'll get an error:

$ composer require hoa/zombie
Using version 3.16.01.11 for hoa/zombie
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - jacques/yolo dev-master requires hoa/zombie 2.* -> satisfiable by hoa/zombie[2.14.09.17, …] but these conflict with your requirements or minimum-stability.

Installation failed, reverting ./composer.json to its original content.

As you can see composer wants to use the version 3.* but it can't because the package jacques/yolo uses already that package, but in its version 2.*.

Don't worry. We have aliases!

Let's update our composer.json manually. We have to add the dependency by ourselves because the previous command failed and the changes have been reverted.

In the node require of your composer.json, add the following dependency: "hoa/zombie": "3.16.01.11 as 2.14.09.17".
We have to be strict with the version because that's how aliases work. We just told composer to use the version 3.16.01.11 instead of the 2.14.09.17.

So now our dependency to 3.* is downloaded and installed because the conflict is solved!
But be careful, the dependency in jacques/yolo is 2.* and not 2.14.09.17. So… maybe you'll have to do it again.

But if the version 3 is on its way, there are not so much possibilities that the version 2 will evolved a lot. Kind of safe.

We had this problem with composer and its own version in Magento 2. True story bro.
So, it's possible to upgrade some dependencies of Magento 2. And because they fixed every version, it should be easy and "safe".

Aliases can fix some issues but it is better to avoid them. Like always, if you can do it without getting around it, do it!
They are like rewrites in Magento 1, it is better without.

Repo path

If you want to manage a module, like a theme, aside your app folder you can do it using the path repository of composer.

Ok, given the following tree:

.
├── .git/
├── apps/
│   └── magento2/
│       ├── composer.json
│       └── …
└── modules/
    └── Mbiz_Price/
        ├── composer.json
        └── …

In our Magento 2 we want to install our Mbiz_Price module.
But this module is outside the apps/magento2 folder. It can be a theme, or anything else.

It has its own composer.json, with the name (jacques/mbiz_price) of the package.

Let's go in our magento2 folder and run some commands to require our Mbiz_Price module:

$ cd apps/magento2
[apps/magento2/] $ composer require jacques/mbiz_price

  [InvalidArgumentException]
  Could not find package jacques/mbiz_price at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability

Hum… Of course, how could composer be aware of our local package?

We have to update our composer.json (in apps/magento2): (very simple version, for the purpose of the article)

{
    "repositories": [
        {
            "type": "path",
            "url": "../../modules/Mbiz_Price",
            "options": {
                "symlink": true
            }
        }
    ],
    "require": {
        "jacques/mbiz_price": "*"
    }
}

Now we run the update of composer:

[apps/magento2/] $ composer update jacques/mbiz_price
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing jacques/mbiz_price (dev-master)
    Symlinked from ../../modules/Mbiz_Price

Writing lock file
Generating autoload files

But wait! How do we define a version for Mbiz_Price? Why *@dev?

As you can see in the initial tree, we are in a git repository, and this repository is on a branch (we don't really know which one) and our module is tracked by this repository.

How to translate "our repository is on a branch, but we don't know which one" to a version number?

*@dev makes sense isn't it!? * stands for "any version" and @dev stands for development branch (which is equal tocurrent branch).
But… You'll probably have few questions, like this one:

If we update the content of Mbiz_Price/, do we have to run composer update again? Even after few commits?

No. You don't have to.
You can notice the "symlink": true in the options node. This option allows you to forget about the content of your package.

If you don't want to symlink your package, you'll have one big problem: your package won't be able to change its version. It means that even if you add a lot of content in your module, then you commit them, then you run a composer update (in order to update the module in your magento2 project), you'll get something like this:

[apps/magento2/] $ composer update jacques/mbiz_price
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files

Using the symlink option is safer.

The only moment the package will be updated is when you checkout another branch. In that case, because the branch name is important to composer, the hash will be updated.

So, one important thing to avoid updating the composer.lock too much times: always run a global composer update on the same branch (like develop).
If you are on a specific branch (like feature/my-stuff), always update only the packages you need, like composer update jacques/yolo. Be specific is the best thing to do.

If you don't follow any rules, you'll have some strange behaviors with composer, but nothing really hard to solve, don't be afraid.

Metapackages

When you have a lot of dependencies you use in all your projects (or most of them…) you can probably create a metapackage!

A metapackage is like a shortcut, or a Pandora box (depending on what you have in it). You require the metapackage and the metapackage requires other dependencies, which require other dependencies… inception!

It's only a composer.json, nothing more, nothing less.

It is useless to add some require-dev (see below) in your metapackage because composer won't install them in your project.

Be careful, never use an unstable version in your metapackages. And it's better to fix the versions of your dependencies (like 1.0.1), unless you know that your code is well developed.
In that case you can have a version like ^1.0, but not ~1.0. Because the caret is considered as stable, the tilde is considered as dev stability.

We use the caret symbol in our Mbiz_MetaPackage.
We fixed the versions of our dependencies mostly to ^0.1 (which means >=0.1.0,<1.0).

But we don't use a specific version for our metapackage because we want to specify the right version on each project.
So, to require the metapackage we run the following command:

[apps/magento2/] $ composer require monsieurbiz/mbiz_metapackage:dev-master#8af4f6d
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing monsieurbiz/mbiz_setup (0.1.1)
    Loading from cache
  …
Writing lock file
Generating autoload files

And we are done!

We do that because the metapackage can change. It always has more or less dependencies, depending on our developments.
Using the caret in the metapackage dependencies allows us to have a more stable version of them. But specifying the hash of the metapackage gives us a safety check: we won't get a new dependency magically after running a composer update!

Unlike other dependencies, the metapackage project is not installed in your vendor/ directory.

Have a look to the "Satis" part below if you want to know how to host the references of your private packages.
Why the power of composer should be available only for public repositories?

require-dev: the toolbox!

It is possible to use the require-dev node, instead of the main require node.

In that case, if your dependencies are in require-dev, they will be installed only if you don't speficy the --no-dev when you run any composer command.

It works well on Magento 2 because a dependency is really a dependency in the vendor/ directory.
It doesn't work well on Magento 1 since it uses a lot of symlinks in your app/ folder.

So, let's use the package jacquesbh/eater, which is really simple. It's like the Varien_Object in Magento 1, I'm sure you know it.

But we only want this package during development, not in production.

[apps/magento2/] $ composer require --dev jacquesbh/eater
Using version ^2.0 for jacquesbh/eater
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Writing lock file
Generating autoload files

You can require(-dev) a lot of tools like symfony/debug or symfony/var-dumper!

In Magento 2 it is possible to add a lot of commands to the magento binary. Don't hesitate to create your own commands available only for the developers and not in production.
It can save a lot of time to your team. Human operations are never safe!

Scripts

Composer can run some scripts when some events appear, like "a package just got installed" (post-package-install event).

So, if you want to run some commands, like running a shell command (chmod +x bin/magento as example), you can easily do it in your composer.json:

{
    …
    "scripts": {
        "post-update-cmd": [
            "chmod +x bin/magento"
        ]
    }
}

You can, by example, execute the run of your test suites after updating your dependencies.

You can also add some commands to composer, using them like composer yolo. Here is howto:

composer.json:

{
    …
    "scripts": {
        "yolo": "echo yolo"
    }
}

Then:

[apps/magento2/] $ composer yolo
> echo yolo
yolo

It can be perfect to run some commands like phpunit, or…
If you alias (bash alias) composer to c (like I do), and you add a command mage, you can do that kind of things: c di.

Which will run ./bin/magento setup:di:compile as example.

Or simply… c mage setup:di:compile or c mage my:command to run any command using the magento binary.

{
    …
    "scripts": {
        "mage": "php ./bin/magento"
    }
}

So now, imagine you add your own commands using the require-dev and run them with ease directly using composer! So perfect.

c mage dev:my:command

Tip about symfony/console: ./bin/magento set:di:com is the same as ./bin/magento setup:di:compile! Shortcuts are everywhere!

Packagist or satis ?

Packagist is the main composer repository. You can add your public packages directly by registering them on https://packagist.org.

You can get your own version of packagist by cloning/forking it. But it can be kind of a huge application if you have only few packages.

What about your own and simple composer repository?

Do you know satis?

Satis is a simple composer repository. It is really easy to install.

Firegento has its own satis running. You can use it for a lot of Magento 1 modules.
To use it, you can add it to your project's composer.json by using this command:

composer config repositories.firegento composer https://packages.firegento.com

Or globally by using this command:

composer config -g repositories.firegento composer https://packages.firegento.com

Last thing about composer repositories: Jordi Boggiano created Toran Proxy: it is a private and hosted composer repository. I can recommend it if you don't want to maintain your own packagist or satis instance(s). It can be used as a backup repository in case github goes down too! Very helpful if you have a lot of projects depending on github.

A project template?

I hope you installed Magento 2 using composer! If you did it, you probably remember this command line:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition my-project/

Now, we take a look at the composer.json of the magento/project-community-edition package:

{
    "name": "magento/project-community-edition",
    "description": "eCommerce Platform for Growth (Community Edition)",
    "type": "project",
    "version": "2.1.2",
    "license": [
        "OSL-3.0",
        "AFL-3.0"
    ],
    "require": {
        "magento/product-community-edition": "2.1.2",
        "composer/composer": "@alpha"
    },
    "require-dev": {
        "phpunit/phpunit": "4.1.0",
        "squizlabs/php_codesniffer": "1.5.3",
        "phpmd/phpmd": "@stable",
        "pdepend/pdepend": "2.2.2",
        "fabpot/php-cs-fixer": "~1.2",
        "lusitanian/oauth": "~0.3 <=0.7.0",
        "sebastian/phpcpd": "2.0.0"
    },
    "config": {
        "use-include-path": true
    },
    "autoload": {
        "psr-4": {
            "Magento\\Framework\\": "lib/internal/Magento/Framework/",
            "Magento\\Setup\\": "setup/src/Magento/Setup/",
            "Magento\\": "app/code/Magento/"
        },
        "psr-0": {
            "": "app/code/"
        },
        "files": [
            "app/etc/NonComposerComponentRegistration.php"
        ]
    },
    "autoload-dev": {
        "psr-4": {
            "Magento\\Sniffs\\": "dev/tests/static/framework/Magento/Sniffs/",
            "Magento\\Tools\\": "dev/tools/Magento/Tools/",
            "Magento\\Tools\\Sanity\\": "dev/build/publication/sanity/Magento/Tools/Sanity/",
            "Magento\\TestFramework\\Inspection\\": "dev/tests/static/framework/Magento/TestFramework/Inspection/",
            "Magento\\TestFramework\\Utility\\": "dev/tests/static/framework/Magento/TestFramework/Utility/"
        }
    },
    "minimum-stability": "alpha",
    "prefer-stable": true,
    "repositories": [
        {
            "type": "composer",
            "url": "https://repo.magento.com/"
        }
    ],
    "extra": {
        "magento-force": "override"
    }
}

The package type is project. Which means that we can use it with the create-project command.
That command copies everything which is in the project in your project directory then runs a simple composer install.

And because it runs a composer install, we can see that it requires a magento/product-community-edition: a metapackage.

This project defines the Magento repository, it forces the stability of the packages to alpha (not great… but because of composer in @alpha, but it's not required because the stability is forced when you use the @ operator in a version).
It adds some autoloads to composer and some require-dev packages. These packages will be installed because they will be in your main composer.json (because it's copied from the project).
It means that by default you'll have phpunit and so on, installed on your machine.

Oh, and by the way, if you can't do the composer create-project command because your platform doesn't have all the system dependencies (like some PHP extensions) but you'll run your project on a VM so you don't want them to be installed, you can use the --ignore-platform-reqs as an argument of your command:

composer create-project --ignore-platform-reqs --repository-url=https://repo.magento.com/ magento/project-community-edition my-project/

Much better!

Here is the composer.json of the metapackage magento/product-community-edition: (with some … to avoid to paste it entirely)

{
  "name": "magento/product-community-edition",
  "description": "eCommerce Platform for Growth (Community Edition)",
  "version": "2.1.2",
  "license": [
    "OSL-3.0",
    "AFL-3.0"
  ],
  "type": "metapackage",
  "require": {
    "magento/magento2-base": "2.1.2",
    "php": "~5.6.5|7.0.2|7.0.4|~7.0.6",
    "zendframework/zend-stdlib": "~2.4.6",
    "zendframework/zend-code": "~2.4.6",
    "…": "…",
    "ext-simplexml": "*",
    "ext-mcrypt": "*",
    "ext-hash": "*",
    "ext-curl": "*",
    "…": "…",
    "magento/module-marketplace": "100.1.1",
    "magento/module-admin-notification": "100.1.1",
    "…": "…",
    "magento/module-catalog": "101.0.2",
    "magento/module-wishlist": "100.1.2",
    "…": "…",
    "magento/theme-adminhtml-backend": "100.1.1",
    "magento/theme-frontend-blank": "100.1.1",
    "magento/theme-frontend-luma": "100.1.1",
    "magento/language-de_de": "100.1.0",
    "magento/language-en_us": "100.1.0",
    "magento/language-es_es": "100.1.0",
    "…": "…",
    "magento/framework": "100.1.2"
  }
}

That metapackage requires every dependencies of Magento 2.

So, to be clear with the "project" thing:

You can create a package with the project type.
This package is a project "template". Everything in it will be copied to your new project directory.
It can require some packages and metapackages in order to init the dependencies of your new project.

Creating a composer project is really a time saver. With it you can initiate a lot of projects, depending on what you want to create.
You can store all your "projects" on a satis repository or even on Packagist.

Conclusion

It was a mega big article because composer is a great great tool.

If you use it great, you can reduce the time you spend on maintainance. And you can really improve your developments.

By creating some metapackages, some projects, using the power of the versions to install whatever you want to.

And a last tip… Please bookmark http://composer.json.jolicode.com/!

"There is no problem that community cannot solve." @benmarks #mn15ny pic.twitter.com/twNNQkrKwn

— Sherrie Rohde (@sherrierohde) September 21, 2015

I couldn’t agree more, and I think even beyond that, there is simply no limit to what we can accomplish when we work together.

What does this look like for our community?

In 2015, the Magento community:

• presented over 500 talks on Magento or at Magento-centric events,
• produced over 100 podcast episodes centered around Magento,
• organized conferences and meetups in over 24 different countries,
• wrote three books about Magento,
• contributed to official product documentation and core code,
• wrote countless blog posts to raise awareness and education, and
• answered thousands of questions on both StackExchange and the Magento Forums.

While 2016 is not quite over, it's still clear this community is running forward at a rapid rate!

So far in 2016, the Magento community has:

• presented over 725 talks on Magento or at Magento-centric events,
• produced over 100 podcast episodes centered around Magento,
• organized conferences and meetups in over 34 different countries,
• written seven books about Magento,
• contributed to official product documentation and core code,
• written over 1,000 blog posts to raise awareness and education, and
• answered thousands of questions on both StackExchange and the Magento Forums.

In addition to everything above, your endless efforts of testing, feedback, pull requests, and reported issues have all helped improve our product to make it better meet your needs as well as the needs of your customers and our broader community. (Yay, open source!)

How can we keep working together?

Whether you’re new to the Magento Community (hi!) or a veteran looking for more ways to get involved, here’s a few ideas:

• Answer, or ask, questions on the Magento Forums or Stack Exchange.
• Find a local Magento Meetup (or start one) to meet others who use and develop on Magento.
• Listen to advice from Magento Masters on how to contribute (from their MageTitans panel).
• Check out our Contributor Guide to learn how to get started contributing to DevDocs and our core code on Github.
• If none of those work for you, check out my post on How to Get Involved in the Magento Community for even more ideas (or ask me!).

Huge thank you to Fabian Blechschmidt and Tobias Vogt for organizing this Magento Advent Calendar, and inviting me to be a part of it, as well as to Hirokazu Nishi for organizing the Japanese Magento Advent Calendar.

You, the Magento Community, are my heroes and I look forward to what else will happen as we continue to work together. Bring it on, 2017!

According to its dictionary explanation, an estimate is a guess of what the size, weight, value, amount, cost, duration of something might be.

It goes without saying that a prediction of what will happen in the future is something that can't be accurate and fixed by definition.

Nevertheless we are often asked to provide the "right estimate" for a software project in a short period of time (because bids don't wait) and, to make things worse, without a clear understanding of the context.

Why estimates don't work

Before presenting my approach to calculating a project cost, I'd like to recap the two key factors that undermine estimates accuracy:

• Accidental complication
• Unknown unknowns

Accidental complication

In his famous video "7 Minutes, 26 Seconds, and the Fundamental Theorem of Agile Software Development", J. B. Rainsberger shows how the total cost of a feature can be expressed as the sum of the cost of essential complication with the cost of accidental complication.

Essential complication is due to the fact that the problem we have to solve is hard. But, as domain experts, we can exploit our skills, discover similarities and be good enough at estimating the cost of essential complication.

Accidental complication is due to the fact that we are not so good at our jobs. It's the errors we make at designing systems; it's the mess we leave in our code because we have no time to clean it up; it's the overhead we introduce when we add people to a project (thinking that nine women can make a baby in one month).

As we can guess, the list is a long one and the following comic strip by Jason Heeris is just another hilarious but meaningful example of accidental complication:

Since the cost of accidental complication dominates the one of essential complication, one way to make the total cost more predictable is reducing accidental complication as much as we can.

Unknown unknowns

Another aspect that has a very big impact on estimates accuracy is our attitude to ignore events that are outside the model under investigation.

Indeed it's easier to focus only on the known unknowns, that are things that we know we don't know.

For example, if a requirement is "I want marketing automation" we don't know what exact features the customer needs but, since we know what's unknown, we can make some analysis on that domain to provide a better estimate of the cost.

Here is another, not so highly improbable, example of unknown unknown: a platform security patch released in the middle of the project development which breaks, say, our brand new integration with the marketing automation system. Sounds familiar, doesn't it?

We can't predict such an event because it isn't under our control. What's more, we can't avoid applying the patch, since it solves a security issue that has just become public and exposes the customer to potential risks.

Sure enough, the patch release has nothing to do with the domain we were focused on and every minute spent dealing with it isn't included in our estimate.

We can fill out a detailed list of highly improbable events that can occur, the so called black swans that change the game and send our estimates up in smoke.

But we can't rely on such list because, like it or not, uncertainty will always find it's way into the project in new, fancy and unpredictable ways.

Calculating a project cost

As we have seen so far, to calculate a project cost we can't take into account only essential complication but also accidental complication and uncertainty.

Thus, to estimate the cost of a project development, we can apply the following rules:

• Reach consensus on essential complication
• Do our best to reduce accidental complication
• Prepare for change

Reach consensus on essential complication

We know how to estimate essential complication: we can count on our attitude to find similarities and weight features based on our past experience.

Write down all the features; we can choose the formalism we prefer but let's consider writing them down as user stories. The main benefit of user stories, to me, is their focus on purpose, that is the reason why a feature is needed.

Then gather the team that will be responsible of bringing those requirements to life. I use the general term team and not developers because a feature is not necessarily a matter of pure software development. Ideally even the customer should take part to this activity, mainly to provide more details during discussion.

Ask the team to estimate the effort of development of each feature.

To express the effort we can use man-hours, man-days, story points, bananas or another unit we like.

Whatever the unit, I warmly suggest to use a non-linear sequence like: 1, 2, 3, 5, 8, 13, 20, 40, 100.

This way the higher the estimate the more the people will be obliged to make a choice between distant numbers, unleashing uncertainty and generating more discussion and details.
This, in turn, will likely bring to break the requirement into smaller and more estimable chunks.

For each requirement:

• each team member writes down his or her own estimate without sharing it with others until the next step;
• all members' estimates are revealed and compared one by one; differences generate discussion that goes on until the team reaches the consensus on a number;
• if consensus isn't reached in a reasonable amount of time (minutes) it likely means that some information is missing; ask more details to the customer, if possible, and estimate again; alternatively trust the estimate from the ones who have some past experience on the development of a similar requirement.

This technique is called planning poker and it definitely makes the estimating process more fun. And if estimating is fun, people will be willing to do it.

It takes a while to get used to this technique but after the initial inertia it's impressive how fast it turns out.

I've used this technique a lot (both using printed cards or this free tool) and the real benefit it gives is the discussion and the seek for details that it generates.

Do our best to reduce accidental complication

Dealing with the root causes that produce accidental complication is a good way to reduce it.

For example, performing code refactoring is a good way to "clean the kitchen" and wipe out technical debt, that is, accidental complication.

Writing automated tests is a proven way to encourage refactoring.

Test driven development (TDD) lets us design better systems, because it avoids premature optimizations and over-engineering.

Pair programming and code review are other techniques that can help us catching design defects earlier.

Useless to say, learning and using solid programming principles and the best available tools and habits is gold.

Since there aren't work-for-all recipes, my advice is that of trying them and choosing those that give us concrete benefits.

To accomplish this goal it's important to measure the outcome: write down the time we spend developing features, use different techniques to develop the same (or equal-weighted ones) and compare the result. Measuring is the key.

Note: before the planning poker session begins we should be clear with the team: the additional cost of applying practices that reduce accidental complication should be taken into consideration.

Prepare for change

If we accept the idea that, sooner or later, uncertainty will mess up things within the project, we need to be prepared for change.

Since unknown unknowns can impact both project costs and delivery dates, embracing change means giving up the illusion that we can control every aspect of the project through a long-term plan (usually represented with a Gantt chart).

Just like a sat nav system does when it drives us from A to B, we need to be ready to recalculate our route as soon as an unexpected event occurs and changes the plan.

This likely means that project costs increase or delivery dates change, so our customer should be prepared. Obviously nobody is happy if this happens but after all we are not paid solely to work for a fixed amount of time or money, we are hired to reach a goal. If something obstacles us, the best we can do is finding alternatives to reach that goal; stopping in the middle of a project not to exceed a fixed time or budget doesn't bring any value to the customer.

Let's consider that exceeding time or budget is not always mandatory: we can reduce the scope and make our best to respect time and budget constraints.

To be able to reduce the scope it's essential to prioritize tasks and define what can be postponed or dropped out when we will encounter black swans.

Conclusion

As we have seen, calculating a project cost is not only a matter of estimating how difficult it is to develop a set of features.

There are other factors that have a huge impact and that have to be taken into consideration in order to give a prediction that is as close as possible to reality.

Nevertheless, we can't avoid to be prepared to embrace change, because thinking that everything can be under control is an illusion.

If you have your opinion about some of the tools and techniques I mentioned in this article or have different experiences you like to share, please leave a comment or contact me and let's discuss about that.

Bibliography

• Duarte, Vasco. No Estimates: How to measure project progress without estimating. OikosofySeries, 2016. Web. http://noestimatesbook.com/.
• Rainsberger, J. B. 7 Minutes, 26 Seconds, and the Fundamental Theorem of Agile Software Development. Web. https://vimeo.com/79106557
• Brooks, Frederick P. The Mythical Man-month: Essays on Software Engineering. Reading, MA: Addison-Wesley Pub., 1982. Print.
• Fowler, Martin, and Kent Beck. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, 2000. Print.
• Taleb, Nassim Nicholas. The Black Swan: The Impact of the Highly Improbable. New York: Random House Trade Paperbacks, 2010. Print.
• Taleb, Nassim Nicholas. Antifragile: Things That Gain from Disorder. New York: Random House Trade Paperbacks, 2014. Print.

LESS concepts to know

The definition of a variable can be placed after its assignment:

#selector { attribute: @foo; }
@foo: bar;

// Result:
#selector { attribute: bar };

The last assignment of a variable wins:

#selector { attribute: @foo; }
@foo: foo;
@foo: bar; // wins

@import "file" defaults to @import (once) "file":

@import 'foo.less';
@import 'bar.less';
@import 'foo.less'; // ignored
@import (multiple) 'foo.less'; // imported a 2nd time

The Magento 2 approach to mobile first

In its default themes Magento splits CSS into two main CSS files:

1. styles-m.css (common and mobile related definitions)
2. styles-l.css (desktop related definitions)

The desktop styles are loaded "on top" of the mobile ones and will only be effective above a certain breakpoint (defined in Layout XML and rendered in the HTML <head/> section.

Quick reminder: Fallback & Code generation in Magento 2

If a requested CSS file is not in it's place, Magento will look for a .less file with the same name and then trigger server side compilation (assuming developer mode is enabled).

We always want to compile our LESS to CSS via the provided grunt tasks, as it is much more perfomant.

While compiling, the Magento fallback system will be respected for requested LESS resources. See Magento 2 Developer Documentation for details.

Defining the "entry points" in Layout XML

In magento/vendor/magento/theme-frontend-blank/Magento_Theme/layout/default_head_blocks.xml the before mentioned CSS entry points are defined. Notice the media query for styles-l.css:

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <head>
        <css src="css/styles-m.css"/>
        <css src="css/styles-l.css" media="screen and (min-width: 768px)"/>
        <css src="css/print.css" media="print"/>
    </head>
</page>

This will be rendered to the following HTML in the pages <head/> section:

<link  rel="stylesheet" type="text/css"  media="all" href="http://your-site.com/static/frontend/<Vendor>/<theme>/<locale>/css/styles-m.css" />
<link  rel="stylesheet" type="text/css"  media="screen and (min-width: 768px)" href="http://your-site.com/static/frontend/<Vendor>/<theme>/<locale>/css/styles-l.css" />

Scaffolding common and mobile styles

In magento/vendor/magento/theme-frontend-blank/web/css/styles-m.less a lot of things happen, so we will analyze it step by step. Its structure may be a little confusing, as the sequence of imports and variable assignments is not absolutely intuitive. One has to follow each @import statement and draw a map to get an overview - and keep in mind, that, like stated above, in LESS the assignment/use of a variable can happen before the actual definition. You can find a complete, merged, gist of the file here.)

@import 'source/_reset.less'; // Imports: magento/vendor/magento/theme-frontend-blank/web/css/source/_reset.less

    // Resolves to:
    & when (@media-common = true) {  // @media-common defined in: magento/lib/web/css/source/lib/_responsive.less
        .lib-magento-reset(); // defined in: magento/lib/web/css/source/lib/_resets.less
    }

The above executes the .lib-magento-reset() Mixin, which basically returns a buch of plain CSS to render at the very beginning. Notice: Both the variable and the mixin are defined in the base lib and are not imported yet.

@import '_styles.less'; // Imports magento/vendor/magento/theme-frontend-blank/web/css/_styles.less

    // Resolves to:
    @import 'source/lib/_lib.less'; // Imports: magento/lib/web/css/source/lib/_lib.less
        @import '_actions-toolbar.less';
        //...
    @import 'source/_sources.less'; // Imports: magento/vendor/magento/theme-frontend-blank/web/css/source/_sources.less
        @import '_variables.less';
        @import (reference) '_extends.less';
        //...
    @import 'source/_components.less'; // Imports: magento/vendor/magento/theme-frontend-blank/web/css/source/_components.less
        @import 'components/_modals.less'; // Imports from lib: magento/lib/web/css/source/components/_modals.less
        @import 'components/_modals_extend.less'; // Imports from local: magento/vendor/magento/theme-frontend-blank/web/css/source/components/_modals_extend.less

(For readability the code listing is shortened. You can find a complete, merged, gist of the file here.)

Here it may become even a bit more confusing. First of all the actual base lib is included as fallback.
Then most of them are overridden by local files from the blank theme. In addition _extends.lessis imported as reference, which seems to be some redundant - considering the following import:

// styles-m.less; line 18
@import (reference) 'source/_extends.less';

According to LESS behaviour, the second @importstatement would be ignored.

After that, some Magento 2 Magic happens:

//  Magento Import instructions
//  ---------------------------------------------
//@magento_import 'source/_module.less'; // Theme modules
//@magento_import 'source/_widgets.less'; // Theme widge

Magento 2 extends vanilla LESS by its own fallback logic. The @magento_import directive has to be commented out with a double slash to not interfere with the default LESS @import one. It iterates over all active modules and resolves every path for the given file relative to the current working directory. So the above would render to:

@import '../Magento_Catalog/css/source/_module.less';
@import '../Magento_Cms/css/source/_module.less';
//...
@import '../Magento_Catalog/css/source/_widgets.less';
@import '../Magento_Cms/css/source/_widgets.less';
//...

If you would place an equivalent file to your own module it would be rendered here as well. This is an intended hook for module designers.

The next statement...

//  styles-m.less
// ...
//  Media queries collector
//  ---------------------------------------------
@import 'source/lib/_responsive.less';

...invokes general media queries depending on the @media-target scope:

// magento/lib/web/css/source/lib/_responsive.less
// ...
& when (@media-target = 'mobile'), (@media-target = 'all') { ... }
// ...
& when (@media-target = 'desktop'), (@media-target = 'all') { ... }

In our case only the first block gets executed, as of the following definition:

// styles-m.less
@media-target: 'mobile'; // Sets target device for this file

Besides this, crazy magic things are happening in magento/lib/web/css/source/lib/_responsive.less

According to the documentation:

Magento UI library provides a strong approach for working with media queries. It's based on recursive call of .media-width() mixin defined anywhere in project but invoked in one place in lib/web/css/source/lib/_responsive.less. That's why in the resulting styles.css we have every media query only once with all the rules there, not a multiple calls for the same query.

Sounds good to me, but by the actual writing of this essay, I honestly am not yet understanding how it actually works.

So if some of you already figured this one out, just leave a comment here or open an issue/pull request at my github.

Next there is a general hook for overriding the themes variables:

//  Global variables override
@import 'source/_theme.less';

//  Theme file should contain declarations (overrides) ONLY OF EXISTING variables
//  Otherwise this theme won't be available for parent nesting
//  All new variables should be placed in local theme lib or local theme files

Last but not least we get another final opportunity to extend on a module basis by using a _extend.less file:

//  Extend for minor customisation
//@magento_import 'source/_extend.less';

And thats it: styles-l.less works pretty much the same - just ommiting inclusion of base lib and setting desktop scope.

Obviously, this can only be the starting point to get productive, but I hope it provides an initial overview of the components pulled into rendering by default in Magento 2 blank theme, thus helping you kickstart your first frontend.

But what would be best practice to build a new theme then?

I don't think there is a distinct answer. It totally depends on the project and your personall approach.
If you decide to use the built in framework - wich I neither recommend nor discourage you to do - then Magento has a couple of key concepts to consider:

• If you inherit from the blank theme, the Magento 2 CSS library is imported and can be used instantaneously.
• For minor adjustments first try find a corresponding variable in magento/lib/web/css/source/lib/variables and overide them in your themes web/css/source/_variables.less file.
• Every base lib file can be extended by putting an equivalently named file in your web/css/source/ directory
• Global variables are meant to be overidden in your themes web/css/source/_theme.less
• In addition you can use the final hook of placing a web/css/source/_extend.less file to your theme. Keep in mind though: this is a @magento_import directive iterating over all modules. So you could use this in your cutom module, too.
• You can extend/overide module related styles by placing an own equivalent Vendor_Module/web/css/source/_module.less or Vendor_Module/web/css/source/_widget.less file in your theme.

Further more you could even think of adapting the CSS entry points to your own need, to pull in just the base lib components you really need, for example. I mean, if you wanted to... ;)

Oder auch: Was passiert eigentlich, wenn’s schief läuft.

Ihr sucht einen Artikel, in dem erzählt wird, wie ihr am besten einen Talk gebt, dann habe ich hier leider nichts für euch. In diesem Artikel geht es wirklich nur darum, wie ihr das ganze so richtig gut vermasseln könnt.

Aber warum?
Es gibt eine enorme Menge an sehr guten Artikeln und Videos darüber, wie es am Besten gelingt, einen Talk auf einer Konferenz oder einer Usergroup zu geben. Ich möchte mich nicht in diese Reihe eingliedern, sondern vielmehr aufzeigen was passiert, wenn es schief läuft.

Aber warum?
Ganz einfach, ich würde gern sehen, dass sich mehr Leute auf die “Bühne” trauen und sprechen.

Einige Links zu oben genannten, sehr guten Artikeln und Videos, findet ihr übrigens am Ende des Artikels, solltet ihr auf der Suche nach eben diesen sein.

Na dann los, ich teile den Prozess des auf der Bühne Sprechens in drei Teile auf, in denen so einiges, in verschiedener Form, schief gehen kann.

Auf der Bühne stehen und sprechen besteht nämlich in der Tat nicht nur daraus eben dieses zu tun, sondern auch aus einem Davor und einem Danach.

Teil 1 - Davor:

Was kann ich machen, um vorher schon sicher zu stellen, dass mein Talk in die Hose geht?

Die richtige Idee für den Talk ist nicht leicht zu finden, korrekt?
Eigentlich ist es total einfach. Nehmt das Nächstbeste, über das ihr gerade Schimpft oder etwas, das ihr schon ewig kennt. Achtet dabei allerdings nicht darauf, ob es jemanden interessiert.

Ein paar Beispiele:

• Installation und Deployment von Magento 2 ;)
• Geschwindigkeit von und Programmierung in Typo3.
• Die Benutzung von Strg+C, Strg+V.
• Hello World in JavaScript.
• Eine ToDo Liste, in welcher Sprache auch immer.

Es gibt hier sicherlich noch viel mehr Themen, allerdings haben wir mit dem Thema alleine noch nichts in den Sand gesetzt. Selbst eine Stunde über STRG+C und V kann durchaus, bei hohem Entertainment-Wert, ein genialer Talk werden. Wir müssen uns also noch etwas mehr anstrengen.
Wichtig ist, dass ihr das Thema entweder gar nicht kennt oder sowas von auswendig, das ihr keine Ahnung mehr habt wie die einfachsten Dinge funktionieren. Zum Beispiel wäre es geradezu genial, über die neuesten HTML Features zu sprechen, wie das alles ganz smooth über ein super tolles Framework läuft aber dabei keinen blassen Schimmer mehr zu haben, wie eigentlich ein HTML5 Grundgerüst ausschaut.

Das passende Tool ist nicht etwa Powerpoint, wie jetzt viele meinen würden. Wir brauchen hier was richtig gutes. Wie wäre es also, wenn wir was selbst programmieren würden, das funktioniert dann auch ganz bestimmt tadellos. Aber auch ein, gerade gestern erst auf dem Markt erschienenes, neue Framework, welches ihr auf eurem Rechner unter XAMPP oder ähnlichem selber hosten müsst, erfüllt seinen Zweck.

Auf jeden fall nicht sowas wie Powerpoint oder gar Google Slides, wir wollen ja schließlich, dass es schief geht oder die Slides gar nicht zur Verfügung stehen.

Ganz wichtig in diesem Zusammenhang ist auch, dass ihr keinerlei Backup vorbereitet, also weder ein USB-Stick, mit dem ihr wegen des super fancy slide Framework ohnehin nichts anfangen könnt, noch Ideen, über was wäre wenn. Denkt einfach gar nicht darüber nach, es macht einen nur zusätzlich nervös und es wird mit Sicherheit nichts schief gehen.

Bei dem Erstellen der Slides achtet bitte darauf, dass ihr alle und ich meine alle tollen Funktionen des Frameworks ausnutzt, warum erkläre ich dann später im nächsten Teil. Weiterhin achtet darauf, dass alle Slides sehr gut gestaltet sind, dies ist immens wichtig. Zeitloses Design kommt übrigens immer gut an, also gerne mal verschiedene hellgraue Farbtöne auf weiß setzen, damit die Schrift schön und grazil wirkt. Auch ratsam ist, eine tolle Schriftart mit zum Beispiel ganz feinen Buchstaben oder extrem Fetten, vielleicht sogar im Wechsel, zu benutzen. Eine Webfont bietet sich an, welche dann zufällig nicht verfügbar ist, weil es auf der Konferenz nur mittelmäßiges W-LAN gibt. Hierbei ist darauf zu achten, dass die Fallback Schrift nicht auf die Slides passt aber wir machen uns ja ohnehin keine Gedanken über einen Fallback.

Natürlich könnten wir uns jetzt Teil 2 und 3 sparen, wenn wir einfach kurz vor der Konferenz absagen aber dies wäre etwas zu langweilig, außerdem sind wir ja der Meinung extrem gut Vorbereitet zu sein – zumindest sollten wir uns dies oft genug einreden.

Okay, damit sind schon einige Vorbereitungen getroffen, los geht’s auf die Bühne.

Teil 2 Die Bühne:

Wie stelle ich es am besten an, ein möglichst schlechtes Bild abzugeben?

Vorab: die Nervosität ist unser Freund und natürlich haben wir direkt vor der Präsentation noch 5 Tassen Kaffee und eine Flasche Wasser getrunken.
Wir kommen natürlich zu spät zum Talk, weil wir zuvor noch schnell auf Toilette waren oder sonst wo, Hauptsache wir kommen zu spät. Denn wir wissen, wer zu spät kommt, hat automatisch einen großen Auftritt. Die Anzahl der Minuten ist hier entscheidend, zu kurz wird verziehen und oft nicht weiter bewertet, zu lang und die Leute sind unruhig, stehen schon auf und gehen. Der beste Zeitpunkt ist also, wenn die Leute anfangen unruhig zu werden, wenn nun der Talk angefangen wird und ihr euch am besten damit entschuldigt noch was wichtiges gemacht zu haben, wissen die Leute woran sie sind.

Nachdem die Realität einen nun vollends erschlägt und uns zeigt, wie schlecht wir vorbereitet sind, beginnt den Talk bitte unbedingt damit zu erzählen das ihr nicht vorbereitet seid und dies doch zu entschuldigen sei. Zack, schon hat das Publikum raus wie viel es euch bedeutet, nämlich gar nichts. Allerdings, gibt es immer ein paar Leute die es erst später kapieren, wir müssen uns also doch noch etwas anstrengen.

Das Publikum verärgert ihr am besten, wenn ihr es erst gar nicht beachtet, schenkt denen einfach gar keine Aufmerksamkeit. Diese Taktik ist auch recht effektiv für den Abbau der Nervosität. Vielleicht sucht ihr euch einfach einen Punkt auf der Bühne, den ihr die ganze Zeit fokussiert. Dies kann auch die Leinwand sein, der Vorteil bei der Leinwand liegt auf der Hand, das Publikum sieht nur den Hinterkopf und ihr könnt die wildesten Grimassen schneiden, wenn jemand eine, natürlich dumme, Frage stellt. Fragen werden übrigens grundsätzlich ignoriert oder aber übergangen, je nachdem wie sicher ihr euch bei der ein oder anderen Technik fühlt.

Weil uns nun bewusst ist, dass wir nicht richtig vorbereitet sind, haben wir in der Nervosität natürlich vergessen, was auf den Slides steht oder über was wir eigentlich sprechen wollten. Kein Problem, wir sind ja ohnehin schon zur Leinwand zugewandt, also lesen wir einfach den Text von den Slides vor. Einige ablesefehler sind immerhin besser als gar nichts zu sagen.

Nun sollten auch die Hartnäckigen begriffen haben, dass ihr euch nicht um sie schert, Gratulation.

Um dies noch etwas abzurunden, achtet doch darauf Tatsachen mit Worten wie >wer das nicht weiß, kann eh nichts< oder >das ist ja eine Grundvoraussetzung< zu erklären, hier könnt ihr wertvolle Zeit sparen, anstatt das Publikum vom wissen her abzuholen. Einfach gar nichts zu komplexen Gegebenheiten zu sagen ist ebenfalls sehr effektiv aber eher die softe Variante, welche nervige Fragen hervorrufen könnte.

Natürlich haben wir auch noch unsere Slides und die ganze Technik auf der Bühne, hier können wir auch noch einiges draus machen. ihr habt hoffentlich nicht euren Laptop geladen oder etwa doch? - Wir wollten uns doch nicht vorbereiten, Pech, nun kann nur gehofft werden ihr habt genug Slides.

Was wir in jedem Fall haben, ist das super tolle Slide-Framework, von dem das Publikum garantiert begeistert sein wird. Durch die Nervosität und dadurch, das wir mit dem Framework so gut wie nicht vertraut sind, springen wir also teils wahllos zwischen und auf den Slides hin und her. Dies machen wir so lange bis wir es geschafft haben uns selbst total zu verwirren.

Natürlich haben wir auch Programme wie Pushbullet oder Browser-Notifications, genau wie die Windows Notifications nicht abgeschaltet und den Bildschirm einfach auf den Projektor dupliziert. Das ist besonders hilfreich um den Talk mit absolut unberechenbaren Informationen zu bereichern wie >Schatz, hast du eigentlich deine Unterhosen gewaschen?< oder >Hey, hammer Party gestern, warst mal wieder total betrunken.< aber auch Firmeninterna, aus dem noch geöffneten Slack-Channel, können hier die Stimmung steigern. Wir handeln schnell, wechseln von der Präsentation auf den Desktop, wo neben PornHub und wichtiger Firmendokumente der Slack-Channel darauf wartet geschlossen zu werden.

Kurz rot werden, schnell alles schließen und mit dem Ablesen weiterer Slides, das nun wieder aufmerksame Publikum, loswerden. Jetzt ist der Moment gekommen an dem wir, in unserem hellblauen Hemd, T-Shirt oder was auch immer, absolut sichtbar durchgeschwitzt wie ein Hochleistungssportler, mit einem hochroten Kopf da stehen und der Talk zu Ende ist.

Wir haben es geschafft, bravo.

Aber Moment, warum sitzen da denn im Publikum immer noch Menschen und warum Applaudieren denn manche davon? Haben wir am Ende doch noch irgendwas ausgelassen um alles zu einem Desaster werden zu lassen?

Teil 3 Danach:

Lieber schnell weg hier.

Total geschockt davon, dass es applaudierende Leute gibt, sehen wir natürlich nun zu, dass wir so schnell wie möglich aus den durchgeschwitzten Klamotten raus kommen und verlassen sofort die Konferenz. Ansonsten würden wir ja nur noch mit unseren Erfolgen konfrontiert werden, dies gilt es zu vermeiden.

Im Hotel oder Daheim angekommen, denken wir schon ganz anders über den Talk nach. Yeah, wir haben es geschafft und die Leute haben applaudiert, wir fühlen uns toll, schlau, geradezu überragend. Schnell Twitter, auch gerne Facebook öffnen und der Welt erzählen, was für einen grandiosen Talk wir gerade gegeben haben. Wichtig ist hier sich keine Tweets von anderen über den Talk durchzulesen, Selbstreflexion brauchen wir nicht, denn wir wissen ja, dass wir gerockt haben.

Wir haben gerockt, Yeah, also am Besten gleich den nächsten CFP ausfüllen.

Sicherlich habt ihr aufgemerkt, als die Menschen am Ende wegen unserem Talk applaudiert haben, warum ist das so? Vorab, ich hab schon vieles der genannten Sachen gesehen, durch andere erzählt bekommen oder habe sie selbst vermasselt, ein zwei Sachen sind natürlich auch erfunden. Alle haben aber eines gemeinsam, es wurde der Mut aufgebracht um vor anderen, auf einer Bühne zu sprechen. Selbst wenn nur abgelesen wurde, durch Nervosität oder mangelnde Vorbereitung etwas schief geht, so ist es doch wahrscheinlich, dass einige Menschen im Publikum die Idee verstehen. Es ist sogar wahrscheinlich, dass sie was davon mitnehmen oder gar eine tolle Zeit hatten, weil sie genauso empfinden oder es amüsant war.

Wurde etwas extrem vermasselt, gibt es natürlich Kritik und vielleicht ist es dann auch nicht das richtige, vor anderen Menschen zu sprechen. Dennoch habt ihr es getan, eure Ideen mitgeteilt und das ist enorm wichtig. Würden wir nämlich alle unsere Ideen zurückhalten, nur weil wir nicht sprechen wollen, Angst davor haben oder besorgt sind, wäre vieles tolles auf dieser Welt nicht möglich.

Meine Bitte an euch, vermasselt es so richtig auf der “Bühne” aber sprecht, teilt eure Ideen und seid vielleicht, sobald die Nervosität sich gelegt hat, offen für Kritik und Diskussionen.

Ich hoffe sehr, euch hat meine kleine Geschichte etwas gefallen, vielleicht habt ihr ja bald das Glück und seid auf einer Konferenz, auf der mein Talk mit selbigem Titel zugelassen wurde. Wenn ja, dürft ihr natürlich gerne auf mich zukommen und mir persönlich Kritik äußern, beziehungsweise mir Feedback geben.

Falls dies nicht passiert, nutzt einfach die Kommentarfunktion oder Twitter @ToH_82.
Die Slides für den Talk könnt ihr übrigens hier finden: Slides.com: How to mess up talking.

Nun wie versprochen einige Quellen die zeigen, wie ein Talk von der Ideenfindung bis hin zur Feedbackrunde, aufgebaut werden kann.

• How To Give the Killer Tech Talk — A Pamphlet
• How to prepare and write a tech conference talk
• ‘Thought Leader’ gives talk that will inspire your thoughts
• THOUGHTS ON PUBLIC SPEAKING BY ZACH HOLMAN

There is no Magento or Meet Magento community.

Or, at least, there is not THE ONE AND ONLY community of Magento and Meet Magento.

Let’s have a look at what “community” really means:

community [kuh-myoo-ni-tee], noun.

“a social (umm, yes), religious (...somehow…), occupational (yep), or other group sharing common characteristics or interests (hmmm don’t know what this could be…) and perceived or perceiving itself as distinct (totally agree!) in some respect from the larger society within which it exists.”

Since I started to work for Meet Magento Association in January, I am involved in Meet Magento and this whole community topic for almost one year. I had to struggle with the same emotions and challenges all the other newbies did, but most of all I noticed one main thing: the community is no community at all, at least not in the common sense. Magento related people spread all over the world, and this is why it is consisted of cultures, languages, people, sexes, professions and characters that can’t be more different. And each culture, each local Meet Magento event and its partners, attendees and sponsors, can be described as another, minor community.

Originally coming from Sociology, I learned that humans can only build personalities and understand themselves as individual, if they have an opposite. We see our counterpart with all his or her characteristics, and we understand our similarities and, much more important, our differences. That’s the way it works - to find out a community’s attributes, we need to point out the differences to the rest of the world.

When we step down in the complexity of this whole community-topic, we’re only exploring more and more diversity than before. And each group, each community-like bunch of people, is setting its boundaries to other groups, cultures, professions and persons to create its own personality. And going deeper in all those different microcosms, the diversity of groups gets bigger and bigger.

But at the end - and this is what makes the community of Magento and Meet Magento so special - there is one thing that connects us all. All people are driven by the same questions, interests, problems and same passion. However, every group just keeps dissociating itself by profiling from all the other communities that aim exactly the same as they do.

Despite all the network tools we use, the most important aspect for people is to meet and talk to each other. Magento events are therefore relevant. In the Magento world are so many events starting from meetups, developer activities, small and huge conferences up to Imaginge. The magic here is that nearly 98% of them are organized by people outside of Magento Inc. We all organize our eco system, not the system vendor. I can feel this heart beat worldwide in my every day work. A company can never drive such a movement. Only people outside can do it. The Magento eco system is a wonderful example for the diversity of human beings. Bringing people together and exchanging knowledge are the ties that connect us all over the world - no matter what sex we are, what professions we learned or what language we speak. It brings people from all kinds together. So let’s just use “community” in its most common sense:

community [kuh-myoo-ni-tee], noun.

“joint possession, enjoyment, liability.”

The year end time is a good moment to remember that we all live in one world. There may be borders and conflicts, but in the Magento community so many different people are connected and stand together. We all make a difference. For 2017 enrich our community with all your knowledge, your flaws and cranky manners, your enthusiasm, passion and enjoyment, and let us sit together.

via GIPHY

Wenn es nun damit getan wäre, könnte man sich natürlich 14 Tage hinsetzen und alles Mögliche einrichten - StackOverflow sei Dank, wird es in 50 % der Fälle sicher dann auch laufen. Aber was ist, wenn wir etwas anpassen müssen oder ein Fehler ums Verrecken einfach nicht verschwinden will? Dann stehen wir da - meist mit runtergelassener Hose.

Herausforderungen bei Magento 1

Bei der Entwicklung von Magento 1 gibt es einige Herausforderungen:

1. Wie speichere ich das ganze Projekt, damit ich es auch auf dem Kundenserver wieder ausspielen kann?
2. Wie erfasse ich meine Änderungen?
3. Wie verkürze ich zwingend notwendige, übliche Arbeitsschritte?

Dummerweise gibt es diese Fragen nicht nur bei der reinen PHP Entwicklung. Bei Websites tanzen wir ja auf den verschiedensten Hochzeiten: HTML, CSS, JavaScript, PHP, SQL. Jeder dieser Bereiche hat seine eigenen Herausforderungen und zwingt uns, eigene Tools zu verwenden.

Viele Lonesome Rangers, die sich nicht in großen Agenturen zu Zahnrädchen haben machen lassen, können meist nicht die Zeit und das Geld aufwenden, um all diese Anforderungsbereiche mit Bravour zu meisten. Meine Meinung: Ist auch gar nicht nötig. Nutzt lieber weniger Tools, aber habt euren Workflow fest im Griff. Dann könnt ihr besser mithalten, als diejenigen, die sich in immer wieder neuen, hippen Technologien verlieren. Ja: Diese neuen Technologien helfen - ohne Frage. Aber sie helfen nur denen, die sie auch meistern können und dafür ist leider immer mehr und immer komplexeres KnowHow nötig.

Eine einschränkende Vorbemerkung muss ich leider noch machen: Ich arbeite seit etlichen Jahren nun ausschließlich mit OS X und kann für die Webentwicklung auch ausschließlich Unix basierte Betriebssysteme empfehlen. Es hat sich in meinen vielen Schulungen immer wieder - und mit Magento 2 noch eklatanter - gezeigt, dass Windows zwar super für den Gaming- und Office-Einsatz geeignet, aber für solide Webentwicklung einfach scheiße ist.

Werbedisclaimer: Einige der hier genannten Tools kosten Geld. Ich verlinke zwar, verdiene aber nichts am Verkauf der Lizenzen. Ich bin mit den Programmen einfach sehr zufrieden und kann sie daher empfehlen. Unbedingt Geld ausgeben muss man aber nicht - auch wenn es zum Geld Verdienen meistens unerlässlich ist, auch welches auszugeben.

TL;DR

• Nutzt auf jeden Fall Git und haltet euch an GitFlow!
• Entwickelt lokal mit MAMP oder XAMP und vergesst Xdebug nicht!
• Um PHPStorm führt kein Weg herum, vergesst nicht Magicento!
• Geht mit SSH auf eure Kundenserver und nutzt dort ebenfalls Git!

Und wer's genauer und noch mehr wissen will, steht jetzt auf, holt sich was weihnachtlich Leckeres zu trinken (Kaffee, Kakao, Tee …) und liest weiter! Viel Spaß … es ist viel geworden ;-)

08/15 Werkzeug-Gürtel

Was braucht es also, um grundsätzlich ziemlich sauber mit Magento 1 entwickeln zu können?

• Eine … naja, DIE ordentliche IDE: PHPStorm (notfalls Derivate wie zum Beispiel Netbeans).
  • Bei PHPStorm: Magicento
• Git (mit zusätzlicher GUI: z. B. SourceTree)
• Lokale Serverumgebung (z. B. MAMP Pro) mit
  • Apache 2
  • PHP 5.6 (Magento 1 ist nur mit Patches auf PHP 7.x lauffähig)
  • MySQL 5.6 (notfalls auch 5.5)
• SSH Zugänge zum Server

PHPStorm

PHPStorm von Jetbrains hat sich als die State-of-the-Art IDE herausgearbeitet. Mit vielen wirklich nützlichen Features für PHP-Entwickler macht es einem das tägliche Entwicklerleben wirklich einfach. Um nur zwei zu nennen, die einem bei der Magento-Entwicklung helfen: CodeNavigation (mit einem Klick zur Implementation einer Klasse springen) oder CodeCompletion (beim Schreiben direkt mögliche Methoden vorgeschlagen bekommen).

Großer Vorteil für uns Entwickler ist dabei die extrem gute Performance bei diesen Aufgaben. Öffnet man ein Projekt zum ersten Mal, lastet PHPStorm den Rechner inkl. aller Cores aus und indiziert das gesamte Projekt. Dieser Vorgang dauert je nach Rechner und Projektgröße gerne mal 4-5 Minuten, anschließend ist dieser Index im Cache und aktualisiert sich on the fly, sodass das Suchen nach Methoden oder Dateien anschließend verzögerungsfrei passiert.

Oft wird PHPStorm mit Netbeans verglichen. Vor Jahren hatte auch ich mit Netbeans gearbeitet, aber wer einmal PHPStorm gesehen und vielleicht sogar benutzt hat, will nichts anderes mehr zum Programmieren verwenden, weil es einfach irrsinnig schnell und ungemein unterstützend ist.

Für PHPStorm legt man normalerweise Geld auf den Tisch. Es gibt aber auch das sogenannte EAP (Early Access Programm) bei dem man sich die aller neueste Beta für (immer wieder) 30 Tage kostenlos installieren kann.

PHPStorm bietet selbst bereits Clients für mySQL und Versionsverwaltungssysteme (in unserem Fall: git) und integriert deren Informationen dann nahtlos in den Editor. Das hat zur Folge, dass geschriebenes SQL direkt mit der Datenbankstruktur verglichen wird und Fehler oder Inkonsistenzen im Code markiert werden können. Die Git Integration zeigt einem bereits im Editor an, welche Zeilen hinzugefügt, geändert oder entfernt wurden und kann auch direkt die History der geöffneten Datei aufschlüsseln.

Ich selbst arbeite aber mit externen Tools, schlicht weil mir die doch sehr entwicklerlastige GUI in PHPStorm nicht wirklich zusagt. Die Tools an sich sind aber mächtig und durchdacht. Wer sich also SequelPRO oder SourceTree nicht antun möchte, kommt mit PHPStorm bequem und funktionsgewaltig durchs normale Entwicklerleben.

Wenn ihr noch kein PHPStorm nutzt, solltet ihr euch mal in den Dokumentationsvideos von Jetbrains umsehen. Sogar alte Hasen können bei den Features noch das eine oder andere Kleinod entdecken.

Magicento

PHPStorm hat noch einen weiteren Vorteil: Enrique Piatti ist selbst Magentician und entwickelt mit viel Hingabe Magicento, ein PlugIn für PHPStorm, das die Entwicklung von Magento 1 Inhalten (Extensions, Themes, etc.) massiv beschleunigt und die Fehlerquote drastisch senkt.

Magicento kostet mittlerweile pro Jahr 39 USD, die ich persönlich aber wirklich gerne bezahle. Ich gebe zu, ich bin ein Sparfuchs, und wenn es nicht sein muss, versuche ich mich auch um solche Beträge zu drücken. Aber für Enriques PlugIn würde ich sogar 50 USD im Jahr bezahlen, alleine deswegen, weil es unheimlich viele Standardarbeiten automatisch erledigen kann und mir somit mehrere Stunden Arbeit im Monat spart:

• Anlegen eines neues Moduls
  • Wahlweise mit oder ohne: Models, Blocks, Helpers, SetupScripts
  • AdminGrids inkl. Controller
• Theme-Arbeiten
  • Duplizieren einer Quelldatei an die richtige Stelle
  • Vergleich von Custom vs. Parent Theme
• Auflösen von Magento Factorynames ('catalog/product') für
  • CodeCompletion
  • CodeNavigation

Und hier ist die Liste noch lange nicht zu ende.

Git

An einer Versionsverwaltung (VCS) kommt man beim professionellen Arbeiten nicht mehr vorbei. Alles andere würde auch bei groben Fehlern schnell dazu führen, dass ihr komplett von vorne beginnen müsst.

Selbst wenn ihr also ganz alleine und nur auf eurem eigenen Rechner arbeitet, solltet ihr Git einsetzen, um eure eigene Arbeit nachvollziehbar und reproduzierbar zu speichern.

Warum Git?

Im Gegensatz zu anderen VCS ist Git dezentral aufgebaut. Das bedeutet, dass es eigentlich keinen zentralen Server gibt. Daher werden Dateien bei Git auch nicht "ausgecheckt" und sind damit für die Bearbeitung durch andere gesperrt.

Git spielt seine Stärke vielmehr in der Zusammenarbeit aus. Jeder Bearbeiter hat eine komplette Kopie des Projekts (das Repository) mit der gesamten Projektvergangenheit (Commit History) auf dem eigenen Rechner.

Arbeiten nun mehrere Leute parallel an einem Projekt, arbeitet erstmal jeder für sich auf seinem eigenen System in seinem eigenen Repo. Ist die eigene Arbeit abgeschlossen, synchronisiert man sein Repo mit den Repos der anderen Kollegen. Das kann natürlich bei 3 Kollegen müßig werden. Immerhin müsste jeder Kollege dann per TCP/IP erreichbar sein.

Hier kommen jetzt Dienste wie Bitbucket oder GitHub ins Spiel. Diese Dienste sind quasi auch nur ein weiterer Bearbeiter, mit dem Unterschied, dass sie keine Änderungen an eurem Projekt vornehmen, sondern lediglich eine Zentrale bieten, mit der sich alle synchronisieren können.

Weil Git dabei aber nur Änderungen (Diffs) der Dateien synchronisiert, ist zum einen die übertragene Datenmenge verhältnismäßig gering und es kommt eher selten zu Konflikten in Dateien, die von mehreren Personen parallel bearbeitet wurden.

Es gibt ein interaktives Tutorial, in dem man sich mit Git vertraut machen kann, wenn man noch nie mit Git gearbeitet hat. In 15 Minuten habt ihr, denke ich, ein ganz gutes Verständnis dafür, was Git genau ist und wie es euch bei eurer Arbeit helfen kann.

Arbeitsablauf mit Git

Damit nicht jeder in Git grad so rumarbeitet, wie es ihm gefällt, hat sich Vincent Driessen 2010 Gedanken gemacht, wie die Arbeit in Git sinnvoll und strukturiert ablaufen kann. Herausgekommen ist dabei: GitFlow.

GitFlow ist im Grunde kein eigenes Programm oder eine Ergänzung zu Git selbst, sondern viel mehr eine Art Ablaufbeschreibung, wie man in Git arbeiten sollte, wenn man bestimmte Aufgaben zu erfüllen hat.

Natürlich gibt es für die Kommandozeile auch kleine Helferlein, die diese Arbeitsschritte automatisiert ausführen können; technisch zwingend nötig sind sie aber nicht.

Einen guten Einblick in die Vorteile des Arbeitens mit GitFlow bekommt man auf einer Tutorialseite von Atlassian, die mit SourceTree auch ein kostenloses GUI-basiertes Git-Werkzeug anbieten, das GitFlow direkt unterstützt. Mehr dazu im nächsten Abschnitt.

Welche Aufgaben soll GitFlow denn nun eigentlich strukturieren:

1. Erarbeiten neuer Funktionen (Features)
2. Sicherstellen des Zustands der Staging-Umgebung (Development)
3. Sicherstellen des Zustands der Live-Umgebung (Master)
4. Integration von Notfall-Patches (Hotfixes)

Dabei ist es GitFlows Ziel, dass wir als Entwickler auf unseren Lokalen Maschinen in Feature-Branches entwickeln, die zu einem bestimmten Zeitpunkt aus dem Develop-Branch abgezweigt werden. Ist unsere Arbeit abgeschlossen und hinreichend getestet, mergen wir unseren Feature-Branch wieder in den jetzt vielleicht überarbeiteten Develop-Branch und stellen unsere Arbeit damit unseren Kollegen und im Staging-System zur Verfügung.

Sind alle Tests abgeschlossen und hat der Kunde sein Okay gegeben, erzeugt man aus dem aktuellen Stand des Staging-Systems (also dem Develop-Branch) ein Release und merged alle bis dahin aufgelaufenen Änderungen in den Master-Branch.

Wichtig bei GitFlow ist: Niemand arbeitet im Master-Branch und wenn möglich arbeitet auch niemand im Develop-Branch. Diese Branches werden immer nur durch einen Merge geändert.

Was nun aber, wenn man einfach mal gravierend Scheiße gebaut hat oder ein anderes Problem im Livesystem zutage tritt? Nun, dann macht man einfach einen Hotfix und GitFlow sorgt dafür, dass diese Änderung automatisch im Master- und Develop-Branch landet, ohne dass man diesen zweiten Merge händisch selbst ausführen müsste.

Alles in allem erleichtert einem GitFlow also das strukturierte und kollaborative Arbeiten ungemein und ich empfehle jedem, diesen Workflow auch dann zu nutzen, wenn man mutterseelenallein auf der eigenen Maschine vor sich hinentwickelt.

GUI für Git

Wie ich im Abschnitt PHPStorm schon erwähnt habe, ist ein eigenes Tool für die Arbeit mit Git im Grunde nicht zwingend nötig. Man kann es wahlweise wie ein Berserker wild auf der Kommandozeile treiben, oder man quält sich durch die hässliche PHPStorm-GUI-Implementation von Git; oder aber, man nutzt eben doch einfach ein weiteres, schickes Tool: SourceTree von Atlassian

Großer Vorteil: SourceTree ist kostenfrei verfügbar. Ich gestehe auch: Es könnte von der GUI etwas stylischer sein. Aber im Vergleich zur etwas schickeren, dafür aber kostenpflichtigen Alternative Tower ist es wenigstens performant.

SourceTree bietet euch eine schöne Übersicht über euer aktuelles Projekt mit der gesamten History, einer Liste mit allen Branches, die bei euch auf dem Rechner liegen und den Branches inkl. der History auf den "Remotes" (die Kopien der Repos bei Bitbucket, Github oder euren Kollegen).

Mit funktionalen Buttons in der Toolbar könnt ihr schnell und zuverlässig auf die üblichen Funktionen zugreifen.

Git und Magento

Es gibt bei der Arbeit in einem VCS mit Magento zwei unterschiedliche Ansätze:

1. Alles liegt im Git
2. Es liegen nur die neuen oder geänderten Dateien im Git, nicht aber die komplette Installation

Wir haben im Büro 71a beide Varianten ausprobiert. Unsere Projekte sind häufig "Feuerwehr"-Projekte, die wir von Agenturen übernommen haben, die sich mit Magento übernommen haben. Oftmals gibt es hier CoreHacks, sodass wir Git verwenden, um uns schnell über solche Änderungen zu informieren.

Dazu ist es aber unerlässlich, dass der gesamte Code des Projektes — inklusive Magento – im Repo gespeichert wird. Ändert sich also "heimlich" eine Core Datei, sehen wir das sofort. Diese Datei zeigt sich dann entweder als "geändert" oder taucht in der History. Für uns kommt daher mittlerweile nur noch Variante 1 in Frage.

Variante 2 hat zudem den Nachteil, dass man eine sehr umfangreiche .gitignore Datei pflegen muss. Git selbst meldet sonst nämlich alle Core-Dateien als "neue Datei" und würde diese am liebsten gerne ins Repo übernehmen. Mit .gitignore kann man sicherstellen, dass Git diese Dateien und Ordner gar nicht erst sieht. Je länger jedoch diese .gitignore Datei wird, umso langsamer wird auch git.

Git unterstützt übrigens zwei unterschiedliche .gitignore Dateien. Eine liegt im Repo und wird für gewöhnlich mit allen anderen geteilt. Eine weitere liegt und gilt global auf eurem Rechner.

Globale .gitignore_global

Ich nutze die globale Datei, um die Standardordner in meinem Projekten, die nichts im Repo zu suchen haben, direkt von vornherein auszuschließen. Diese Ordner sind zum einen systembedingt zum anderen von meiner Arbeitsweise geprägt:

*~
.DS_Store
.idea
.modman
app/code/community/Aoe/TemplateHints
app/etc/modules/Aoe_TemplateHints.xml
skin/frontend/base/default/aoe_templatehints

app/code/community/Hackathon/EmailPreview
app/design/adminhtml/default/default/layout/hackathon_emailpreview.xml
app/etc/modules/Hackathon_EmailPreview.xml
app/locale/en_US/Hackathon_EmailPreview

app/code/community/Mgt/DeveloperToolbar
app/code/local/Mgt/Base
app/design/adminhtml/default/default/layout/mgt_developertoolbar.xml
app/design/adminhtml/default/default/template/mgt_developertoolbar
app/design/frontend/base/default/layout/mgt_developertoolbar.xml
app/design/frontend/base/default/template/mgt_developertoolbar
app/etc/modules/Mgt_Base.xml
app/etc/modules/Mgt_DeveloperToolbar.xml
js/mgt_developertoolbar

app/etc/modules/AvS_ScopeHint.xml
app/locale/de_DE/AvS_ScopeHint.csv
js/scopehint/tooltip.js
app/code/community/AvS/ScopeHint
app/design/adminhtml/default/default/layout/scopehint.xml

config.codekit
.sass-cache/
.scss-lint.yml
vendor/

Damit schließe ich von vornherein aus, dass meine üblichen Entwicklertools (ScopeHint, TemplateHints, DevToolbar) überhaupt im Git auftauchen. Zudem gibt es Dateien meiner Programme, die ich ebenfalls nicht angezeigt bekommen möchte (modman, PHPStorm, CodeKit, OSX).

Projektspezifische .gitignore

Anschließend gibt es in jedem Projekt eine eigene .gitignore Datei für Dateien, die sich zwischen Entwickler-, Test- und Produktivumgebung ändern (Zugangsdaten, etc).

/app/etc/local.xml
robots.txt

Meistens stehen hier natürlich noch weitaus mehr Dateien, aber diese beiden Vertreter sind immer mit dabei.

Für beide gibt es eine Entsprechung im Git selbst: app/etc/local.xml.dist und robots.txt.dist. Die enthalten den Mustercode, mit dem ich dann auf den jeweiligen Systemen das Original erzeuge (siehe später beim Thema Deployment).

Bitte immer daran denken, dass ihr diese Dateien auf den jeweiligen Maschinen separat sichern müsst. Hier bietet euch Git kein Sicherheitsnetz durch versionierte Kopien! Einmal weg -> für immer weg!

Lokale Serverumgebung mit MAMP

Es gibt mittlerweile viele Entwickler, die sich mit Vagrant, Docker und hastenichtgesehen beschäftigen. Wie ich aber am eigenen Leib schon feststellen musste, ist das alles nur dann ganz hipp und witzig, wenn es mit den mitglieferten Tutorials und Skripten aus-der-Kiste-heraus (Anm. d. Autors: out-of-the-box) funktioniert. Geht's aber mal nicht, stehen wir da … ja … und dann? Stackoverflow driven error resolving durch copy'n'paste'n'trail'n'error.

Alles in allem ein echt zeit- und nervenfressender Prozess, der nur in wenigen Fällen zum erwünschten Ergebnis führt.

Einfacher ist es, direkt "bare metal" zu arbeiten. Das hat allerdings auch einige Nachteile, über die man sich im Klaren sein muss. Damit wir lokal überhaupt Magento ausführen können, brauchen wir einen Webserver, einen SQL-Server und PHP. Das alles vereint gibts mit MAMP (Pro). Die Investition in MAMP Pro (39 €) rentiert sich, wenn man viele Projekte parallel betreibt und sich die Zeit sparen will, die ganzen Domainkonfigurationen (vhosts) händisch zu erzeugen.

Um ehrlich zu sein: MAMP Pro ist jetzt nicht das geilste Teil vor dem Herrn, aber es tut, was es soll. Problematisch sind Upgrades, weil sich bei denen die PHP- und MySQL Konfigrationen in Luft auflösen. Problematisch ist das auch deswegen, weil bei MAMP Pro die Dateien mit dieser Konfiguration in völlig unwegbaren Untiefen des Systems verstecken. Nervig ist es auch, weil manche Konfiguration in plist-Dateien steckt, die sich nur fummelig zusammenführen lassen.

Diese Schmerzchen aber werden durch den Komfort einer lokalen Entwicklungsumgebung und der damit verbundenen Geschwindigkeit meines Erachtens aufgewogen.

Nachteil von "Bare Metal" Entwicklung

Normalerweise sind die Projekte unserer Kunden bei unterschiedlichen Hostern untergebracht, die alle unterschiedliche Konfigurationen – ggf. sogar unterschiedliche Betriebssysteme – laufen lassen. Ziel in der Webentwicklung ist es, mit der eigenen Entwicklungsumgebung so nah wie möglich am Live-System zu bleiben. Das ist mit der "Bare Metal" Arbeit quasi unmöglich. Alleine das Betriebssystem bei mir (macOS) dürften wohl bei den wenigsten Hostern so im Einsatz sein.

Immerhin kann ich in MAMP Pro die verwendete PHP-Version weitestgehend selbst einstellen. Mit dem mySQL Server sieht es da aber schon wieder ganz anders aus.

Wir müssen also darauf vertrauen, dass die Bugs und Performanceschwierigkeiten im Live- wie auch Stagesystem mit dem unseren zumindest tendenziell zusammenlaufen. Die Erfahrung zeigt, dass die PHP-Version wenigstens in der zweiten Stelle übereinstimmen sollte bspw: 5.6.21 auf dem Server, 5.6.25 im MAMP Pro und schon ist im Grunde alles gut. Die meisten Bugs sind meist unabhängig von der Serversoftware und treten so oder so auf.

Ein ganz wichtiges Tool, was man für die Magento Entwicklung in PHP auf jeden Fall auch braucht, ist Xdebug. In MAMP Pro gibt es dafür zum Glück ein Häkchen. Bitte daran denken: Ist Xdebug aktiviert ist PHP um längen langsamer. Braucht man also für die Arbeit im Frontend keine Xdebug-Unterstützung rentiert es sich, das kurzerhand abzuschalten.

Xdebug

Dieses nette Modul für PHP sorgt dafür, dass euer PHPStorm nach drücken des Telefonhörers

• alle vorhanden Variablen und Objekte im aktuellen Scope sind sichtbar
• Stack trace der aktuellen Methode (woher kommt der Aufruf, abgehend von index.php)
• in Methodenaufrufe hineinspringen
• einzelne Befehle ablaufen lassen
• beliebigen PHP-Code im Evaluator im aktuellen Scope ausführen

Gerade bei der Arbeit mit Magento hilft es ungemein, zu sehen, welche Objekte gerade mit welchen Eigenschaften (_data[] Array!) verfügbar sind.

Ich habe die Konfiguration von Xdebug etwas angepasst:

xdebug.max_nesting_level = 500
xdebug.var_display_max_children = 512
xdebug.var_display_max_data = 1024
xdebug.var_display_max_depth=5
xdebug.collect_vars=on
xdebug.collect_params=4
xdebug.show_local_vars=on
xdebug.show_exception_trace=off

Damit werden ein paar zu restriktive Einstellungen von Xdebug etwas gelockert und die angezeigten Informationen erweitert. Die Konfiguration gehört in eure jeweilige php.ini Datei - bei mir steht es ganz am Ende. Nutzt ihr, wie ich, MAMP Pro, dann schreibt euren Kram bitte immer HINTER die Zeile ; DONT REMOVE: MAMP PRO phpx.x.xx.ini template compatibility version: x

SSH-Zugänge

Früher hat man nur FTP verwendet. Nachdem aber mittlerweile "Gott und die Welt"™ versucht, Daten abzugreifen, empfiehlt es sich, immer eine gesicherte Verbindung zum Webserver zu nutzen.

Das geht wahlweise und unbequem langsam per FTP over SSL oder aber ordentlich und halbwegs professionell via SSH. Beim Zugang via SSH solltet ihr darauf achten, euch statt mit Passwort mit einer Schlüsseldatei am Server anzumelden.

Dazu richtet ihr euch lokal ein Schlüsselpaar ein. Auf der Kommandozeile geht das mit

 ~/   cd ~/.ssh
 ~/.ssh/   ssh-keygen -t rsa -b 2048
Enter file in which to save the key (/Users/webguys/.ssh/id_rsa):

SSH-KeyGen möchte von euch nun gerne einen Dateinamen für das Schlüsselpaar haben. Ich nutze für jeden Kunden ein eigenes paar und daher sind das bei mir dann gerne mal die Kundennamen: webguys zum Beispiel.

Anschließend könnt ihr ein Passwort für den Schlüssel speichern, das ihr immer dann eingeben müsst, wenn der Schlüssel verwendet werden soll. Wer's mit der Sicherheit nicht so ganz genau nimmt, gibt kein Passwort ein. Nachteil: Ergaunert sich jemand eure private Schlüsseldatei, ist der Zugang zum Server quasi offen.

Habt ihr die Schlüsseldateien erzeugt, gibt es eine webguys und eine webguys.pub Datei im ~/.ssh/ Verzeichnis. Der Inhalt der webguys.pub Datei muss nun auf den Zielserver übertragen werden. Also: SSH mit Passwort zum Zielserver öffnen und dann auf dem Server die Datei ~/.ssh/authorized_keys öffnen. Dort hängt ihr den Inhalt eurer webguys.pub Datei einfach an die letzte Zeile an.

Wer's bequem mag, kann sich dann auf dem eigenen Rechner unter ~/.ssh/config eine eigene Konfiguration anlegen, die festlegt, wie sich SSH mit euren Zielservern verbinden soll und welche Schlüsselpaare dafür zum Einsatz kommen:

host webguys.de
 HostName webguys.de
 IdentityFile "~/.ssh/webguys"
 User riconeitzel

Für jeden Server (respektive jedes Projekt) gibt es also so einen Eintrag.

Wer viel CSS schreibt, freut sich garantiert darüber

Bevor wir zum Finale des Deployments an sich kommen, hier noch ein Hinweis für CSS Fetischisten. Es gibt ja mittlerweile für vieles nette Helferlein. So auch für's CSS schreiben. Dazu muss man noch nicht mal unbedingt das volle Potential dieser Lösungen ausschöpfen.

Die Rede ist von CSS-PreProzessoren. Diese Programme können eine etwas leichter zu schreibende Form von CSS in normales Browser-CSS übersetzen.

Beispiel:

.body {
    background-color:red;
    font:15px/21px 'Open Sans', Helvetica, Arial, sans-serif;
    #page {
    	width:980px;
    	margin:0 auto;
    }
}

Ihr seht hier das Verschachteln von CSS. Ein normaler Browser kann damit nichts anfangen. Nachdem Verwursten dieser Sass-Datei kommt aber schönes CSS dabei heraus:

.body {
    background-color:red;
    font:15px/21px 'Open Sans', Helvetica, Arial, sans-serif;
}

.body #page {
	width:980px;
	margin:0 auto;
}

Zugegeben, dieses Beispiel ist mehr als dürftig. Mit Sass könnt ihr weitaus mehr machen:

1. Variablen
2. Berechnungen
3. Mixins (Mini-Funktionen)
4. Imports

Besonders die Variablen solltet ihr euch noch ansehen. Am Kopf eurer Sass Datei legt ihr eure Standardfarben fürs Projekt fest:

$firmenfarbe: #cc0000;
$auszeichnung: #12345a;

Später im Code verwendet ihr dann einfach nur noch eure Variablen:

h1 {
	color: $firmenfarbe
}

p.auszeichnung {
	background-color: $auszeichnung;
}

Ändert sich nun die Firmenfarbe, ist das für euch ein leichter Handgriff in Zeile 1 und das war's. Genauso können Abstände, Schriften, Größen und vieles mehr in Variablen ausgelagert werden.

Compiling von Geisterhand

Damit das ganze dann auch von alleine in echtes CSS umgewandelt wird, braucht's natürlich den PreProcessor. Sass kann man sich wahlweise auf die Kommandozeile packen (gut für die Git-Berserker) oder sich die Sass-Datei mit nützlichen GUI-Tools, wie z. B. CodeKit kompilieren lassen. Dabei kommt CodeKit mit eigenen Compilern zur Tür hereinspaziert und man spart sich die separat manuelle Installation der ganzen Tools. Sozusagen: All-in-One!

CodeKit ist nicht alleine für das Kompilieren von Sass zu CSS zuständig, sondern beherrscht auch alle anderen gängigen Sprachen wie Less, Stylus, CoffeeScript, Markdown, … und sorgt mit einem Watcher dafür, dass eure Zieldateien immer dann aktualisiert werden, wenn sich die Quelldateien verändern. Und mit etwas Einstellungen hier und etwas Konfiguration da kann CodeKit sogar euren Browser immer neuladen, sobald sich die Zieldateien geändert haben.

Nützlich finde ich, dass sich je Datei bestimmte Einstellungen speichern lassen - bequem über die GUI eben. Dazugehört der Zielpfad der fertig kompilierten Datei, aber auch die zusätzlichen Optionen der Prozessoren. Außerdem bieten beispielsweise die CSS Prozessoren in CodeKit die Möglichkeit, direkt im Anschluss mit Autoprefixer und Bless die CSS-Dateien zusätzlich anzureichen und bugfest für den IE zu machen.

Wer gerne mit Kunden arbeitet

Am Anfang war das Telefon. Und der Entwickler sah, dass es scheiße war. Warum? Zum einen werden wir ständig aus der konzentrierten Arbeit gerissen; Außerdem schreiben wir uns ja doch nur die Hälfte auf, und davon die Hälfte auch noch falsch und am Ende geht sowieso der Zettel verloren.

Besser ist es dann schon, sich die Änderungswünsche per eMail schicken zu lassen. Dann kann man wenigstens mit dem INBOX-ZERO Prinzip arbeiten. Aber bei einer entsprechenden Anzahl an Kunden und vorrangig kontinuierlicher Shoppflege wird auch das unübersichtlich und man weiß am Ende nicht mehr, wem man welchen Aufwand weitergegeben und was welche Priorität hat.

Was hilft, sind Ticketsysteme. Zu Beginn - und das ist sehr empfehlenswert - haben wir unsere Aufgaben in BitBucket Issues organisiert. Man ist nicht wirklich frei in der Konfiguration der Ticketabläufe, aber es hilft einem ungemein, den Überblick zu behalten und mit dem Kunden dokumentiert in Kontakt zu stehen.

Für größere Aufgaben möchte man dann irgendwann auf JIRA wechseln. Früher wollte ich JIRA mit der Kneifzange nicht anfassen, weil es völlig überladen und viel zu komplex zu administrieren ist. Jetzt arbeiten wir seit gut einem Jahr mit JIRA und liebe ich es heiß und innig. Ich kann ohne dieses System eigentlich nicht mehr arbeiten! Und auch unsere Kunden kommen ziemlich gut damit zurecht.

Nachdem ich nun gefühlte 24 Seiten nur über die Tools gesprochen habe, bleibt ja nun schlussendlich noch die Frage:

Wie spiele ich jetzt mein Projekt aus?

Wir sind da recht pragmatisch: Wir nutzen Git auch auf den Servern. Wir sorgen zuerst dafür, dass jede Website des Kunden wenigstens in einem eigenen DocumentRoot liegt: meist sowas ~/html/webguys.de/ und führen dann dort ein git clone … aus. Auf dem Staging-System sollte noch ein git checkout develop erfolgen, damit hier nicht der Master Branch vom Live System sondern der aktuelle Entwicklungstand angezeigt wird.

Damit wir bei der Arbeit mit git auf dem Server nicht ständig mit Zugangsdaten hantieren müssen, erstellen wir auch auf den Kundenserver immer Schlüsselpaare. Den öffentlichen Schlüssel (.pub) des Servers hinterlegen wir bei Bitbucket als Deployment Key.

Diese Deployment Key Zugänge haben keine Berechtigung, Änderungen zu speichern, sondern können lediglich lesend auf das Repo zugreifen. Daher werden diese Zugänge auch nicht im kostenpflichtigen Plan angerechnet.

Wichtig ist nun, dass das .git Verzeichnis nicht über den Browser aufrufbar sein darf. Das sollte also Teil eurer .htaccess Datei im Magento-Verzeichnis, besser noch Teil der vHost-Config von Apache sein (die man bei den meisten Hostern für gewöhnlich aber nicht ändern kann).

Haters gonna hate: Ich weiß, dass man das .git Verzeichnis auch woanders ablegen kann, aber es geht in diesem Artikel explizit um die Schmalspurlösung.

Unsere Standardeinträge für den Anfang der .htaccess sind diese:

RedirectMatch 404 ^/\.git.*$
RedirectMatch 404 ^/Vagrantfile
RedirectMatch 404 ^/puphpet
RedirectMatch 404 ^/var/.*$
RedirectMatch 404 ^/app/.*$
RedirectMatch 404 ^/dev/.*$
RedirectMatch 404 ^/downloader/.*$
RedirectMatch 404 ^/includes/.*$
RedirectMatch 404 ^/lib/.*$
RedirectMatch 404 ^/pkginfo/.*$
RedirectMatch 404 ^/shell/.*$

Ist das Repo erfolgreich ausgecheckt und erlaubt auch keine Zugriffsmöglichkeit auf den .git Ordner, müsst ihr eure local.xml einrichten. Dazu in app/etc/ die am Anfang mal angelegte local.xml.dist nach local.xml kopieren und die Zugangsdaten der Datenbank anpassen.

Anschließend ladet ihr euren SQL-Dump in die Datenbank des Servers. Achtet hierbei auch unbedingt darauf, für die folgenden path Einträge in der core_config_data Tabelle, die Domain zu korrigieren:

web/unsecure/base_url => http://www.webguys.de/
web/secure/base_url => https://www.webguys.de/
web/cookie/cookie_domain => .webguys.de

Anschließend Caches löschen, Indizes aufbauen und fertig!

Nützliche Aliase für die Shell

Die Standardaufgaben wie Reindizieren, Cache löschen und Sessions löschen erledigen bei mir 4 Aliase, die ich in meiner ~/.bash_profile Datei hinterlegt habe:

alias cache='rm -fr ./var/cache/* '
alias magelog='tail -f ./var/log/\*.log'
alias reindex='php_cli -f ./shell/indexer.php reindexall'
alias session='rm -fr ./var/session/\*'

Wichtig: cache und session bitte immer im Magento Root ausführen!

Projekt aktualisieren

Wenn ich jetzt fleißig war und auf dem Test- oder Livesystem Änderungen ausspielen will, logge ich mich per SSH auf der Machine ein und rufe lediglich

git pull
cache

auf und habe sofort das Ergebnis im Browser.