Stephan Schmidt. Head of Web Sales Development bei der 1&1 Internet AG. PHP seit Autor von PHP Design Patterns, Co-Autor weiterer PHP Bücher

Transkript

1 PHP mit Paul Bocuse PHP World Kongress 2010

2 Stephan Schmidt Head of Web Sales Development bei der 1&1 Internet AG PHP seit 1999 Autor von PHP Design Patterns, Co-Autor weiterer PHP Bücher Konferenzen seit 2001 Open-Source-Aktivist

3 Holger Head of Sales Processes Access bei der 1&1 Internet AG PHP seit 2000 Gast-Dozent an der Berufs- Akademie Mosbach Autor für die Zeitschrift T3N Clean Code Aktivist

4 Paul Bocuse Head of Nouvelle Cuisine Michelin Sterne seit 1965 Autor von Die neue Küche, Französisch Kochen mit dem Meister und weiterer Bücher Besitzer von fünf Restaurants Koch des Jahrhunderts Gewürz-Aktivist

5 Kochen und PHP WTF?

6 Das mag ich...

7 Das kuckt meine Frau...

8 Nochmal: Kochen und PHP WTF?

9

10

11

12 Kochen und PHP FTW!

13 Beispiele Für PHP im Unternehmenseinsatz

14 Viele Entwickler Über Entwickler sind bei der 1&1 Internet AG beschäftigt. Nicht nur PHP-Entwickler. Montabaur Entwickler sind in verschiedenen organisatorischen Teams. Karlsruhe München Entwickler sind über verschiedene Standorte verteilt. Bukarest

15 Hohe Komplexität

16 Hohe Komplexität

17 Hohe Komplexität

18 Hohe Zugriffszahlen Visits / Tag

19 Hohe Zugriffszahlen Page Impressions / Tag

20 Viele Änderungen 3-5 Onlinegänge / Woche

21 Viele Änderungen Neue Produkte und Preisänderungen

22 Viele Änderungen Einbindung von neuen Services

23 Viele Änderungen Änderungen des Seitenablaufs

24 Viele Änderungen Kompletter Umbau des Portfolios

25 Große Applikationen

26 Große Applikationen

27 Anforderungen an unternehmenskritische Software

28 Unternehmen Ein Unternehmen ist ein spezieller Betriebstyp in marktwirtschaftlichen Systemen. Konstitutive Merkmale des Unternehmens sind nach Erich Gutenberg das erwerbswirtschaftliche Prinzip (Streben nach Gewinnmaximierung), das Prinzip des Privateigentums und das Autonomieprinzip (Selbstbestimmung des Wirtschaftsplans). Wikipedia

29 Performance

30 Skalierbarkeit

31 Kosten

32 Wartbarkeit

33 Sicherheit & Verfügbarkeit

34 Erweiterbarkeit

35 Die Anforderungen im Überblick

36 Empfehlung des Tages 1. Der Code Wie finden Sie die richtigen Zutaten für Ihre Applikation? 2. Das Team Wie schaffen Sie es, dass viele Köche nicht den Brei verderben? 3. Die Methoden und Tools Wie rühren Sie die einzelnen Zutaten zusammen und welche Küchengeräte sollten Sie dazu einsetzen?

37 Code Das Salz in einer PHP- Applikation.

38 Halten Sie Ihren Code sauber

39 Sauberer Code Sauberer Code kann von anderen Entwicklern gelesen werden. Er verfügt über Unit- und Akzeptanz-Tests. Er enthält bedeutungsvolle Namen. Erst stellt zur Lösung einer Aufgabe nicht mehrere, sondern eine Lösung zur Verfügung. Er enthält minimale Abhängigkeiten, die ausdrücklich definiert sind, und stellt ein klares und minimales API zur Verfügung Dave Thomas

40 Verwende Namen die ihre Absicht aufdecken Namen von Variablen, Funktionen oder Klassen, sollten folgende Fragen beantworten: Warum existiert die Variable (Funktion oder Klasse)? Was macht sie? Wie wird sie verwendet? $d = 1; // elapsed time in days $elapsedtimeindays = 1;

41 Benennung Verwende aussprechbare Namen GMDB und XGMDB (extended Generic Message Driven Bean) Verwende ein Wort pro Konzept (z.b. fetch, retrieve oder get) fetchmeals, retrieveingredients, getchefs Vermeide "Nerd Names" in Klassennamen...Helper,...Manager oder...util

42 Benennung

43 Benennung

44 Benennung

45 Kommentare Gute Kommentare Schlechte Redundante Kommentare Informative Kommentare Postionsmarkierungen PHPDocs in öffentlichen APIs Auskommentierter Code Kommentare sind keine Ausrede für schlechten Code.

46 Coding Standards Legen fest, wie lang eine Zeile sein darf, wie eingerückt wird, wo geklammert wird, wo Leerzeichen stehen, wann Großbuchstaben oder Kleinbuchstaben verwendet werden, wie eine Funktionsdefinition aussehen soll, wie eine Klassendefinition aussehen soll, wie eine Methodendefinition aussehen soll, wie und wo Includes verwendet werden sollen, und, und, und, Haben religiöse Sprengkraft Sorgen dafür, dass der Code für alle Entwickler lesbar bleibt Entwickler haben dadurch Zeit, sich auf das Wesentliche zu fokussieren

47 DRY - Don t Repeat Yourself Every piece of knowlege must have a single, unambiguous, authoritative representation within a system Andrew Hunt and Dave Thomas

48 DRY - Don t Repeat Yourself Nichts ist einfacher als Copy & Paste Nummer Eins der Gestanksparade in Refactoring von Martin Fowler Jede Doppelung von Code leistet Inkonsistenzen und Fehlern Vorschub

49 Fehlerhandling Verwende Exceptions Reichere deine Exceptions mit sinnvollen Informationen an Exceptions sind für den Empfänger wichtig, nicht für den Sender Verwende Exceptions nicht als billige Alternative für goto Gib niemals null zurück

50 Die Pfadfinder-Regel Leave the campground cleaner than you found it Robert C. Martin

51 Die Pfadfinder-Regel Don t live with Broken Windows Fixe schlechte Designs, falsche Entscheidungen und schlechten Code sobald du ihn siehst Es muss nichts großes sein Ändere den Namen einer Variable in einen besseren Breche eine Funktion auf, die zu groß ist Eliminiere ein kleine Duplizierung Software muss dauerhaft sauber gehalten werden

52 Die Pfandfinder-Regel

