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

In 4 Wochen treffen wir uns wieder. Am 16. Februar sind wir wieder be iCheck24 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
Webdesign und TYPO3 Blog aus DuisburgGulp run sequence – Gulp Task sequentiell abarbeiten (24.11.2016, 11:41 UTC)

Frontend-Webdevelopment mit Gulp Task sequentiell abarbeiten ist bei modernen Webdesign nötig. Dabei sind Gulp-Tasks ein wichtiger Bestandteil dieser tollen neuen Technologie. Gulp ist eine NodeJS Applikation, die natürlich auch in der Prozessverarbeitung ihre großen Vorzüge bezüglich der Performance hat. Asynchrone Prozessverarbeitung. Damit tun sich traditionelle Webdeveloper, gerade aus der PHP-Welt recht schwer. Hier findet man sich dann schnell in der sogenannten Callback-Hell wieder. An diesem Punkt sollte man sich natürlich fragen, ob man die richtige Technologie für das zu lösende Problem gewählt hat.

Gulp Task sequentiell ausführen – TYPO3 Gulp

In einer TYPO3 Migration von 6.2 auf 7.6 bin ich vor kurzem auf eine Herausforderung mit Gulp gestoßen. Hier war es wichtig die CSS-Files und JS-Files erst zu minimieren und dann an die richtige Stelle zu meiner Design Extension zu exportieren. So konnte unabhängig im Front- und Backend im Team gearbeitet werden.

const gulp = require('gulp');
const debug = require('gulp-debug');
const gulpLoadPlugins = require('gulp-load-plugins');
const wiredep = require('wiredep').stream;
const del = require('del');
const runSequence = require('run-sequence');

const $ = gulpLoadPlugins();

var stylesTarget = 'Resources/Public/Styles/';
var scriptsTarget = 'Resources/Public/Scripts';
var imagesTarget = 'Resources/Public/Images';
var fontsTarget = 'Resources/Public/Fonts';

gulp.task('clean-styles', del.bind(null, [stylesTarget]));
gulp.task('styles', () => {
  return gulp.src('../../rogoit-design/app/Styles/*.scss')
    .pipe(debug())
    .pipe($.plumber())
    .pipe($.sourcemaps.init())
    .pipe($.sass.sync({
      outputStyle: 'expanded',
      precision: 10,
      includePaths: ['.']
    }).on('error', $.sass.logError))
    .pipe($.autoprefixer({browsers: ['> 1%', 'last 2 versions', 'Firefox ESR']}))
    .pipe($.sourcemaps.write())
    .pipe(gulp.dest(stylesTarget));
});

gulp.task('clean-scripts', del.bind(null, [scriptsTarget]));
gulp.task('scripts', () => { // ['lint'],
  return gulp.src('../../rogoit-design/app/Scripts/**/*.js')
    .pipe(debug())
    .pipe($.plumber())
    .pipe($.babel())
    .pipe(gulp.dest(scriptsTarget));
});

gulp.task('vendor-scripts', () => { // ['lint'],
    return gulp.src(['../../rogoit-design/dist/Scripts/vendor/**/*', '../../rogoit-design/dist/Scripts/vendor.js'])
        .pipe(debug())
        .pipe(gulp.dest('Resources/Public/Scripts/vendor'));
});

gulp.task('clean-images', del.bind(null, [imagesTarget]));
gulp.task('images', () => {
  return gulp.src('../../rogoit-design/app/Images/**/*')
    .pipe(debug())
    .pipe($.imagemin({
      progressive: true,
      interlaced: true,
      svgoPlugins: [{cleanupIDs: false}]
    }))
    .pipe(gulp.dest(imagesTarget));
});

gulp.task('clean-fonts', del.bind(null, [fontsTarget]));
gulp.task('fonts', () => {
  return gulp.src(require('main-bower-files')('**/*.{eot,svg,ttf,woff,woff2}', function (err) {})
    .concat('../../rogoit-design/app/Fonts/**/*'))
    .pipe(debug())
    .pipe(gulp.dest(fontsTarget));
});


