Webdesign und TYPO3 Blog aus DuisburgCodeception Test einzelnen ausführen (25.2.2017, 13:12 UTC)

Gerade beim der Ebtwicklung von einem Codeception Test ist es wichtig Codeception Tests auch mal einzeln auszuführen.

Codeception Test Single

Codeception Test Single

Tests sind ja immer auch thematisch gruppiert. Dafür sollte man auch immer mit Cest- und nicht mit Cept-Files arbeiten. Da die PHP-Webdevelopern generell auch mehr Möglichkeiten bieten sind die Cest-Files auch in meinen Projekten fest etabliert. Betrachten wir einmal aus meinem Silex Codeception Repository den NavigationCest.

<?php
use Step\Acceptance\Acceptance;
use \Codeception\Scenario;

class navigationCest
{
    ...

    public function checkLinksToAnchor(Acceptance $I, \Page\Startpage $startpage)
    {
        $links = $I->grabMultiple($startpage::$navigationLink, 'href');
        foreach ($links as $link) {
            $I->assertContains('#', $link, 'Link contains #: ' . $link);
        }
    }

    ...


    }
}

Einzelnen Codeception Test ausführen

In den Cest-Szenario werden verschiedenen Tests für die Navigation ausgeführt. Jetzt ist es natürlich möglich, daß nur einer failed. Jetzt möchte man natürlich nicht immer alle anderen ebenfalls ausführen und den Bug schnell fixen.

php vendor/bin/codecept run acceptance navigationCest.php: checkLinksToAnchor

So kann man nur einen bestimmten Codeception Test ausführen.

PHP-Kurs Inhouse-Schulung Codeception

Ab sofort können auch verschiedene PHP-Kurs Inhouse-Schulungen über mich gebucht werden. Hier ist auch Codeception ein Thema.

Automatisierte Tests mit Codeception für effektive Entwicklung

Je eher ein Bug gefunden wird desto günstiger ist es diesen zu beheben. Mit Codeception Acceptance Tests kontrolliert man dabei nicht nur das Backend, sondern die gesamte Applikation als fertiges Produkt. Javascript, CSS, Vendor libraries im Zusammenspiel und auch fertig komprimiert. Navigationen, Tooltips, Formulare, Mouse Overs und auch Lightboxen. Klappt hier alles zuverlässig. Und wer hat schon Lust das auf 3 Browsern mit 2 Auflösungen zu testen. Codeception

Kostenlose Webdevelopment Workshops – Never Code Alone

Seit letzten Jahr richten wir auch alle 3 Monate einen kostenlosen Webdevelopment Workshop aus und versuchen so, die Software-Qualität als Initiative zu fördern. Dabei ist es uns wichtig professionelle Schulungen kostenlos zugänglich zu machen. Neben den Schulungen bieten wir auch die Möglichkeit Gastbeiträge zu veröffentlichen. Diese werden zusätzlich von einem professionellen Redakteur korrigiert und in Absprache mit euch veröffentlicht.

Der TYPO3 Webdesign Blog Codeception Test einzelnen ausführen erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
PHPUG WürzburgEinladung zum März-Treffen / Verlosung PHPStorm-Lizenz (22.2.2017, 18:40 UTC)

Hallo alle zusammen!

Wir treffen uns am 01. März um 19 Uhr in

Mennas Time Out
Frankfurter Straße 1
97082 Würzburg

Parkplätze sind in der näheren Umgebung ausreichend vorhanden, Straßenbahn-Haltestelle: Wörthstraße.

Und dran denken: Es wird eine Lizenz von PHPStorm verlost!

Ich freue mich auf viele Teilnehmer und rege Diskussionen!

Viele Grüße
Jason

Link
CodeMercenaryIm jQuery tablesorter nach deutschem Datum sortieren (20.2.2017, 14:07 UTC)

Den jQuery tablesorter kennen bestimmt viele, ich benutze diesen sehr häufig und gern. Allerdings kann das Ding von Haus aus nicht nach dem deutschem Datumsformat (dd.mm.yyyy [hh:mm]) richtig sortieren.

Hier dazu mein „Plugin“, dass in die entsprechende JavaScript Datei gehört:

