PhpStorm 2016.3 Neuerungen

Seit dem 01.09.2016 läuft das Early Access Programm für PhpStorm 2016.3 – doch was sind wichtige PhpStorm 2016.3 Neuerungen? Auf ein paar wichtige Punkte möchte ich im Folgenden eingehen.

PhpStorm 2016.3 Neuerungen

Dass PhpStorm 2016.3 in einer neuen EAP-Version released wurde, habe ich bereits in einem früheren Blogbeitrag erwähnt.

Mehrere Projekte in einem Fenster öffnen

Eine der größten Neuerungen an PhpStorm 2016.3 ist die Möglichkeit, mehrere Projekte parallel in einem Fenster („Frame“) geöffnet zu haben. Hier setzt ihr einfach ein Häkchen beim öffnen des Projektes, damit PhpStorm weiß, dass es das Projekt zum aktuellen in der Übersicht „hinzufügen“ soll. Achtung: „Per-Project“-Einstellungen werden in diesem Modus ignoriert!

Docker-Support für Remote-Interpreter

Ab sofort ist PhpStorm nun auch endlich in der Lage, Remote-Interpreter aus einem Docker-Container zu verwenden.

Autocompletion für Methoden und Felder ohne „var“ und „function“-Keyword

Eine weitere PhpStorm 2016.3 Neuerung ist, dass ihr nun auch eine Autocompleten für das Überschreiben von Konstanten und Co.

Projektweite PHP7 Strict-Types

Es gibt nun eine „Missing Strict Types Declaration“-Inspektion. Diese aktiviert den Strict-Type-Modus in PhpStorm und ist zu finden unter Settings|Editor|Code Style|Inspections|PHP|Type Compatibility. Diese Einstellung erzeugt eine Warnung in den PhpStorm-Inspections, sofern die Datei kein declare(strict_types=1); als erste Zeile enthält. Es ist auch in Planung, eine Art „automatische Korrektur“ zu implementieren, welche diese Zeile automatisiert überall hinzufügt.

Verbesserter Support für PSR-0/PSR-4

Die letzte, wichtige Neuerung, die ich euch vorstellen möchte, sind verbesserte Unterstützungen für PSR0 und PSR4. Die Funktionen „Create new text“ und „Create new class“ wurden verbessert und beachten die Standards PSR-0 und PSR-4 – sie erlaubeneuch nun auch das generieren von neuen Verzeichnisses. Ebenso beachtet PhpStorm 2016.3 bei der automatischen Erstellung von Testklassen nun das (im PhpStorm) markierte „Test Source Root“ und generiert in diesem Ordner automatisch die Datei passend zum Test.

 

Natürlich bringt PhpStorm 2016.3 noch viele weitere Neuerungen mit sich. Diese könnt ihr auf dem Blogeintrag direkt bei Jetbrains einsehen. Zu finden ist der Blogeintrag hier.

Was ist Agile Softwareentwicklung – Ein Einblick

Der erste Teil der Artikelserie zum Thema „Agile Softwareentwicklung“ wird sich mit der Definition beschäftigen, was überhaupt Agile Softwareentwicklung ist. Im darauffolgenden Teil des Artikels soll unter anderem auf Vorteile und Nachteile dieses Entwicklungsmodelles eingegangen werden. Weiterhin sollen ebenso die ein oder anderen Stolpersteine der „Agilität“ herausgearbeitet werden.

Was ist Agile Softwareentwicklung?

Die Agilität in der Softwareentwicklung beschreibt im Groben das Bestreben, einen möglichst flexibel handhabbaren Softwareentwicklungsprozess zu haben. Durch das eliminieren von unnötigem Verwaltungsaufwand, soll der Prozess schlank gehalten werden und die Softwareentwicklung soll in den Vordergrund treten.

