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.

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!

Continuous Integration

Continuous Integration – das Wort kommt einem bereits seit einiger Zeit sehr oft zu Ohren. Doch was ist das eigentlich? Für was braucht man das? Und wieso finden das eigentlich so viele Leute toll?

Continuous Integration? Continuous Delivery und Deployment?

Generell ist Continuous Integration (viele kürzen es mit „CI“ ab) sehr nah am Thema Continuous Delivery und Continuous Deployment. Aus diesem Grund, möchte ich im folgenden Text kurz die drei Begriffe voneinander differenzieren:

  • Continuous Integration: beschreibt das kontinuierliche Zusammensetzen und testen der Quellcodebasis in einem automatisierten Prozess
  • Continuous Delivery: ist die Weiterentwicklung der Continuous Integration und beschreibt den ständig deploybaren Zustand einer Software, es liegt also ständig eine verteilbare Version der Software vor
  • Continuous Deployment: ist der letzte logische Schritt dieser Kette und besagt, dass die kontinuierlich integrierte Version der Software (welche nun auch zu jeder Zeit deploybar ist) mit jedem neuen (und funktionierendem Build) automatisiert verteilt wird

Warum das Ganze?

Da wir nun wissen, was Continuous Integration ist fragen wir uns sicher: warum betreibt man so einen Aufwand, ständig releasebare Software zu haben? Man baut doch erst ein Feature zu Ende, testet das und schiebt es dann zur Marktreife ab in’s Deployment.

Nun, hier muss man die Brücke zum Thema „Agile Softwareentwicklung“ schlagen. Da man bestrebt ist vollzogene Änderungen möglichst schnell und zeitnah an den Kunden ausspielen zu können, müssen Fehler möglichst Ressourcenschonend und schnell erkannt werden. Hierbei hilft natürlich eine CI-Pipeline, welche direkt zum Zeitpunkt des pushens von Quellcode die Applikation neu baut und mittels automatischen Tests bereits prüft.

Ebenso ist es natürlich im Sinne agiler Software (auch wenn wir ein wenig vom Thema Continuous Integration abschweifen, so ist es doch ein gutes Hilfsmittel der agilen Softwareentwicklung), das Produkt möglichst schnell am Kunden ausprobieren zu können. Hierfür muss gewährleistet sein, dass das Produkt ständig funktioniert und im optimalen Fall auch ständig ausgespielt werden kann. Ein Feature, welches nicht performt, muss entweder angepasst werden – damit es funktionieren kann – oder es sollte frühzeitig eingestampft werden wenn es kein Geld bringt.

Umso komplexer natürlich der Quellcode beim „verheiraten“ der Entwicklung ist, umso fehleranfälliger wird das Ganze. Ein frühzeitiges, ständiges integrieren und testen der entwickelten Teile des Softwaresystems bringen also einen großen Vorteil mit sich – da durch das ständige Zusammenführen stärker eingegrenzt werden kann, was die mögliche Fehlerquelle ist.

Welche Software bildet das alles ab?

Es gibt so einige Tools, welche zur Unterstützung eines CI-Prozesses verwendet werden können. Die zwei bekanntesten hierfür dürften Travis-CI und Jenkins sein.

Jenkins ging damals aus dem Hudson-Projekt hervor und ist seit jeher ein sehr flexibles und anpassbares Tool zum Umsetzen von CI-Pipelines. Ebenso bekannt ist Travis-CI. Dieses verfügt über eine direkte Anbindung an GitHub und liefert hier (durch das einchecken einer .travis-ci.yml-Datei) eine hohe Flexibilität durch direkt im Repository befindliche Taskbeschreibungen.

Die Ansätze hierbei sind sehr verschieden. Während man für Jenkins direkt die auszuführenden Tasks im Jenkins selbst konfiguriert, geht Travis-CI den umgekehrten Weg. Die Tasks werden hier direkt im Repositry beschrieben. Anmerkung: es gibt auch für Jenkins ein Plugin, welches den Travis-CI-Weg zur Verfügung stellt.

Vermutlich etwas weniger bekannt dürfte Gitlab-CI sein. Gitlab ist eine hochintegrierte Umgebung, welche ein Git Repository und ein Continuous Integration System ineinander vereint. In meinen Augen sind alle drei Tools gelungen – wenngleich Gitlab-CI und Travis-CI ein wenig die Nase vorn haben, da sie ohne weiteren Extra-Konfigurationsaufwand „Out of the Box“ mit ihren Quellcodemanagementsystemen verzahnt sind.

Links:

  • https://gitlab.com
  • https://jenkins.io
  • https://travis-ci.com