53 Schmutziger Code führt zu unsauberem Design. Lass auch bei Detail-Fragen die gleiche Sorgfalt walten wie bei großen Design-Entscheidungen.

54 You Ain t Gonna Need It (YAGNI)

55 You Ain t Gonna Need It (YAGNI) Always implement things when you actually need them, never when you just foresee that you need them Ronald E Jeffries

56 You Ain t Gonna Need It (YAGNI) Anforderungen sind in der Software-Entwicklung notorisch ungenau oder wechselnd Ungenaue Anforderungen werden oft durch möglichst flexible und funktionsfähige Software kompensiert Es werden Features entwickelt die keine Anwendung finden Dinge die niemand braucht, haben keinen Wert.

57 Do the simplest thing that could possibly work. YAGNI kann als Ergänzung des XP-Prinzips "Do the simplest thing that could possibly work." verstanden werden Wann ist ein Design am einfachsten? Es verkörpert die Absicht des Entwicklers und besteht alle Tests. Es enthält kein Duplizierungen. Es enthält das Minimum an Klassen und Methoden

58 Emergenz Emergenz ist die spontane Herausbildung von komplexen Systemen und Strukturen durch eine Vielzahl von relativ einfachen Interaktionen. Wikipedia

59 Saubere Software durch emergentes Design Alle Tests bestehen Software muss in erster Linie den gewollten Zweck erfüllen. Software, die nicht testbar ist, kann nicht verifiziert werden. Klassen die dem Single Responsibility Prinzip folgen sind leichter zu testen. Je mehr Tests wir schreiben, desto mehr bemühen wir uns Code zu schreiben, der einfacher zu testen ist.

60 Saubere Software durch emergentes Design Alle Tests bestehen Eine starke Kopplung erschwert das Schreiben von Tests Je mehr Tests wir schreiben, desto mehr bemühen wir uns, die Kopplung zu minimieren

61 Saubere Software durch emergentes Design Refactoring nach dem Bestehen eines Tests Duplizierten Code eliminieren Ausdrucksstärke des Codes verbessern Anzahl der Klassen und Methoden minimieren Tests sichern das bisherige Ergebnis ab

62 Vorsicht: Perfekt ist der Feind von "Gut genug" Entwickler tendieren dazu Lösungen danach zu analysieren wie elegant und optimal sie für die Problemstellung sind. Software Entwicklung ist kein Schönheitswettbewerb Der Code ist klar, ausdrucksstark, gut dokumentiert und getestet. Geht es noch besser? Klar. Aber es er ist gut genug. Verschwende keine Zeit auf der Suche nach dem perfekten Design

63 Mit kleinen Schritten zum großen Ziel. Mach es nicht perfekt, mach es gut genug. Je länger Entscheidungen aufgeschoben werden, desto mehr Wissen hat man darüber

64 Design Patterns

65 Konkretes Problem Ich möchte Debug-Meldungen auf verschiedene Arten verarbeiten und diese auswechseln können, ohne den Code der MicroWave Klasse anpassen zu müssen. Paul

66 Abstraktes Problem Ich möchte eine Aufgabe mit verschiedenen Algorithmen lösen können. Jede der Lösungen soll gekapselt sein und nichts von den anderen wissen. Die einzelnen Lösungen sollen gegeneinander austauschbar sein, ohne den nutzenden Client anzupassen. Abstract Paul

67 Konkret vs Abstrakt Abstrakt Konkret Aufgabe Algorithmen Verarbeiten von Debug- Meldungen Ausgeben per print(), Schreiben eines Logfiles Client Die Klasse MicroWave

68 Konkret vs Abstrakt Abstrakt Konkret Aufgabe Algorithmen Persistieren von Gästebucheinträgen Speichern in Datenbank, Speichern in XML-Datei Client Die Klasse Guestbook

69 Einsatz von Interfaces class MicroWave {... Eigenschaften der Klasse... public function construct(debugger $debugger) { $this->debugger = $debugger; } }... weitere Methoden der Klasse... interface Debugger { public function debug($message); } class DebuggerEcho implements Debugger { public function debug($message) { echo $message. "\n"; } }

70 Einsatz von Interfaces Debugger einsetzen $debugger = new DebuggerEcho(); $microwave = new MicroWave($debugger); Debugger austauschen class DebuggerLog implements Debugger { public function debug($message) { error_log("{$message}\n", 3, './MicroWave.log'); } } $debugger = new DebuggerLog(); $microwave = new MicroWave($debugger);

71 Pauls erstes Design Pattern Strategy-Pattern

72 Design Patterns Lösungsmuster für häufig auftretende Entwurfsaufgaben in der Software- Entwicklung Keine Code-Bibliothek Organisiert in Pattern-Katalogen (z.b. Gang-of-Four Buch) Verschiedene Kategorien: Erzeugungsmuster, Strukturmuster, Verhaltensmuster, Enterprise-Patterns Verhindern, dass Ihr Code so aussieht.

73 Design Patterns Lösungsmuster für häufig auftretende Entwurfsaufgaben in der Software- Entwicklung Keine Code-Bibliothek Organisiert in Pattern-Katalogen (z.b. Gang-of-Four Buch) Verschiedene Kategorien: Erzeugungsmuster, Strukturmuster, Verhaltensmuster, Enterprise-Patterns Verhindern, dass Ihr Code so aussieht.

74 Erzeugungsmuster Erzeugungsmuster werden verwendet, um Objekte zu konstruieren. Zu den Erzeugungsmustern gehören unter anderem Singleton-Pattern Factory-Method-Pattern Prototype-Pattern Abstract-Factory-Pattern

75 Factory-Method-Pattern Definiert eine Schnittstelle zur Erzeugung von Objekten Verlagert die eigentliche Instanziierung in Unterklassen Lässt Unterklassen entscheiden, welche konkrete Implementierung verwendet wird