Unter diesem flexibel handhabbaren Entwicklungsprozessen versteht man die Tatsache, möglichst zeitnah den Fokus von einem Thema auf ein anderes Thema setzen zu können. Hierbei soll nicht mehr im Vorhinein eine Art „Fünf-Jahres-Plan“ erstellt werden. Vielmehr es soll möglich sein, nach der Umsetzung des ersten Features ein beliebiges, zum Zeitpunkt der Erstellung von Feature 1 noch nicht bekanntes Feature, einwerfen und in die Umsetzung geben zu können.

Die genannte Agilität wird gestützt durch das sogenannte „Agile Manifest“, welches im Februar 2001 veröffentlicht wurde. Selbiges umfasst vier Grundwerte der „Agilität“:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Schaut man sich diese Werte an, so geht es vordergründig nicht darum, sich an Prozessen, Befehlsketten und ähnlichem aufzuhalten. Vielmehr ist dafür zu sorgen, möglichst schnell ein (den Kundenanforderungen genügendes) funktionierendes Produkt zu liefern.

Vorteile des agilen Entwicklungsprozesses

Die Softwareentwicklung in ihrer agilen Form mag für den einen oder anderen sicher als eine Modeerscheinung bekannt sein. Diese Modeerscheinung bringt jedoch handfeste Vorteile mit sich. Beginnen wir mit dem Punkte der Risikobewertung. Einer der Fokuspunkte agiler Entwicklung liegt darin, ein Produkt in kurzen Iterationen umzusetzen. Aus diesem Vorgehen folgt, dass schlecht ankommende Versionen einer Software weniger negative Auswirkungen generieren. Nimmt man das Vorgehen per Wasserfallmodell als Vorbild, so ist diese (meist längere) Planungs- als auch Umsetzungszeit verloren. Agilität schränkt diesen Zeitraum stark ein, indem es kurze Iterationen fordert. Ein Feature nach dem anderen. Funktioniert dieses eine Feature nicht, sind lediglich die Zeiten für diese Iteration vergeben. Bei herkömmlichen Entwicklungsmethoden, muss das geplante und entwickelte Feature beim Kunden ankommen, ansonsten geht viel Geld verloren.

Ebenso vorteilhaft ist, dass man sehr viel schneller auf Marktgegebenheiten reagieren kann. Märkte und Kundenverhalten ändern sich häufig und teilweise sehr schnell. Genau diese Reaktionsfähigkeit durch agile Softwareentwicklung ist Gold wert: durch die Gegebenheit wenige Wochen an einer Softwareversion zu arbeiten, müssen keine langen Planungs- und Umsetzungsphasen verworfen werden. Im Gegenteil: Diese Arbeiten können abgeschlossen werden. Es muss keine, bzw. im Notfall nur wenig Arbeit verworfen werden und es kann direkt mit der Reaktion auf das Marktumfeld begonnen werden.

Ein weiterer, wichtiger Punkt ist der direkte Draht zwischen IT-Abteilung und Management. Auch wenn es nicht so wirkt: durch den frühen Einstieg der IT in die Planungen eines Features lassen sich verschiedene Fehlplanungen vermeiden, welche zum Beispiel im Wasserfallmodell zu einem großen „Knall“ und einem deutlichen Mehraufwand an Investitionen geführt hätten.

Nachteile agiler Entwicklung

Es ist nicht nur so, dass die agile Entwicklung ausschließlich Vorteile mit sich bringt. Sie bringt auch einige Nachteile mit sich. Nach meiner Erfahrung der letzten 2,5 Jahre sind sich (vor allem zu Anfang eines solchen Prozesses) viele Projektmanager nicht im klaren darüber, dass das Wort „agil“ nicht gleichzusetzen ist mit dem Wort „spontan“. Ein Kanban- oder SCRUM-Prozess verleiten sehr schnell dazu, doch noch das eine oder andere Ticket tauschen oder „in den Prozess quetschen“ zu wollen. Dass das nicht gewollt ist, sollte jedem verständlich sein. Auch ein agiler Prozess lebt von einer bestimmten Kontinuität. Diese erreicht man unter Verwendung von SCRUM beispielsweise durch das Einhalten der „Sprints“. Diese beschreiben das definieren eines Ziels binnen der nächsten 14 Tage und auch, dass sich an diesem Ziel möglichst nichts änder sollte.

