Interview with Mage+ creator

[You may have heard about the Magento fork Mage+.]

 

Lee, just tell us: who are you and what are you doing?

I’m a Magento technical architect, developer and contributor to Magento CE. I specialise in architecting and building large scale and complex installations of Magento – having built enterprise Magento platforms for Warner Music Group both in Europe & USA, and for Rebate Networks, who operate a collection of localised flash-sales websites throughout the world. I’m also the founder of the London Magento Users Group.

I created a fork of Magento CE called Mage+, after the frustrations I’d experienced whilst working with Magento.

Weiterlesen

Dependency Management mit Composer

PHP befindet sich aktuell auf dem Weg, wieder eine angesehene Plattform für professionelle Webanwendungen zu werden. Dieses Ansehen muss sich erst wieder erkauft werden. Noch zu oft leidet die Sprache unter dem Bild, ihre Produkte bestünden nur aus schlecht strukturierten und unprofessionellen Scripts.
In vielen Fällen mag dies richtig sein und man muss zugeben, dass die Verwendung von PHP oft dazu verleitet, einen „Quick & Dirty“-Ansatz der sauberen Lösung vorzuziehen. Als professionelle Software-Entwickler müssen wir aber stets versuchen, mit unserer Arbeit hoch-qualitative und nachhaltige Software zu produzieren.

Ein Anspruch, den sich sicher jeder Entwickler stellen muss, ist, die Produkte seiner Arbeit wiederverwendbar zu halten. In diesem Kontext fallen oft die Begriffe Kapselung und Modularisierung. Um Module wiederverwendbar zu machen, müssen diese eine klare Schnittstelle besitzen und möglichst nur eine Aufgabe – und diese Aufgabe dafür richtig – erledigen. Beim Design modularer Applikationen merkt man schnell, dass bestimmte Module bereits an anderer Stelle entwickelt wurden und eventuell wiederverwendet werden können.
Dieser Artikel beschreibt eine Software, die das Wiederverwenden von PHP-Modulen automatisiert.

Weiterlesen

Zend Framework application.ini Cheat-Sheet

With the release of Zend Framework 1.8 came the long awaited component for bootstrapping a Zend Framework application. Many different bootstrapping-solutions became obsolete with Zend_Application.

 

In the beginning of the framework most developers didn‘t give much thought on bootstrapping. Most of the initialisation work was done directly in index.php, the central starting point of the application. Teams often moved that bootstrapping code to a separate configuration script. The solution worked, but many people wanted a more standardised process for application initialisation.

Weiterlesen

21.12. Agile Developer Skills (ADS)

Last week I had the chance to attend an Agile Developer Skills Workshop in Berlin.

The 3 day workshop is, next to a Scrum Master or PO Certification, a prerequisite for the Certified Scrum Developer, short CSD.

I was very excited about the ADS workshop and I found it an intersting approach to hold a workshop which focusses on developers rather than on the management side of scrum. Especially as in my experience all the other scrum workshops mainly concentrate on the rituals, artefacts and organisation of Scrum, without giving answers on how to develop high quality software.

Weiterlesen

20.12. JSHint – das bessere JSLint?

JSHint ist ein JSLint Fork von Anton Kovalyov. Dieser hat zwar nicht das Standardwerk der JavaScript-Welt „JavaScript – The Good Parts“ geschrieben, dennoch kritisiert er Crockford’s jslint, das in dem Buch ein eigenes Kapitel bekommen hat, pointiert mit:

JSHint is a fork of Douglas Crockford’s JSLint that does not tyrannize your code. It is
designed to detect errors that actually break your code while skipping things that, according
to Crockford, “are known to contribute mistakes in projects”. In other words, JSHint is a
fork of JSLint for the real world. The most important difference is that JSHint is developed
and supported by the JavaScript developer community and not by one very opinionated person.

Weiterlesen

17.12. Zend Framework (1) vs. Symfony2

In this article, I want to highlight some differences between the two PHP frameworks that have been the most popular ones at the time of writing.
Zend Framework (ZF) is currently a quasi-standard in many PHP companies and Symony2’s popularity is constantly increasing. Symfony2 is pretty new now and many developers are thinking about if and when to make the switch from ZF to Symfony2 which is why I think we should spend time looking at the frameworks‘ differences.

I selected three topics that are implemented differently in these frameworks and will describe how each of them does it.

Weiterlesen

16.12. Eine Einführung in Behavior Driven Development

Testdriven Development, also das Schreiben eines oder mehrerer Tests bevor der eigentliche Code entsteht, ist inzwischen ein alter Hut.
Ein großer Nachteil dieses Verfahrens ist, dass im agilen Umfeld die User Stories erst verstanden werden müssen.
Wenn die Story aber falsch verstanden wurde, dann wird auch der Test falsch implementiert.
Knackpunkt ist also immer noch der Abgrund zwischen Analyse und Verdeutlichung der Geschäftsprozesse sowie dem korrekten Erfassen und testen eben jener.
Eine Lösung hierfür soll Behavior Driven Development – kurz BDD – bieten.

Weiterlesen

15.12. Using custom annotations in PHP

When developing enterprise software one should always keep an eye on writing code that is easily maintainable, testable and extendable. Design patterns already propose a way to implement a loosely coupled architecture. With annotations you can take a step forward to make your code look even more expressive, focusing on the primary problem instead of writing a lot of boilerplate code. A single comment line can save you many more lines of code but as it is written in the project’s domain language it will be much more meaningful to the developer. Weiterlesen

10.12. Lösungen für Debugging von Mobile Web Apps

Webkit Web Inspector (Remote)