$.tablesorter.addParser({
 id: 'germanDate',
 is: function(s) {
 return false;
 },
 format: function(s) {
 var dateMatches = s.match(/([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{2,4}) ([0-9]{1,2}):([0-9]{1,2})/i);
 return dateMatches[3]+dateMatches[2]+dateMatches[1]+dateMatches[4]+dateMatches[5];
 },
 // set type, either numeric or text
 type: 'numeric'
 });

$('#tblApps').tablesorter({
 sortList: [[1,0]],
 headers: {
 0: { sorter: false },
 2: { sorter: 'germanDate' },
 3: { sorter: false }
 }
 });

Damit kann mein Frontend nun auch innerhalb von Tabellen nach Terminen im deutschen Datum richtig sortieren.

Link
PHPUGFFMDie UG als Teil der WebWeek (15.2.2017, 20:20 UTC)

In 4 Wochen treffen wir uns wieder. Am 16. März sind wir wieder bei Check24 zu Gast. Diesmal als Teil der WebWeek

Bis dahin.

Link
Webdesign und TYPO3 Blog aus DuisburgTwig key underscore Unterstrich dash Template attribute-Methode (31.1.2017, 12:59 UTC)

Ein Twig key underscore und gerade die Kombination aus Minus und Underscore können im Twig-Template nicht direkt angesprochen werden. Ist dann noch der Strict Mode gesetzt wird eine Exception „Array to string conversion“ geworfen. Allerdings ist es auch ohne den strict_variables ärgerlich. Man kommt nicht an den Value im Template und dann stimmt die Ausgabe nicht. Die Lösung ist hier der Zugriff über die attribute-Methode.

Twig key underscore „Array to string conversion“ mit attribute-Methode

Twig Key Underscore

Twig Key Underscore

Leider hat man nicht immer Einfluß auf die Datenquelle. Gerade wenn man mit importierten Daten aus einem anderen System arbeitet. Bei einem Silex Projekt mit einem CSV-Import für Elasticsearch ist mir dieser Fehler untergekommen. Hier gibt es jetzt die einfache Lösung:

{{ attribute(object, method) }}

{{ attribute(object, method, arguments) }} {{ attribute(array, item) }}

Weitere Anwendungsfälle sind hier auch dynamische Keys.

Twig-Template isset mit defined

Grundsätzlich kann man in Twig auch die Existenz einer Variablen prüfen, bevor man auf diese zugreift.

{{ attribute(object, method) is defined ? 'Method exists' : 'Method does not exist' }}

Das ist allerdings keine effektive Art der Entwicklung. Hier wird gerade der Template Code stark aufgebläht. Von daher sollte man einfach im Live-Betrieb über die Environment-Variable den Strict-Mode ausschalten. Während der Entwicklung hingegen macht er durchaus Sinn. Aber ein robustes Template schützt nur eine Legacy-Applikation. Das ist der falsche Entwicklungsweg. Einen Wrapper für Keys, die im Template verwendet werden, ist ebenfalls der falsche Weg. Nach Möglichkeit ist hier ganz oben an der Datenquelle und der Ursache der Fix vorzunehmen.

Silex Twig-Templating

Das Micro-Framework Silex eignet sich hervorragend für die schnelle Implementation von Marketing Landingpages. Das Webdesign von PHP-Kurs Inhosue-Schulung basiert darauf. Das entsprechende GitHub-Repo ist hier zu finden.

Der TYPO3 Webdesign Blog Twig key underscore Unterstrich dash Template attribute-Methode erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
Gjero KrsteskiPHP Nuclear Reactor (25.1.2017, 16:59 UTC)

Asynchronous programming is a way to create programs that can execute multiple parallel tasks faster in the same process by executing code while other parts if the programs wait for I/O operations to finish, like database accesses, file accesses, network accesses, etc..

ReactPHP is a low level library similar to JavaScript Node.js that can be used to implement asynchronous programming in PHP, so you can write PHP code that can efficiently access multiple files, databases, or network computers in parallel, making everything faster.

The PHP Nuclear Reactor is library based on PIMF micro-framework that implements the MVC design pattern on top of ReactPHP.

This way you can continue to write PHP MVC components the way you are used to do, and still work well in an asynchronous programming environment based on ReactPHP.

http://gjerokrsteski.github.io/reactphp-pimf/

Link
Webdesign und TYPO3 Blog aus DuisburgMAC localhost kill Prozess Port 8080 8000 (24.1.2017, 13:23 UTC)

Beim Webdevelopment lokal auf dem MAC nutzt man gerne einen Prozess Port 8080 oder 8000. Bekannte Beispiele sind hier z.B. Symfony, TYPO3, WordPress oder auch Silex. Alle Technolgien sind mir sehr vertraut und bei mir im täglichen Einsatz. Hier kann es allerdings sein, daß ich den Prozess nicht richtig beende und den Tab bei oh-my-zsh schon vorher schließe. Dann läuft der Prozess im Hintergrund weiter und blockiert einen Start bei einem anderen Projekt.

Command Line MAC localhost kill Prozess Port 8080

Vorab es macht auf jeden Fall Sinn hier mit oh-my-zsh zu arbeiten, damit man die Autovervollständigung auf der CLI Command Line nutzen kann. Zuerst suchen wir alle Prozesse die auf Port 8080 laufen.

MAC finde alle Prozesse auf Port 8080

lsof -i tcp:8080

Jetzt wird der entsprechende Prozess gelistet. Hier wird u.a. eine UID. Dann einfach ein kill command ausführen.

kill -9 <PID>

MAC Kill Prozess 8080 localhost

MAC Kill Prozess 8080 localhost

 

Der TYPO3 Webdesign Blog MAC localhost kill Prozess Port 8080 8000 erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
Gjero KrsteskiLean Testing und eine Beobachtung der letzten Jahre – ein Gastbeitrag von Nils Langner (17.1.2017, 14:48 UTC)

Über den Autor: Einige von euch kennen Nils vielleicht aus seinem Blog phphatesme, die anderen von Konferenzen oder ähnlichem. Vor einem Jahr hat er sich aufgemacht das “Lean Testing”-Vorgehen unter die Leute zu bringen. Das liegt hauptsächlich daran, dass diese Testing-Methodik wunderbar zum Internet passt, aber vielleicht auch, weil er mit Leankoala die erste “Software as a Service”-Lösung in diesem Bereich auf den Markt gebracht hat. Ach ja, er schreibt Texte über sich gerne in der dritten Person.

Was haben wir nicht alles die letzten Jahre ausprobiert?! Seit über zehn Jahren habe ich mich jetzt schon in das Thema des Qualitätsmanagements gestürzt. Die meiste Zeit davon im Web. Ausprobiert habe ich fast alles und vieles lieben gelernt. Begonnen haben wir oft mit einfachen Testplänen, die wir dann genutzt haben, um manuell Webseiten durchzutesten, wenn einem das zu blöd wurde, hat man Selenium angeworfen und echte Browser automatisiert ferngesteuert. Danach wurde man etwas mutiger und hat sich Behaviour Driven Development angeschaut. Auch eine feine Sache. Die Testabdeckungen wurden immer ausgereifter und umfänglicher, was leider häufig dazu geführt hat, dass die Wartbarkeit gelitten hat. Alles in allem war man aber glücklich, da trotz des manchmal hohen Aufwandes man trotzdem schneller mit der Testen von Funktionen war, als die Entwickler neue Features rausgebracht haben.

2012, nachdem wir fast alles ausprobiert hatten, was der Markt so zu bieten hatte, wollten wir etwas Neues ausprobieren. Also schrieben wir unser eigenes kleines Werkzeug, um uns zu helfen Tests zu schreiben und durchzuführen. Wir haben es LiveTest2 genannt und es sollte dabei behilflich sein einfache Eigenschaften von Webseiten abzutesten. So konnte man zum Beispiel in einer Konfigurationsdatei sagen, dass auf jeder hinterlegten Seite der String Impressum vorkommen soll. So wollten wir sicherstellen, dass der Footer überall gerendert wird. Ziel war es möglichst einfach simple Smoke-Tests aufzustellen. Ein Test wie dieser muss schnell durchgeführt sein, um zu entscheiden, ob es sich lohnt die teuren, lange dauernden Tests auszuführen. Zu dieser Zeit sind wir zweigleisig gefahren. Einfache Tests als erste Testphase und danach die Tests, die wir mit unserem QA-Stolz gebaut hatten.

Nach einer gewissen Zeit kam dann die angekündigte Beobachtung. Jedes Mal wenn die einfachen günstigen Tests angeschlagen haben, haben uns auch die teuren alarmiert. Und wenn die einfachen Tests gesagt haben, dass alles grün ist, so haben sich die teuren angeschlossen. Daher haben wir erstmal die Theorie aufgestellt, dass LiveTest2 genauso gut ist wie andere Testing-Tools, nur mit weniger initialen Aufwand. Betrachtet man die beiden Herangehensweisen genauer, fällt einem ein großer Unterschied auf. Bei Unit-Tests, BDD-Tests und Selenium-Tests versucht man häufig jeden möglichen Fehlerfall auszutesten. Jeder potentiellen Ursache von Fehlern sollte möglichst ein Test zugeordnet sein. Bei unserer neuen Methodik ging es nicht mehr um Ursachen, sondern um Symptome.

Nehmen wir wieder das Beispiel des Footers. Sobald das Wort Impressum nicht mehr vorhanden ist, wissen wir, dass wir funktionale Probleme haben. Welche Ursache dies hat, können wir anhand des Testes nicht sagen. Der Erfahrung nach ist den Entwicklern dies aber trotzdem sehr schnell klar.

2014 kamen wir dann mit dem Begriff Lean Testing auf, den ich für diese Art des Testens prägen wollte. Dabei geht es darum sich auf Symptome zu konzentrieren und nicht mehr auf Ursachen.

Wenn man eine Weile im Internet unterwegs ist, dann ist einem klar, dass die Anzahl der Symptome, die klassischerweise auftauchen, sehr beschränkt ist. So kommt man mit einem einfachen “Http-Status-Code 200”-Test in der Integrations- oder Stage-Umgebung schon sehr weit. Fügt man dann noch die Möglichkeit hinzu nach Texten zu suchen ist man fast durch. Weil man das Web kennt garniert man das ganze noch mit XPath und Css-Selektoren. Dazu hatten wir 2015 das Open-Source Tool Smoke released, was all diese Tests beinhaltet.

2016 haben wir begonnen diese Methodik in eine “Software as a Service”-Lösung zu gießen und es ist mit dem Anfang dieses Jahre die erste Produktivversion unter www.leankoala.com erschienen.

Link
Gjero KrsteskiLean Testing und eine Beobachtung der letzten Jahre – ein Gastbeitrag von Nils Langner (17.1.2017, 14:48 UTC)

Über den Autor: Einige von euch kennen Nils vielleicht aus seinem Blog phphatesme, die anderen von Konferenzen oder ähnlichem. Vor einem Jahr hat er sich aufgemacht das “Lean Testing”-Vorgehen unter die Leute zu bringen. Das liegt hauptsächlich daran, dass diese Testing-Methodik wunderbar zum Internet passt, aber vielleicht auch, weil er mit Leankoala die erste “Software as a Service”-Lösung in diesem Bereich auf den Markt gebracht hat. Ach ja, er schreibt Texte über sich gerne in der dritten Person.

Was haben wir nicht alles die letzten Jahre ausprobiert?! Seit über zehn Jahren habe ich mich jetzt schon in das Thema des Qualitätsmanagements gestürzt. Die meiste Zeit davon im Web. Ausprobiert habe ich fast alles und vieles lieben gelernt. Begonnen haben wir oft mit einfachen Testplänen, die wir dann genutzt haben, um manuell Webseiten durchzutesten, wenn einem das zu blöd wurde, hat man Selenium angeworfen und echte Browser automatisiert ferngesteuert. Danach wurde man etwas mutiger und hat sich Behaviour Driven Development angeschaut. Auch eine feine Sache. Die Testabdeckungen wurden immer ausgereifter und umfänglicher, was leider häufig dazu geführt hat, dass die Wartbarkeit gelitten hat. Alles in allem war man aber glücklich, da trotz des manchmal hohen Aufwandes man trotzdem schneller mit der Testen von Funktionen war, als die Entwickler neue Features rausgebracht haben.

2012, nachdem wir fast alles ausprobiert hatten, was der Markt so zu bieten hatte, wollten wir etwas Neues ausprobieren. Also schrieben wir unser eigenes kleines Werkzeug, um uns zu helfen Tests zu schreiben und durchzuführen. Wir haben es LiveTest2 genannt und es sollte dabei behilflich sein einfache Eigenschaften von Webseiten abzutesten. So konnte man zum Beispiel in einer Konfigurationsdatei sagen, dass auf jeder hinterlegten Seite der String Impressum vorkommen soll. So wollten wir sicherstellen, dass der Footer überall gerendert wird. Ziel war es möglichst einfach simple Smoke-Tests aufzustellen. Ein Test wie dieser muss schnell durchgeführt sein, um zu entscheiden, ob es sich lohnt die teuren, lange dauernden Tests auszuführen. Zu dieser Zeit sind wir zweigleisig gefahren. Einfache Tests als erste Testphase und danach die Tests, die wir mit unserem QA-Stolz gebaut hatten.

Nach einer gewissen Zeit kam dann die angekündigte Beobachtung. Jedes Mal wenn die einfachen günstigen Tests angeschlagen haben, haben uns auch die teuren alarmiert. Und wenn die einfachen Tests gesagt haben, dass alles grün ist, so haben sich die teuren angeschlossen. Daher haben wir erstmal die Theorie aufgestellt, dass LiveTest2 genauso gut ist wie andere Testing-Tools, nur mit weniger initialen Aufwand. Betrachtet man die beiden Herangehensweisen genauer, fällt einem ein großer Unterschied auf. Bei Unit-Tests, BDD-Tests und Selenium-Tests versucht man häufig jeden möglichen Fehlerfall auszutesten. Jeder potentiellen Ursache von Fehlern sollte möglichst ein Test zugeordnet sein. Bei unserer neuen Methodik ging es nicht mehr um Ursachen, sondern um Symptome.

Nehmen wir wieder das Beispiel des Footers. Sobald das Wort Impressum nicht mehr vorhanden ist, wissen wir, dass wir funktionale Probleme haben. Welche Ursache dies hat, können wir anhand des Testes nicht sagen. Der Erfahrung nach ist den Entwicklern dies aber trotzdem sehr schnell klar.

2014 kamen wir dann mit dem Begriff Lean Testing auf, den ich für diese Art des Testens prägen wollte. Dabei geht es darum sich auf Symptome zu konzentrieren und nicht mehr auf Ursachen.

Wenn man eine Weile im Internet unterwegs ist, dann ist einem klar, dass die Anzahl der Symptome, die klassischerweise auftauchen, sehr beschränkt ist. So kommt man mit einem einfachen “Http-Status-Code 200”-Test in der Integrations- oder Stage-Umgebung schon sehr weit. Fügt man dann noch die Möglichkeit hinzu nach Texten zu suchen ist man fast durch. Weil man das Web kennt garniert man das ganze noch mit XPath und Css-Selektoren. Dazu hatten wir 2015 das Open-Source Tool Smoke released, was all diese Tests beinhaltet.

2016 haben wir begonnen diese Methodik in eine “Software as a Service”-Lösung zu gießen und es ist mit dem Anfang dieses Jahre die erste Produktivversion unter www.leankoala.com erschienen.

Link
Webdesign und TYPO3 Blog aus DuisburgCaps Lock Shift Taste Escape statt Delete Key macOS Sierra (3.1.2017, 13:50 UTC)

Für effektives Arbeiten an Keyboards ist es wichtig die Shift Taste Escape (Caps Lock) zu belegen. So hat man die größte Taste auf der Baseline mit einer wichtigen Funktion belegt. Da ich selber recht viel mit VIM arbeite und die Escape-Taste auch sonst recht häufig brauche habe ich diese auf die Caps Lock gelegt. Einige Webdeveloper nutzen hier allerdings auch die Delete-Taste. Das ist vielleicht auch ein sehr guter Usecase. Da schlägt bei mir allerdings die Macht der Gewohnheit zu.

Die Caps Lock oder Shift Taste mit Escape statt Delete Key in macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Leider gibt es eine Änderung bei der neuen Version von Apples Betriebssystem macOS Sierra gegenüber vorherigen Versionen. Hier hatte ich bereits über das Setting mit der Software Seil gebloggt. Das fällt ab sofort flach und geht dafür allerdings gefühlt auch ein wenig einfacher. Man ruft einfach folgendes auf

Systemeinstellungen
Tastatur
Sondertasten
Shift Taste
Escape auswählen

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Leider muß man das sowohl für die normale Tastatur, als auch für die Magic Keypad Settings einrichten. Das ist zwar recht seltsam, aber nicht die Hölle

Der TYPO3 Webdesign Blog Caps Lock Shift Taste Escape statt Delete Key macOS Sierra erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
LinksRSS 0.92   RDF 1.
RSS 2.0 Feed   RDF 1.
100% Planet PHP   PHP5 powered
PEAR powered  
Code wird von Planet-PHP zur Verfügung gestellt. Vielen Dank.