Ebenso wirkt es sich nachteilig aus, dass wenige Entwickler und auch wenige Führungsrollen vertraut mit agiler Entwicklung sind. Es gilt, vor allem zu Beginn, auf die strikte Einhaltung besitmmter Regeln zu achten. In vielen Fällen werden Vorgehen wie SCRUM zunächst zu einem Naserümpfen im Management führen. Auf den ersten Blick wirken viele Meetings dieses Entwicklungsprozesses nach „Überfluss“. Gerade Meetings wie das Estimation-Meeting helfen jedoch auch dem Management ein besseres Gefühl für den Wert einer Aufgabe („User-Story“) zu bekommen. Auf die einzelnen Phasen des Sprints sowie die dazugehörigen Meetings werde ich jedoch in einem weiteren Artikel eingehen.

Artikelserie: Agile Softwareentwicklung

Mittlerweile ist die agile Softwareentwicklung in aller Munde – viele setzen hier vor allem auf den SCRUM-Prozess. Aus diesem Grund möchte ich mit Hilfe einer Artikelserie auf verschiedene Themen eingehen. Unter anderem werde ich hierbei erläutern:

Struktur der Artikelserie Agile Softwareentwicklung

  • Was ist agile Softwareentwicklung
    • Birgt das Vorgehen der agilen Entwicklung Vorteile?
    • Welche Nachteile sind mit der agilen Softwareentwicklung verbunden?
  • Was ist SCRUM?
    • Wie ist SCRUM aufgebaut?
    • Welche Phasen gibt es im SCRUM-Zyklus?
    • Was ist ein Sprint?
  • Was ist Kanban?
    • Wie funktioniert Kanban?
    • Bietet es Vorteile oder Nachteile gegenüber SCRUM?

Wie schon erwähnt soll das Ganze in die Form einer Artikelserie gegossen sein. Ich werde dabei vor allem viele praktische Erfahrungen einfließen lassen, welche ich innerhalb meiner letzten zwei Jahre als SCRUM-Master sammeln konnte.

Das Thema Agilität wird somit der Fokuspunkt dieses Blogs für die nächsten Tage und Wochen werden. Ich hoffe, mit dieser Serie einen echten Mehrwert im Internet zu schaffen – sofern ihr den einen oder anderen Artikel also interessant findet, teilt mir das gerne mit. Kommentiert fleißig und teilt den Artikel mit Freunden, Bekannten und Kollegen.

Finanzrechner für die Rente – wann bin ich dran?

In der heutigen Zeit sorgen sich immer mehr Menschen um ihre finanzielle Sicherheit während der Rente. Das Renteneintrittsalter wird gefühlt von Jahr zu Jahr immer weiter nach oben gesetzt – mittlerweile diskutiert man, ob nicht 72 oder mehr Jahre ein gutes Rentenalter wären.

Wem das alles zu kompliziert ist, der sorgt sich schlichtweg selbst um seine Rente. Doch wieviel Geld muss ich eigentlich auf die Hohe Kante legen und ab wann kann ich damit in Rente gehen? Ich selbst habe mich genau das gleiche gefragt. Aus diesem Grund habe ich angefangen, wilde Excel-Tabellen zu erstellen mit einem Wust aus Formeln, um mir meinen jetzigen Verdienst zu errechnen sowie meine Ausgaben in den Überblick zu bekommen. Daraus konnte ich später errechnen, wie lange ich wohl noch arbeiten gehen muss, um irgendwann von meinem angehäuften Kapital leben zu können.