Dass Firebug in JavaScript programmiert wurde dürfte den meisten bekannt sein. Das gleiche gilt für den WebInspector von WebKit, wie er in Safari oder Google Chrome zu finden ist. Es dürfte also nicht wundern, dass für mobile Geräte mit Weinre von Patrick Mueller bereits 2010 eine Portierung des WebInspectors geschaffen wurde, die über eine JS-Include auf der im Website-Header im Mobilen Browser Remote Debugging Funktionalität zur Verfügung stellt. Somit kann bequem über dem Desktop eine Mobile Webseite debugged werden. Weinre läuft heute als PhoneGap Projekt, ist sozusagen Standard und ist natürlich auf GitHub zu finden.

Das Ganze hat aber leider eben leider Grenzen, was Features wie Breakpoints, Backtraces und Profiling angeht, d.h. genau die nützlichen Features, die normalerweis unter dem “Script”-Tab im Debugger-Panel zu finden sind.

JavaScript Remote Debugging mit WebKit/Chrome

Der nächste konsequente Schritt war also, den Debugger direkt in den Browser Runtime zu heben und eine Remote API anzubieten bzw. eine Verbindung zu dem ohnehin schon existierenden V8 DebuggerProtocol zu schaffen, dass sich allerdings nur auf JavaScript Debugging beschränkt. Das Gesamtpaket nennt sich dann WebKit Remote Debugging Protocol. Währenddessen arbeitete Google auch am ChromeDevToolsProtocol was aber mittlerweile deprecated ist.

Seit Frühjahr diesen Jahres bietet nun WebKit sein Remote Debugging Feature an, welcher praktisch alle bekannten WebInspector Features unterstützt – dazu zählen:

  • JavaScript Console & JS Debugger
  • CSS Debugging & Live Änderungen
  • DOM Manipulation & Debugging – z.B. DOM Knoten auf Änderungen durch JS Events überwachen (DOM Mutation Events)
  • Netzwerk & Timeline – Verfolgung von Netzwerk-Aktivitäten auf der Seite (HTTP, WebSocket, Timings)
  • Resourcen – LocalStorage, ApplicationCache, Cookies

Das Feature kann bereits seit einigen Chrome Versionen getestet werden. Eine aktuelle Chrome Version bevorzugt kann eine Debugger-Instanz mit chrome --remote-debugging-port=9222 gestartet wird.

Sodann ist eine zweite Browserinstanz für den Remote Web Inspector nötig – diese muss jedoch Ihr eigenes Nutzerprofil verwenden, um Probleme zu vermeiden: chrome –user-data-dir=<existierendes Verzeichnis>

Mit Navigation auf http://localhost:9222 im zweiten Browserfenster findet sich nun eine Thumbnail-Übersicht der geöffneten Tabs des zu debuggenden Browsers. Ein weiterer Klick auf das ein Thumbnail lädt nun den Debugger auf die komplette Seite, mit dem wie gewohnt gearbeitet werden kann.

Somit kann zusammenfassend folgendes zur Funktionsweise gesagt werden:

  • Der Web Inspector ist eine Web Application.
  • Der Debugger Server lieftert per HTTP HTML, JavaScript wie CSS aus.
  • Sobald die Application geladen ist wird ein WebSocket zu http://localhost:9222/json geöffnet
  • Der Debugging Port ist für jeden offen, insofern nicht durch Firewall geschützt.
  • Neue Remote Debugging Sessions ersetzen evtl. bereits laufende Debug-Sessions
  • Web Inspector Remote läuft derzeit nur in WebKit Browsern einwandfrei

In iPhone oder Android-WebKits sucht man den Debugger derzeit noch vergebens (about:debug), auch wenn es bereits einige ROMs für Android mit Web Inspector Support gibt. Blackberrys Playbook hingegen besitzt schon entsprechende WebKit Funktionalität.

Der Debugger bietet für den Browser eine vereinfachte, aber noch experimentelle JavaScript API, die z.B. auch durch Chrome Extensions angesprochen werden kann. Nach Google’s Vorstellungen sollen damit auch WebIDEs wie Cloud9 zum bereits integrierten JavaScript Debugger (lib-v8debug) einen vollwertigen “WebInspector” erhalten.

Google/Webkit sind nicht die ersten

Opera demonstrierte bereits 2008 mit DragonFly und Scope einen funktionierenden Remote Debugger, mit dem es möglich ist sich an an einen Opera Mobile oder auch Desktop Opera via TCP-Port ranzuhängen und nicht nur JavaScript zu debuggen. Nachteil an der ganzen Sache: Im Mobile Web dominiert derzeit WebKit.

Firebug Crossfire

Ein ähnliches Projekt existiert seit Anfang diesen Jahres mit Firebug Crossfire, was ähnliche Möglichkeiten bieten soll. Zudem unterstützen die JavaScript Development Tools (JSDT) für Eclipse bereits Crossfire. Derzeit befindet sich das Projekt jedoch noch in der Alpha-Phase, aber darf bereits getestet werden.

Weitere JavaScript Debugging Plugins

Für den, der nodejs debuggen muss, gibt es mit dem NodeInspector eine schicke Lösung, mit der es möglich ist, dies bequem im Browser zu erledigen. NodeInspector ist wie ebenfalls wie Weinre eine Adaption von WebInspector.

Für JavaScript Debugging in der IDE, d.h. bequem Breakpoints in den Quelldateien des geöffneten Projekts setzen, haben wir zum einen die ChromeDevTools als Eclipse-Plugin. Zum anderen hat IntelliJ mit IDEA 10.5 und PHPStorm 3 das V8 DebuggerProtocol bereits implementiert.

Eine weitere einfache JavaScript-Konsole stellt z.B. JSConsole bereit, dass zum Debuggen von iPhone oder Android-Mobile Apps benutzt werden kann.