function lint(files, options) {
  return gulp.src(files)
    .pipe($.eslint(options))
    .pipe($.eslint.format());
}

gulp.task('lint', () => {
  return lint('../../rogoit-design/Scripts/**/*.js', {
    fix: true
  })
  .pipe(gulp.dest(scriptsTarget));
});

gulp.task('compress', ['styles', 'scripts'], () => {
  return gulp.src(['Resources/Public/**/*'])
    .pipe(debug())
    .pipe($.if('*.js', $.uglify()))
    .pipe($.if('*.css', $.cssnano({safe: true, autoprefixer: false})))
    .pipe(gulp.dest('Resources/Public'));
});

gulp.task('default', function(done) {
    runSequence('clean-styles', 'clean-scripts', 'clean-images', 'clean-fonts','styles', 'scripts', 'vendor-scripts', 'fonts', 'images', 'compress', function() {
        console.log('All tasks finished');
        done();
    });
});

Gulp Task sequentiell

Artikel gek: Lesen Sie den Rest hier (weitere 1424 Bytes)

Link
PHPUG WürzburgEinladung zum November-Treffen / Verlosung PHPStorm-Lizenz (22.11.2016, 14:14 UTC)

Hallo alle zusammen!

Wir treffen uns am 29. November 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
Coding – byteludeWie kann ich einen unendlich lang gültigen Facebook Page Accesstoken erzeugen? (7.11.2016, 19:00 UTC)

Facebook Access Tokens sind eine ziemlich fiese Sache, wenn man Server only Anwendungen bauen möchte – also keine wirkliche Chance hat, den User einen Token besorgen zu lassen. Zusätzlich haben die “normalen” Access Tokens bei Facebook das Problem, dass sie spätestens nach 60 Tagen ungültig sind. Es gibt aber derzeit noch eine Möglichkeit, an unendlich gültige Access Tokens zu kommen. Mit diesen Tokens könnt ihr beliebig auf euer Seite posten, Statistiken abfragen usw. – und an diesen Token kommt ihr so:

  1. Zunächst müsst ihr Admin der gewünschten Fan Page sein
  2. erstellt eine Facebook App – natürlich mit dem gleichen User, der auch Admin der Seite ist.
  3. kopiert in den Einstellungen der App die App-ID sowie das App Secret
  4. öffnet den Facebook Graph API Explorer
  5. oben rechts ist ein Dropdown, in dem ihr die eben erstellte App auswählt (anfänglich steht da “Graph API Explorer” drin)
  6. nun klickt ihr auf das “Get Token”-Dropdown und wählt da “Get User Access Token” – dabei ist es wichtig, dass ihr in der nun erscheinenden Übersicht das Häkchen bei “manage_pages” setzt
  7. kopiert nun den kurzfristigen Token aus dem Textfeld in der Mitte und ruft folgende URL auf:
    https://graph.facebook.com/oauth/access_token?client_id=[APP_ID]&client_secret=[APP_SECRET]&grant_type=fb_exchange_token&fb_exchange_token=[TOKEN]
  8. kopiert euch den nun angezeigten langfristigen Token (LONG_LIVING_TOKEN, 60 Tage gültig)
  9. ruft nun die folgende URL auf:

    https://graph.facebook.com/me/accounts?access_token=[LONG_LIVING_TOKEN]

  10. in dem nun erscheinenden JSON seht ihr alle von euch verwalteten Seiten sowie deren unendlich lang gültigen Tokens für die verwendete App

Zur Überprüfung ruft ihr einfach das Access Token Debug Tool auf: 

https://developers.facebook.com/tools/debug/accesstoken

Hier könnt ihr den Token eintragen und bekommt dann Informationen darüber – und eben auch die Gültigkeit.

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.