Jeder, der sich dafür interessiert, schaut am besten mal das von mir programmierte Browsertool „Finanzrechner“ an. Ihr findet es auf meiner privaten Webseite unter einer Subdomain: http://finanzrechner.gunter-thomas.de/

Wenn ihr Featurewünsche habt, kontaktiert mich sehr gern. Das Programm ist noch im Aufbau und dahingehend noch sehr featurearm – aber ich versuche natürlich weiterhin, immer wieder sinnvolle und neue Features hinzuzufügen. Im Hinterkopf habe ich da bereits einiges, wie zum Beispiel den Zinsezins-Effekt für vorhandenes Kapital oder auch eine Variante der Anpassung verschiedener Ausgabearten mittels Schieberegler und daraufhin sofortiger Neuberechnung des Renteneintrittsalters.

Nicht beachtet werden auch hier eventuelle Gehaltserhöhungen in Zukunft. Der Rechner geht nur vom aktuellen Einkommen, sowie den aktuellen Ausgaben aus.

Schaut es euch an, probiert es aus. Aktuell ist es eher rudimentär – aber ich wollte es euch nicht vorenthalten einmal ausrechnen zu können, wann ihr in den Ruhestand übergehen könnt. Und nutzt die Möglichkeit, öfter vorbeizuschauen – ich werde versuchen, immer und immer wieder das eine oder andere neue und interessante Feature für euch zu ergänzen!

Buchempfehlung: PHP Design Patterns

Heute möchte ich euch eine Buchempfehlung im Bereich Entwurfsmuster („Design Patterns“) aussprechen. Das Buch, um welches es geht, nennt sich „PHP Design Patterns“ und wurde von Stephan Schmidt geschrieben. Es ist in der 2. Auflage vorhanden.

Warum empfehle ich das Buch? In meinen Augen gehört es klar zum Standardwerk eines jeden Softwareentwicklers. Wie der Name vermuten lässt, stellt das Buch einen starken Bezug zur PHP-Welt her. Auch wenn die Beispiele allesamt PHP Code sind, so sind sie in ihrer Art und Weise dennoch in fast allen OOP-Sprachen anwendbar. Genau das macht das Buch für mich so wertvoll – und auch deshalb ist es in meinem Bücherregal gelandet. Auch die Rezensionen auf Amazon überzeugen meiner Meinung nach sehr – das Buch hat 4,6 von 5 Sternen bei 34 Bewertungen bekommen.

Für alle, die noch nicht besonders fit in objektorientierter Entwicklung mit PHP sind findet sich zu Beginn des Buches ein kleiner Crash-Kurs, welcher die neuen PHP 5.3, bzw. generell den Objektorientierten Ansatz von PHP erläutert.

„PHP Design Patterns“ umfasst eine umfangreiche Auswahl von Design Patterns. Design Pattern sind Entwurfsmuster, welche euch dabei helfen sollen euren Quellcode zu strukturieren und sauber zu halten. Sie geben Lösungen für bereits vorhandene Probleme vor und bieten einen Lösungsansatz.

Alle Beispiele sind in diesem Buch sehr schön erläutert. Es werden öfter Bezüge zur Praxis gesucht um die Pattern an einem Beispiel zu erklären, welches nicht nur theoretische Anwendung findet. Das erhöht die Verständlichkeit merklich. Leider ist das Buch mit seinem Bezug zu PHP 5.3 etwas in die Jahre gekommen. Das macht aber dahingehend nichts, als das Design Patterns weiterhin ihre Gültigkeit behalten. Einige Quellcodestellen des Buches ließen sich jedoch mittlerweile sicher eleganter lösen.

In meinen Augen ein extrem gelungenes Buch und oftmals ein Standardwerk bei Entwicklern in der Webprogrammierung. Ihr solltet euch dieses 512 Seiten starke Buch unbedingt einmal anschauen! Kaufen könnt ihr es hier auf Amazon.

Ein Tag als Softwareentwickler