76 Factory-Method-Pattern abstract class AbstractManufacturer { } protected $name; public function construct($name) { $this->name = $name; } public function selloven() { $oven = $this->manufactureoven(); // weitere Operationen möglich return $oven; } public abstract function manufactureoven();

77 Factory-Method-Pattern class MicroWaveOvenManufacturer extends AbstractManufacturer { } public function manufactureoven() { return new MicroWave($this->name); } $mwmanufacturer = new MicroWaveOvenManufacturer('Bosch'); $microwave = $mwmanufacturer->selloven();

78 Factory-Method-Pattern Das Factory-Method-Pattern definiert eine Schnittstelle zur Erzeugung von Objekten. Es verlagert aber die eigentliche Instanziierung in Unterklassen; es lässt die Unterklassen entscheiden, welche konkreten Implementierungen verwendet werden.

79 Factory-Method-Pattern

80 Prototype-Pattern Das Prototype-Pattern erzeugt Objekte durch das Kopieren eines prototypischen Exemplars Es ermöglicht das Hinzufügen neuer "Klassen" zur Laufzeit ohne Programmierung Es hält die Anzahl der benötigten Klassen klein

81 Prototype-Pattern class SandwichMaker { } protected $prototypes = array(); public function addrecipe($recipe, Sandwich $prototype) { $this->prototypes[$recipe] = $prototype; } public function makesandwich($recipe) { if (!isset($this->prototypes[$recipe])) { throw new UnknownRecipeException( 'No prototype for sandwich '. $recipe. ' registered'); } return clone $this->prototypes[$recipe]; }

82 Prototype-Pattern interface Sandwich {... } class Melt implements Sandwich {... } class Reuben implements Sandwich {... } $swmaker = new SandwichMaker(); $blt = new Reuben(); $blt->addingredient('bacon'); $blt->addingredient('lettuce'); $blt->addingredient('tomato'); $swmaker->addrecipe('tomato', $blt); $cheese = new Melt(); $cheese->addingredient('blue Cheese'); $cheese->addingredient('swiss Cheese'); $swmaker->addrecipe('cheese', $cheese);

83 Prototype-Pattern Das Prototyp-Muster bestimmt die Arten der zu erzeugenden Objekte durch die Verwendung eines prototypischen Exemplars, das zur Erzeugung neuer Instanzen kopiert wird.

84 Prototype-Pattern

85 Strukturmuster Strukturmuster befassen sich mit der Komposition von Objekten Zu den Strukturmustern gehören unter anderem Composite-Pattern Proxy-Pattern Adapter-Pattern Facade-Pattern

86 Composite-Pattern Lässt mehrere Instanzen eines Typs nach außen wie eine Instanz aussehen Implementieren einer neuen Klasse, die die einzelnen Instanzen aufnimmt Muss die selbe Schnittstelle implementieren wie die entsprechenden Instanzen

87 Composite-Pattern interface Debugger { public function debug($message); } // Implementierungen class DebuggerLog implements Debugger { public function debug($message) { error_log($mssage, 3, 'debug.log'); } } class DebuggerMail implements Debugger { public function debug($message) { mail('schst@php.net', 'Error happened', $message); } }

88 Composite-Pattern class DebuggerComposite implements Debugger { } protected $debuggers = array(); public function adddebugger(debugger $debugger) { $this->debuggers[] = $debugger; } public function debug($message) { foreach ($this->debuggers as $debugger) { $debugger->debug($message); } } $debuggercomposite = new DebuggerComposite(); $debuggercomposite->adddebugger(new DebuggerLog()); $debuggercomposite->adddebugger(new DebuggerMail());

89 Composite-Pattern Das Composite-Pattern fügt mehrere Objekte zu einer Baumstruktur zusammen und ermöglicht es, diese von außen wie ein einzelnes zu verwenden.

90 Composite-Pattern

91 Adapter-Pattern Das Adapter-Pattern passt die Schnittstelle eines Objekts an die vom Client erwartete Schnittstelle. Es erleichtert die Nutzung von Fremdcode in eigenen Systemen. Das Adapter-Pattern arbeitet ähnlich wie ein Adapter für Steckdosen.

92 Adapter-Pattern class TwitterWarningSender { } protected $tweet; public function preparetweet($tweet) { $this->tweet = $tweet; } public function sendtweet() { // Code, der die Nachricht an Twitter verschickt. }

93 Adapter-Pattern class TwitterWarningSenderAdapter implements Debugger { protected $warningsender; public function construct(twitterwarningsender $warningsender) { $this->warningsender = $warningsender; }... } public function debug($message) { $this->warningsender->preparetweet($message); $this->warningsender->sendtweet(); } $warningsender = new TwitterWarningSender(); $debugger = new TwitterWarningSenderAdapter($warningSender); $microwave = new MicroWave($debugger);

94 Adapter-Pattern Das Adapter-Muster passt die Schnittstelle einer Klasse an die vom Client erwartete Schnittstelle an. Es ermöglicht die Zusammenarbeit von Klassen, die eigentlich aufgrund inkompatibler Schnittstellen nicht zusammenarbeiten können.

95 Adapter-Pattern

96 Verhaltensmuster Verhaltensmuster beschreiben die Interaktion zwischen Objekten. Zu den Verhaltensmustern gehören unter anderem Subject/Observer-Pattern Template-Method-Pattern Command-Pattern Iterator-Pattern

97 Template-Method-Pattern Definiert die Schritte eines Algorithmus in einer Methode Implementierung der einzelnen Schritte bleibt Unterklassen vorbehalten Gemeinsames Verhalten muss nur einmal implementiert werden: Änderungen am Algorithmus nur an einer Stelle notwendig Neue Unterklassen müssen nur die konkreten Schritte implementieren

98 Template-Method-Pattern abstract class AbstractSandwichMaker {... } final public function makesandwich() { print "Butter auf s Brot\n"; $this->addbutter(); $this->addcheese(); if ($this->ismeltedsandwich()) { $this->melt(); } } abstract protected function addbutter(); abstract protected function addcheese(); abstract protected function ismeltedsandwich(); protected function melt() { print "Überbacke den Sandwich.\n"; }

99 Template-Method-Pattern class SwissCheeseSandwichMaker extends SandwichMaker { } protected function addbutter() { print "Füge Butter hinzu.\n"; } protected function addcheese() { print "Füge Swiss Cheese hinzu.\n"; } protected function ismelted() { return true; }

100 Template-Method-Pattern Das Template-Method-Pattern definiert die Schritte eines Algorithmus in einer Methode und überlässt die Implementierung der einzelnen Schritte den Unterklassen. Diese können somit Teile des Algorithmus modifizieren, ohne dessen Struktur zu verändern.

101 Template-Method-Pattern

102 Command-Pattern Kapselt einen Auftrag als Objekt. Aufträge (Objekte) sind parametrisierbar Aufträge können in einer Queue nacheinander abgearbeitet werden Aufträge können rückgängig gemacht werden.

103 Command-Pattern interface DishWasherCommand { public function execute(dishes $dishes); } class DishWaherSimpleWashCommand implements DishWasherCommand { public function execute(dishes $dishes) { echo "Das Geschirr wird gewaschen"; } } class DishWasherDryingCommand implements DishWasherCommand { public function execute(dishes $dishes) { echo "Das Geschirr wird getrocknet"; } }

104 Command-Pattern class DishWasher { } protected $programmes = array(); public function addprogramme($name, array $commands) { $this->programmes[$name] = $commands; } public function wash($prog, Dishes $dishes) { foreach ($this->programmes[$prog] as $command) { $command->execute($dishes); } }

105 Command-Pattern $wash = new DishWasher(); $wash->addprogramme('standard', array( new DishWasherSimpleWashCommand(), new DishWasherDryingCommand() )); $wash->wash('standard', $dishes);

106 Command-Pattern Das Command-Pattern kapselt einen Auftrag als Objekt. Dadurch wird ermöglicht, andere Objekte mit Aufträgen zu parametrisieren, Aufträge in eine Queue zu stellen oder diese rückgängig zu machen.

107 Command-Pattern

108 Enterprise Patterns Kommen aus der Java Welt Stark geprägt durch Martin Fowler Meistens komplexer als die Gang-of-Four Patterns Deswegen ab hier keine Beispiele mehr Mehr zu Enterprise Patterns in PHP im Buch "PHP Design Patterns"

109 Verteilte Architekturen

110 Klassische PHP Architektur Client HTTP Alle Logik und alle Daten in einer Applikation auf einem Server

111

112 Verteilte Architektur Client HTTP Frontend Service Layer Business Logic Storage

113 Verteilte Architektur Client HTTP Frontend Frontend Frontend Service Layer Business Logic Storage Storage Storage Storage

114 Vor- und Nachteile verteilter Architekturen + - Skaliert besser als monolithische Architekturen. Verschiedene Schichten können leichter erweitert werden. Komplexität steigt an Sie brauchen klare Deployment- Prozesse und Versionierung der einzelnen Schichten. Einzelne Schichten können getrennt voneinander entwickelt und gewartet werden. Gesteigerter Testaufwand

115 Fallbeispiel: 1und1.de Client HTTP Session Frontend und Business Logik Frontend und Business Logik Telnet Session Session Storage Storage Storage Session

116 Fallbeispiel: 1und1.de Cluster mit vier Frontend-Rechnern Daten werden in MySQL-Cluster gehalten Sessions werden in einem Session-Cluster verwaltet IP des Rechners, der die Session hält ist in Session-Id verschlüsselt Beliebige zustandslose Frontend-Rechner greifen dadurch immer auf den korrekten Session-Host zu Einfaches Telnet-Protokoll zum Abrufen der serialisierten Session-Daten

117 Fallbeispiel: United-Internet.de Client HTTP HTTP CDS Frontend Frontend CDS CDS Services Services Services

118 Fallbeispiel: United-Internet.de Cluster mit zwei Frontend-Rechnern Größter Teil der Business-Logik und Daten werden über Services (RMI, REST & SOAP) von verschiedensten Middleware-Systemen bereit gestellt. Statische Ressourcen werden beim Deployment auf Content-Delivery- Server übertragen. Content-Delivery-Server verwenden Light HTTPD Statische Ressourcen werden performant ausgeliefert Requests auf Frontend-Rechner kann um bis zu 75% reduziert werden.

119 Caching

120 Premature Optimization Premature optimization is the root of all evil Donald Knuth

121 Premature Optimization Premature Optimization beschreibt die Situation in der Design Entscheidungen aufgrund von Performance-Optimierungen getroffen werden Solche Optimierungen resultieren oft in unleserlicherem Code

122 Michael Jackson über Premature Optimization Don't do it!

123 Michael A. Jackson über Premature Optimization Don't do it! For experts: Don't do it yet.

124 Premature Optimization Was wenn Performance-Optimierung unumgänglich ist? Anwendung & Design entwickeln Profiler / Benchmarks einsetzen Flaschenhälse identifizieren Ein einfaches und elegantes Design ist oft leichter zu optimieren

125 Caching und Optimierungen Caching und Optimierungen können in verschiedenen Schichten Ihrer Applikation Sinn machen. Verwenden Sie einen Profiler oder Logging, um zu analysieren, wo Ihre Performance Probleme liegen. Client Logik Dateisystem

126 HTTP-Caching PHP ermöglicht Ihnen, HTTP-Header zu setzen, die das Caching des Clients beeinflussen: Expires-Header ETag-Header Reduziert die Load auf dem Server und beschleunigt den Aufbau Ihrer Website.

127 Caching der Logik Cachen Sie komplexe Operationen, die nicht für jeden Request neu ausgeführt werden müssen. Parsen von XML-Dateien Datenbank-Abfragen Generierung von XSL-Stylesheets Legen Sie Daten im serialize-format von PHP ab.

128 Caching des Dateisystems Abfragen auf das Dateisystem kosten Zeit. Können zum Bottleneck werden. APC ist eine Alternative, Caching ist jedoch lokal pro Server. memcached kann auch von mehreren Servern eingesetzt werden.

129 PHP Caching Opcode-Caches verhindern, dass Ihre Skripte bei jedem Request neu interpretiert werden müssen. Alternative PHP Cache ( eaccelerator ( XCache ( Zend Server (

130 Don't reinvent the wheel...

131 ... unless you plan learning more about wheels "Reinventing the wheel" ist eines der bekanntesten Anti-Patterns in der Software Entwicklung Stetige Neuerstellung von Software ohne bestehende Lösungen oder Frameworks zu nutzen Verhindert Wiederverwendung und führt zu instabiler, unreifer, teurer Software Sie sind nicht alleine Irgendwo auf der Welt kämpft immer jemand an den gleichen Software Design Problemen wie Sie

132 Vorteile von Frameworks Bringen fertige Komponenten und Lösungen für typische Probleme mit: Cross-Cutting-Concerns werden vom Framework gelöst. Fokussieren Sie Ihren Entwicklungsaufwand auf die Business-Logik anstatt auf das Schreiben von Glue-Code. Standardisieren Ihre Architektur und Ihren Entwicklungsprozess: Durch Inversion-of-Control wird die Steuerung des Ablaufs an das Framework übergeben. Ihr Team implementiert Standard-Interfaces des Frameworks.

133 Zend Framework Komponenten-orientiertes Framework für PHP 5 Fokusiert auf Web 2.0 Anwendungen Viele Komponenten wie z.b. MVC- System, Lokalisierung, PDF- Erstellung oder Suchfunktionen Einige der Merkmale Flex Integration LDAP Interface REST Interface Caching Google Apps Integration

134 Symfony MVC Framework für PHP 5 Einige der Merkmale Wird seit 2005 entwickelt Basiert auf den Prinzipien von Ruby on Rails Fokusiert für die Entwicklung von Enterprise-Level Anwendungen (wie z.b. Askeet und Yahoo) Template Engine mit PHP Syntax Scaffolding von CRUD-Interfaces Request Dispatcher für "saubere" URLs Mehrsprachigkeit

135 CakePHP MVC Framework für PHP 4 und 5, dass seit 2005 entwickelt wird Basiert auf den Prinzipien von Ruby on Rails Fokussiert auf Einfachheit und schneller Entwicklung Geeignet für Websites und Kommandozeilen-Tool Einige der Merkmale Application Scaffolding Code Generation Authentifizierung Helper für AJAX, XML, RSS, JavaScript und mehr

136 CodeIgniter Leichtgewichtiges auf Einfachheit und Schnelligkeit fokussiertes Framework für PHP 4 Erste öffentliche Version seit 2006 Gut geeignet für Shared Hosting Accounts Gute Dokumentation mit vielen Video Tutorials, einem User Guide und einem Wiki Einige der Merkmale Bild-Manipulation FTP-Support Verschlüsselung Filtern von Eingaben und Ausgaben

137 Apache Zeta Components Besser bekannt als ez Components Einige der Merkmale Seit Juli 2010 bei Apache Template Engine Modulare Komponentenbibliothek für PHP 5 zetacomponents Unterstützung für RSS-Feeds Generierung von Graphen WebDAV Server Validierung von Benutzereingaben

138 Und viele Weitere

139 Der Code Clean Code YAGNI Design Patterns Caching Verteilte Architekturen Don t Reinvent

140 Buchempfehlungen

141 Das Team Viele Köche verderben nicht immer den Brei.

142 Kommunikation

143 Communication is King! Verstehen die Entwickler, was der Kunde möchte? Versteht der Kunde, was der Entwickler liefern kann? Verstehen die Entwickler gegenseitig wirklich, wie die Schnittstellen aussehen? Verstehen die Entwickler, was die Qualitätssicherung braucht? Verstehen Sie, was ich damit sagen will?

144 Kommunikationswege Treffen von Angesicht zu Angesicht. Treffen von Angesicht zu Angesicht. Treffen von Angesicht zu Angesicht. Videokonferenzen. Telefonkonferenzen. s und Instant Messenger. Projekt-Blogs und Microblogging.

145 Kreative Kommunikations-wege

146 Vertrauen Das Vertrauen gibt dem Gespräch mehr Stoff als Geist. François Duc de La Rochefoucauld Performing Norming Storming Forming

147 Teambildung Gemeinsame private Erlebnisse stärken das Teamgefühl und fördern die Zusammenarbeit. Das gilt nicht nur für gemeinsame Essen, jedoch ist der Effekt dabei besonders groß. Schaffen Sie Rituale.

148 Tod durch Meeting Team-Meetings sind oft unstruktiert und werden von vielen als verschenkte Zeit empfunden. Machen Sie sich Gedanken über die Struktur und das Ziel der Meetings. Richten Sie verschiedene Meetings mit verschiedenen Zielen ein, statt alles in einem Meeting zu besprechen. Strategie-Meeting, Status-Meeting,... Es gibt kein Rezept für die richtigen Meetings. Richten Sie die richtigen Meetings für Ihr Team ein.

149 Beat the Meeting Be...scheiden Todo 60s pro Thema Erfolgreich Jedes Team- Mitglied erzählt 60 Sekunden zu jedem Thema. Ein Thema geht reihum, bevor das nächste Thema drankommt. Abgehakt

150 Vorteile von BEAT Die Meetings erhalten eine klare Struktur. Jeder weiß, was von ihm erwartet wird und kann sich vorbereiten. Die vorangegangene Woche wird reflektiert und sowohl über positive als auch negative Erlebnisse nachgedacht.

151 Planning Poker

152 Organisation und Struktur

153 Die richtige Team-Zusammensetzung Senior vs. Junior Entwickler Kommunikative Mitarbeiter vs. Zuhörer Kreative Köpfe vs. Analytiker Führungspersönlichkeiten

154 Verantwortung Teilen Sie die Verantwortung im Team auf und vermeiden Sie, dass diese sich an wenigen Stellen konzentriert. Etablieren Sie Collective Code Ownership. Ermöglichen Sie einen konstruktiven Umgang mit Fehlern im Team, ansonsten wird niemand Verantwortung übernehmen. Zu Verantwortung gehört auch die Möglichkeit, Entscheidungen treffen zu dürfen.

155 Kultur der Angst Was wären wir sündigen Kreaturen dann ohne die Angst, diese vielleicht wohltätigste und gnädigste Gabe Gottes? Umberto Eco, Der Name der Rose

156 Sie leben in einer Kultur der Angst, wenn... es gefährlich ist, bestimmte Dinge auszusprechen. Zielvorgaben so aggressiv sind, dass diese unmöglich erreicht werden können. Macht über gesunden Menschenverstand triumphieren darf. die Leute, die gehen müssen, sind im Durchschnitt kompetenter als die, die bleiben. Aus "Spielräume" von Tom DeMarco

157 Matrixorganisation Teamleiter PHP Teamleiter Frontend Teamleiter QA Projektleiter A PHP Entwickler 1 Frontend Entwickler 1 Tester 1 PHP Entwickler 2 Frontend Entwickler 2 Tester 2 Projektleiter B PHP Entwickler 3 Frontend Entwickler 3 Tester 3 PHP Entwickler 4 Frontend Entwickler 4 Projektleiter C PHP Entwickler 5 Frontend Entwickler 5 Tester 4 Projekteinheit Organisatorische Einheit

158 Vor- und Nachteile der Matrixorganisation + - Kürzere Kommunikationswege Spezialisierung der Teamleiter, sie müssen nicht parallel noch Projektmanager sein permanenter Ansprechpartner für den Mitarbeiter, der sich um dessen Weiterentwicklung kümmern kann. Kompetenzkonflikte können auftreten Langsame Entscheidungsfindung Hoher Kommunikationsaufwand Unsicherheit bei den Mitarbeitern ( Zwei Herren )

159 Das Team Kommunikation Organisation & Struktur

160 Buchempfehlungen

161 Methoden und Tools Schneiden, mixen, rühren und der richtige Ofen.

162 Versionsverwaltung

163 Versionsverwaltung Ermöglicht parallele Änderungen an einem Projekt Es gibt viele Variationen von Versionsverwaltungssystemen - alle teilen die gleichen Konzepte: Checkouts, Commits, Merges und Nebenläufigkeit Es ist egal, welches System Sie einsetzen, aber tun Sie's!

164 Richtlinien für die Versionsverwaltung Einigen Sie sich auf gemeinsame Richtlinien Checkins von Zwischenschritten (nicht funktionierenden)? Wo sollte der Code eingechecked werden? Gibt es Orte die weniger kontrolliert werden? Wie gelangen die Änderungen in Releases? Wie werden Tags, Branches und der Trunk verwendet?

165 Branching Patterns Gängige Patterns Release Branches Feature Branches

166 Release Branch Ist die Entwicklung einer neuen Version der Anwendung abgeschlossen, wird ein Release Branch erzeugt Dieser Branch wird anschließend getestet, getagged und deployed /trunk /branches/v1.0 /branches/v2.0 /tags/v1.0.0 /tags/v2.0.0

167 Aktualisierung des Release Branch Entwicklung im Branch direkt sollte generell vermieden werden Bugs werden im Trunk gefixt und anschließend in den Branch gemerged Ansonsten besteht die Gefahr, dass Änderungen nicht in den Trunk übernommen werden und beim nächsten Release-Branch fehlen Ausnahmen sind Änderungen, die für den Trunk nicht mehr nötig oder nicht möglich sind

168 Feature Branch Umfasst eine Neuentwicklung mehrere Commits die den Trunk in einen instabilen Zustand versetzen, wird ein Feature Branch angelegt Nach abgeschlossener Test-Phase wird der Branch zurück in den Trunk gemerged und von dort deployed /trunk /branches/feature-1 /branches/feature-2

169 Aktualisierung des Feature Branch Ein Feature Branch sollte stets aktuell gehalten werden Im Idealfall wird der Trunk ein bis zwei mal pro Woche in den Branch gemerged Je älter ein Branch ist, desto schwieriger wird der Merge zurück in den Trunk Sobald der Branch zurück in den Trunk gemerged wurde ist die Entwicklung darin abgeschlossen

170 Tools zur Versionsverwaltung GIT

171 Tools zur Versionsverwaltung Subversion

172 Tools zur Versionsverwaltung CVS

173 Tools zur Versionsverwaltung Mercurial

174 Tools zur Versionsverwaltung Bazaar

175 Tools zur Versionsverwaltung LibreSource

176 Tools zur Versionsverwaltung Es ist egal welches Tool Sie einsetzen, aber tun Sie's

177 Hosting Optionen

178 Hosting Optionen

179 Hosting Optionen

180 Hosting Optionen

181 Entwicklungsumgebung

182 Entwicklungsumgebung

183 Entwicklungsumgebung Eclipse PDT Codelobster Komodo IDE NuSphere PhpED PHPEdit Dreamweaver Netbeans E-Texteditor phpdesigner Coda Zend Studio Textmate Aptana Studio

184 Syntax Highlighting

185 Code Completion

186 Code Snippets

187 Code Folding

188 Navigation

189 Debugging

190 Integrierte Versionsverwaltung

191 Fehler- und Warnhinweise

192 Refactoring und Code Generierung

193 Unterstützung für HTML, CSS & JavaScript

194 Unit Tests

195 Die Qual der Wahl Schnell einsatzbereit oder möglichst "feature complete"? Kostenlos oder kostenpflichtig? Tipps zur Entscheidungsfindung Testen Sie die kostenlosen IDEs zuerst Wenn Sie eine IDE gefunden haben, die Ihre gewünschten Funktionen bietet, prüfen Sie ob diese korrekt in der IDE funktionieren Wenn nur wenige Funktionen fehlen, testen Sie dafür spezifische Tools

196 Statische Code Analyse

197 Statische Code Analyse White-Box-Test Verfahren - man benötigt den Quelltext Der Quelltext wird dabei einer Reihe formaler Prüfungen unterzogen Statische Code Analyse ermöglicht unter anderem das werkzeuggestützte oder automatisierte Erkennen von Fehlern die Abdeckung von zusätzlichen Qualitätsaspekten wie Wartbarkeit und Analysierbarkeit eine einfache Vergleichbarkeit der Messergebnisse mit anderen Systemen

198 phploc Misst mithilfe unterschiedlicher Ausprägungen den Umfang eines PHP Projekts anhand der Lines of Code (LOC) Darüber hinaus wird die Anzahl der Namensräume, Klassen, Methoden und Funktionen gezählt sebastianbergmann/phploc

199 Copy/Paste Detector (CPD) Durchsucht PHP Projekte nach dupliziertem Code (Code Clones) sebastianbergmann/ phpcpd

200 Dead Code Detector (DCD) Durchsucht PHP Projekte nach Code der nicht mehr aufgerufen wird sebastianbergmann/ phpdcd

201 PHP Depend Ein an JDepend angelehntes Tool das eine Vielzahl an Software- Metriken für PHP Projekte berechnet und visualisiert Zyklomatische Komplexität NPath-Komplexität

202 PHP Depend Ein an JDepend angelehntes Tool das eine Vielzahl an Software- Metriken für PHP Projekte berechnet und visualisiert Zyklomatische Komplexität NPath-Komplexität

203 PHP Mess Detector An das Java Tool PMD angelehntes Tool, dass auf PHP_Depend aufsetzt und Warnungen bzw. Fehler auslöst wenn vorgegebene Schwellenwerte für einzelne Software-Metriken überschritten werden

204 PHP_CodeSniffer Durchsucht PHP Projekte nach "übel riechenden Codes" (Code Smells) wie beispielsweise Formatierungsregeln Software-Metriken Erkennung von potentiellen Fehlern Performance Problemen PHP_CodeSniffer/

205 Testing & Integration

206 Test Es gibt viele Arten von Tests Unit Tests Ein Test auf der tiefsten Ebene bei dem einzelne Komponenten auf korrekte Funktionalität getestet werden Integrationstests Testen die Zusammenarbeit voneinander abhängigen Komponenten Akzeptanztests Ein Test der gelieferten Software durch den Kunden Systemtests Das gesamte System wird gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet

207 Unit Tests Im Unit Test werden kleinere Programmteile in Isolation von anderen Programmteilen getestet. Frank Westphal

208 Unit Tests Testen eine einzelne Codeeinheit isoliert. Die Granularität der Codeeinheit kann von Methoden über Klassen bis hin zu Komponenten reichen. Unit Test-Frameworks für PHP PHPUnit - JUnit Portierung für PHP von Sebastian Bergmann SimpleTest - von Marcus Baker

209 Unit Tests require_once 'OvenCompany.php'; class OvenCompanyTest extends PHPUnit_Framework_TestCase { } protected $ovencompany; protected function setup() { $this->ovencompany = new OvenCompany(); } public function testaddtoinventory() { $this->ovencompany->addtoinventory(new MicroWave('Bosch', 'silber')); $ovencount = $this->ovencompany->countovensininventory(); $this->assertequals(1, $ovencount); }

210 Unit Tests $ phpunit OvenCompanyTest PHPUnit by Sebastian Bergmann.. Time: 0 seconds OK (1 test, 1 assertion)

211 Integrations- und Akzeptanztests There is a vast gulf between the process mappers who model business systems pictorially, and the programmers who grind out the C++ or Java or.net services that support those business systems. Between the two camps lies a fertile land of opportunity. It's time to jointly explore it. Ward Cunningham

212 FIT - Framework for Integrated Tests Framework für Integrations- und Akzeptanz-Tests Der Kunde schreibt die Testfälle in HTML, Word oder Excel Bezieht den Kunden in den Entwicklungsprozess ein und fördert agiles Vorgehen Mittlerweile für sehr viele Sprachen verfügbar, für PHP innerhalb von PEAR

213 Funktionsweise Kunde erstellt eine Tabelle mit Eingabe-Parametern und erwarteten Rückgabe-Werten FIT parst die HTML-Tabelle und interpretiert diese als Testfälle FIT reicht die Eingabeparameter an den Testcode (Fixture) weiter Der Testcode führt den zu testenden Code aus FIT holt die das Ergebnis aus dem Testcode FIT markiert Abweichungen in der HTML-Tabelle

214 Funktionsweise

215 Webtests mit Selenium Dem Kunden sind Unit-Tests egal, wenn die Website nicht funktioniert Selenium prüft die Anwendung auf der Ebene, die der Kunde sieht Steuert den Browser fern und prüft gegen das erwartete Verhalten Funktioniert in allen großen Browsern, auch im IE6 Tests können über Firefox-Extension aufgezeichnet werden Selenium RC ermöglicht Fernsteuerung aus PHPUnit Tests

216 Selenium in Bildern

217 Selenium in Bildern

218 Continuous Integration Beschreibt den Prozess des regelmäßigen, vollständigen Builds und Testens einer Anwendung Vorteile durch den Einsatz von CI Integrations-Probleme werden frühzeitig entdeckt Fehler werden nicht verschleppt Code Qualität ist über den gesamten Entwicklungsprozess sichtbar

219 Continuous Integration SVN Repository CI Server

220 phpundercontrol

221 Mehr Tools

222 Better safe than sorry. Schaffe dir Sicherheitsnetze durch automatisierte Tests auf verschiedenen Ebenen deiner Applikation. Integriere regelmäßig und stelle Fehler frühzeitig fest.

223 Build-Systeme

224 Build-System Erleichtern Setup eines Projekts in neuen Umgebungen. Führen wiederkehrende Aufgaben aus, die nötig sind, um eine Applikation zu starten. Kopieren, Löschen, Verschieben Dependencies ermitteln Source-Code transformieren In PHP noch nicht so weit verbreitet, da meistens kein Code kompiliert werden muss.

225 Apache Ant Java basiert, aber universell einsetzbar. Plattform unabhängig. Build-Skripte werden in XML geschrieben und dann ausgeführt. Bereits seit Jahren in vielen Java-Projekten im Einsatz. Bereits für viele Aufgaben schon Tasks vorhanden, die diese ausführen. Eigene Tasks werden in Java implementiert.

226 Typisches Ant Build-Skript Default-Dateiname ist build.xml Ausführen durch Aufruf von ant, optional abweichender Dateiname <project name="myproject" default="build" basedir="."> <description>simple example build file</description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

227 Typisches Ant Build-Skript <project> gibt Projektname, Default-Target und Build-Verzeichnis an Optional Projektbeschreibung über <description> <project name="myproject" default="build" basedir="."> <description>simple example build file</description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

228 Typisches Ant Build-Skript Häufig verwendete Werte, wie Ordner-Namen, Versionen in Properties Können auch einfach aus einer.properties Datei gelesen werden <project name="myproject" default="build" basedir="."> <description>simple example build file</description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

229 Typisches Ant Build-Skript build -Target hängt vom init -Target ab Kopiert alle Dateien von src nach build <project name="myproject" default="build" basedir="."> <description>simple example build file</description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

230 Typisches Ant Build-Skript init -Stellt sicher, dass der build -Ordner existiert. Gibt mit <echo> eine Meldung nach STDOUT <project name="myproject" default="build" basedir="."> <description>simple example build file</description> <!-- set global properties for this build --> <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

231 Ausführen des Build-Files Aufruf von ant genügt $ ant Buildfile: build.xml init: [mkdir] Created dir: /Users/schst/tests/ant/build [echo] Directory /Users/schst/tests/ant/build build: [copy] Copying 1 file to /Users/schst/tests/ant/build BUILD SUCCESSFUL Total time: 0 seconds

232 Informationen zum Build-File Aufruf von ant -p $ ant -p Buildfile: build.xml simple example build file Main targets: Other targets: build init Default target: build

233 Features von ant Alle File-Tasks, die man sich vorstellen kann. Archive-Tasks, Pre-Processing Tasks (ANTLR, XSLT, etc.) Java kompilieren, JARs erstellen, etc. SCM-Tasks, Testautomatisierung, Code-Coverage Mails, Logging, SQL, FTP, SSH,... Als letzter Fallback einfach <exec/>

234 Phing PHP Port von Apache Ant. Konzept und Großteil der XML-Struktur übernommen. Leider nicht zu 100% kompatibel. Weniger vordefinierte Tasks als Ant, dafür mehr PHP-verwandte Tasks Neue Tasks werden in PHP geschrieben

235 Typisches Phing Build-Skript Default-Dateiname ist build.xml Ausführen durch Aufruf von phing, optional abweichender Dateiname <project name="myproject" description="simple example build file" default="build" basedir="."> <!-- set global properties for this build --> <property name="src" value="src"/> <property name="build" value="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

236 Unterschiede zum ant Build-Skript Beschreibung ist ein Attribut, kein Element. <property/> kennt nur value, keine location <project name="myproject" description="simple example build file" default="build" basedir="."> <!-- set global properties for this build --> <property name="src" value="src"/> <property name="build" value="build"/> <target name="init"> <!-- Create the build directory structure --> <mkdir dir="${build}"/> <echo message="directory ${build}"/> </target> <target name="build" depends="init"> <copy todir="${build}"> <fileset dir="${src}"/> </copy> </target> </project>

237 Ausführen des Build-Files Aufruf von phing genügt $ phing Buildfile: /Users/schst/tests/phing/build.xml MyProject > init: [echo] Directory build MyProject > build: [copy] Copying 1 file to /Users/schst/tests/phing/build BUILD FINISHED Total time: seconds

238 Informationen zum Build-File Aufruf von phing -p $ phing -p Buildfile: /Users/schst/tests/phing/build.xml simple example build file Default target: build Subtargets: build init

239 phing oder ant? Verfügbare Tasks Sehr viele Tasks vorhanden, da jahrelang im Einsatz Weniger Tasks als ant, die Wichtigsten sind vorhanden Arten der Tasks Erweitern Breit gefächtert, allerdings keine PHP-spezifischen Tasks Kann einfach erweitert werden, Java-Wissen nötig Sehr PHP-spezifische Tasks, wie PHPUnit, phpdocumentor, phpcodesniffer Kann einfach erweitert werden, PHP-Wissen reicht aus

240 Apache Maven Java-basiertes Build-System. Setzt auf Convention over Configuration. Verwendet einen deklarativen Ansatz. Alle Informationen zu einem Projekt werden in einem Project Object Model (pom.xml) definiert. Build-Prozess wird nicht mehr programmatisch beschrieben, sondern standardisiert. Sehr mächtiges Dependency-Management.

241 Typisches Maven POM Beschreibt das Projekt und dessen Dependencies Beschreibt nicht, wie der Build aussieht <project xmlns=" xmlns:xsi=" xsi:schemalocation=" maven.apache.org/xsd/maven xsd"> <modelversion>4.0.0</modelversion> <groupid>de.paul-bocuse</groupid> <artifactid>mvn-app</artifactid> <name>php mit Paul Bocuse</name> <packaging>jar</packaging> <version>1.0-snapshot</version> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

242 Typisches Maven POM Maven verwendet XML-Namespaces Jedes Projekt hat eine Group- und Artefakt-Id, optional einen Namen <project xmlns=" xmlns:xsi=" xsi:schemalocation=" maven.apache.org/xsd/maven xsd"> <modelversion>4.0.0</modelversion> <groupid>de.paul-bocuse</groupid> <artifactid>mvn-app</artifactid> <name>php mit Paul Bocuse</name> <packaging>jar</packaging> <version>1.0-snapshot</version> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

243 Typisches Maven POM Packaging Mechanismus ist JAR, kann auch WAR, EAR, etc. sein. Plugins können neue Packaging Mechanismen hinzufügen. <project xmlns=" xmlns:xsi=" xsi:schemalocation=" maven.apache.org/xsd/maven xsd"> <modelversion>4.0.0</modelversion> <groupid>de.paul-bocuse</groupid> <artifactid>mvn-app</artifactid> <name>php mit Paul Bocuse</name> <packaging>jar</packaging> <version>1.0-snapshot</version> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

244 Typisches Maven POM Dependencies werden über Maven-Koordination definiert Group-Id, Artefact-Id und Version (bzw. Range) <project xmlns=" xmlns:xsi=" xsi:schemalocation=" maven.apache.org/xsd/maven xsd"> <modelversion>4.0.0</modelversion> <groupid>de.paul-bocuse</groupid> <artifactid>mvn-app</artifactid> <name>php mit Paul Bocuse</name> <packaging>jar</packaging> <version>1.0-snapshot</version> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

245 Ausführen des Builds mvn package startet den Build $ mvn package [INFO] Scanning for projects... [INFO] [INFO] Building PHP mit Paul Bocus [INFO] task-segment: [package] [INFO] [INFO] [resources:resources {execution: default-resources}] [WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent! [INFO] skip non existing resourcedirectory /Users/schst/tests/mvn/src/main/ resources [INFO] [compiler:compile {execution: default-compile}] [INFO] No sources to compile... [INFO] [jar:jar {execution: default-jar}] [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 4 seconds [INFO] Final Memory: 15M/81M [INFO]

246 Maven Repositories Public Repository Company Repository Developer 1 Local Repository Developer 2 Local Repository Developer 3 Local Repository

247 Der Maven Build-Lifecycle mvn compile mvn test mvn install generate-sources compile test-compile test package integration-test install deploy POM archetype compile surefire jar install

248 Sind wir noch beim PHP World Kongress?

249 Maven mit PHP Maven Plugin PHPUnit Integration Generiert Dokumentation über DoxyGen (statt JavaDoc) Installation über Hinzufügen von neuen Repositories in der settings.xml

250 Erstellen eines neuen Projekts maven-php liefert einen eigenen Archetype $ mvn archetype:generate -DarchetypeGroupId=org.phpmaven -DarchetypeArtifactId=php5-lib-archetype -DarchetypeVersion=1.1 -DgroupId=de.paul-bocuse -DartifactId=mvn-app [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [INFO] Building Maven Default Project [INFO] task-segment: [archetype:generate] (aggregator-style) [INFO] [INFO] Using property: package = de.paul-bocuse Confirm properties configuration: groupid: de.paul-bocuse artifactid: mvn-app version: 1.0-SNAPSHOT package: de.paul-bocuse [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds

251 Typisches PHP Maven POM Basisdaten wie bei Java-Projekten, aber <packaging> ist php maven-php-plugin wird für den Build benötigt <project> <modelversion>4.0.0</modelversion> <groupid>de.paul-bocuse</groupid> <artifactid>mvn-app-2</artifactid> <packaging>php</packaging> <name>sample PHP 5 library project</name> <version>1.0-snapshot</version> <build> <plugins> <plugin> <groupid>org.phpmaven</groupid> <artifactid>maven-php-plugin</artifactid> <extensions>true</extensions> </plugin> </plugins> </build>... </project>

252 Typisches PHP Maven POM PHPunit wird als Dependency benötigt Wird automatisch aus dem Maven PHP Repository geladen <project>... <dependencies> <dependency> <groupid>org.phpunit</groupid> <artifactid>phpunit5</artifactid> <version>3.3.9</version> <scope>test</scope> </dependency> </dependencies>... </project>