Der Beruf des Softwareentwicklers. Er beginnt irgendwann zu unchristlichen Zeiten und endet auch zu solchen. Dabei macht man nichts anderes, als den ganzen Tag vor einem Bildschirm zu sitzen und auf eine Tastatur einzuhacken. 120 Anschläge die Sekunde – acht Stunden am Tag durchweg, sodass sich der schwarze Bildschirm mit immer mehr weißen Zeichen füllt. Am Ende drückt man dann einmal auf die ENTER-Taste und zack – wir sind drin, im System der NSA. Zumindest, wenn es nach vielen Filmen geht.

Doch wie läuft so ein Tag im Leben eines Softwareentwicklers wirklich ab? Ein Tag im Leben eines Softwareentwicklers könnte wie folgt ablaufen:

Das Entwicklerleben …

… beginnt in den meisten Fällen zunächst einmal mit dem erscheinen auf Arbeit. Sachen abgelegt, schon einmal den PC einschalten und danach ab in die Küche – erstmal einen Kaffee ziehen und eine Flasche Wasser greifen. Zurück mit der Ausrüstung am Arbeitsplatz am PC einloggen und – genau, ihr wusstet es – eMail-Client öffnen. Emails lesen. Die Hände über dem Kopf zusammenschlagen. Emails beantworten. Noch schnell ein kurzer Blick über das Ticketsystem werfen – gibt es zu meinen Zwischenständen von gestern etwas neues? Sind die fertig bearbeiteten Tickets abgenommen, oder muss ich nachbessern und Bugs fixen? Nun, ist auch egal – es ist schon wieder 09:30 und damit Zeit für unser daily Stand-Up. Beeilung, der SCRUM-Master steht schon in der Tür.

Das Daily StandUp

Das Daily- oder auch Standup-Meeting ist ein 10-15 minütiges Meeting. Dabei bildet die Entwicklerschaft einen Halbkreis – mit der offenen Seite zum Backlog, welches entweder in analoger Form auf einer Tafel oder in digitaler Form mit dem Beamer an die Wand projeziert wird. Es dient dem kurzen Austausch über den aktuellen Entwicklungsstand innerhalb des Teams. Ziel ist es, den Tag zu planen: welche Themen will ich heute angehen? Bei welchen brauche ich noch Zuarbeit? Was bekomme ich noch fertig heute, bei welchen Tickets brauche ich länger? Gibt es irgendetwas wichtiges, auf das ich meine Teammitglieder hinweisen möchte?

Nachdem wir diese ganzen Diskussionen hinter uns gebracht haben, geht es wieder zurück an den Arbeitsplatz.

Zurück am Platz – endlich programmieren!

Endlich zurück am Platz, blinkert schon wie wild der Jabber-Client. Och Mensch, da braucht wieder jemand aus dem anderen Bereich Zuarbeit. Nun gut – nach fünf maligem fragen aufgrund von schwammiger Erklärun und mehrmaliger spontaner Abwesenheit des gegenüber nehme ich eben kurz den Telefonhörer in die Hand. Rufe ihn an. Die Sache ist in zwei Minuten geklärt. Endlich. Programmieren!

Also die IDE geöffnet, nochmal kurz mittels eines git pull die Arbeitskopie aktualisiert. Browser geöffnet, Refresh gedrückt. BAM. Error 500. Wer war’s? Natürlich keiner. Spitze. Also nun push-History nachschauen und einzeln prüfen, woher der Fehler kommt? Oder lieber gleich fixen? Ich entscheide mich für zweiteres. 20 Minuten später ist das Problem gelöst. Der Quellcode eingecheckt, alle anderen können wieder arbeiten. Es ist Mittagspause.

Zurück am Platz – endlich programmieren!

Nun beginnt der eigentlich spannende Teil des Tages: jetzt habe ich eine funktionierende Arbeitsumgebung. Alle Mails sind abgefrühstückt. Gegessen habe ich. Los geht’s!

Nach ungefähr 45 Minuten werde ich unterbrochen. Eine Projektmanagerin steht neben mir. Sie will den Stand des Features wissen. Ich sage ihr, dass ich heute wohl das gröbste schaffe und wenn nichts dazwischen kommt, werde ich das Feature morgen finalisieren und es an die Testabteilung geben. Das stellt sie soweit zufrieden. Sie verlässt das Büro. 10 Minuten später steht mein Scrum-Master neben mir und fragt nach, seit wann ich solche kurzfristigen Termine herausgebe. Verwirrt frage ich ihn, was er meint – die Projektmanagerin stand bei ihm am Tisch und wollte ein Release für morgen haben. Sie meinte, das Feature sei morgen fertig hätte ich gesagt. Nachdem ich ihm die Situation erklärt habe, wird er nun der Projektmanagerin den Wind aus den Segeln nehmen müssen. Ich programmiere weiter.

Mittlerweile bin ich tatsächlich zwei Stunden ungestört gewesen, als sich ein weiterer Kollege meldet. Er benötigt Hilfe. Wir setzen uns zusammen an seinen Platz und tauschen Wissen aus, begeben uns auf Fehlersuche. Die Zeit vergeht – wir finden den Fehler und können ihn eliminieren. Wir schreiben ein weiterführendes Ticket – unsere Hack-artige Lösung muss dringend durch etwas Hand- und Fußfestes ersetzt werden. Das Ticket wird wohl (so wie die 25 anderen der letzten 14 Tage) im Nirvana verschwinden.

Als ich wieder an meinem Arbeitsplatz sitze, pingt mich ein Kollege an – er macht für heute Feierabend, hat aber noch ein Ticket fertiggestellt. Ich solle mir seinen Quellcode anschauen und ein Code-Review anfertigen, damit die Tester morgen direkt mit den manuellen Tests starten können. Da das Code-Review Teil meiner Arbeit ist, verspreche ich ihm das Ganze heute noch durchzuziehen – er bedankt sich, wünscht einen schönen Feierabend. Ich wünsche das gleiche, beginne direkt mit dem Code-Review. Meine zwei kleinen Anmerkungen passe ich direkt selbst an, schiebe das Ticket auf coding finished und gebe es an die Testabteilung weiter. Per eMail benachrichtige ich meinen Kollegen noch darüber, dass ich zwei kleine Anpassungen durchgeführt habe – das Review sonst aber gut aussah. Aus der Bahn sendet er mir eine Antwort-eMail und bedankt sich.

Mittlerweile ist es Abend. Nach drei Stunden Programmierung und der sonstigen „Daily Routine“ verlasse ich das Büro. Geschafft habe ich wie immer gefühlt nichts, was in meiner Ticketliste stand. Zu tun hatte ich dennoch ordentlich. Morgen werde ich mir direkt meine großen Kopfhörer aufsetzen. Vielleicht bin ich dann ungestört und kann das Feature fertigstellen …

PHPStorm 2016.3 EAP und PHP 7.1.0 RC1

Eine kurze Nachricht zum Abend:

Seit heute gibt es die neue PHPStorm EAP 2016.3 – die Build-Nummer lautet 163.3512
Eine ausführliche Beschreibung aller neuen Features findet ihr auf der PHPStorm Seite. Dort findet ihr auch den Download sowie eine komplette Liste aller Änderungen aus dem YouTrack.

Außerdem wurde vor wenigen Stunden der PHP 7.1.0 RC1-Branch überarbeitet und in den Master überführt und ein Tag erstellt. Zu finden ist das Ganze auf dem GitHub-Account von PHP. Ebenso scheinen schon die ersten Änderungen für die RC2 eingearbeitet zu sein. Einen Tag davon gibt es jedoch noch nicht.

Da kann man nur happy Updating wünschen – bitte benutzt nichts davon produktiv!