Dank moderner Kommunikationsmittel ist eine ICE-Fahrt heutzutage kein Grund mehr mit der Arbeit aufzuhören :). Insbesondere falls es Probleme am Server gibt, ist es wünschenswert, auf SSH-Ebene mit den Servern stabil zu kommunizieren.

Leider führt eine solche Fahrt auch mal durch ländliches Gebiet ohne gute Netzabdeckung, und eine stabile SSH-Verbindung ist dann nicht gegeben. Als Ergebnis friert die Shell ein, und man muss eine neue aufmachen. Ärgerlich, wenn man die soeben geöffnete Datei noch nicht gespeichert hat.

Allerdings gibt es da einige Tipps, die auf unixoiden Betriebssystemen (Linux, MacOS) leicht umzusetzen sind. Zum einen gibt es eine Einstellung in der SSH-Verbindung und zum anderen einige Punkte in der Arbeitsweise, die man beachten kann, um so trotzdem sinnvoll zu arbeiten.

Einstellungen

Falls man noch keine ssh-Konfigurationsdatei hat, so kann man diese in seinem Homeverzeichnis unter ~/.ssh/config anlegen. Eine Konfiguration sieht z.B. so aus:

Host pl
  User xxxx
  Hostname pludoni.de
  ServerAliveInterval 60

Setzt z.B. einen Alias “pl” für den angegeben Nutzer zum Server. Wichtig ist die letzte Option. Sollte nun unser SSH-Client die Verbindung verlieren, so probiert er in 60 Sekunden einen Reconnect. Aufrufen dieser Einstellung und verbinden können wir uns dann mittels ssh pl.

Arbeitsweise

Um bei einem Verlust der Verbindung die noch nicht gespeicherten Daten zu behalten, sollte man einen Terminal Multiplexer, wie screen, oder besser tmux verwenden. Diese ermöglichen es, die Shell von der aktuellen Verbindung zu entkoppeln. Zusätzlich ermöglichen beide auch ein simultanes Login mehrer Nutzer und TMUX ist damit eines der Standardtools beim Remote Pair Programming.
Nach einer gewissen Einarbeitungszeit gewöhnt man sich daran nach dem Login auf dem Server immer eine tmux-Sitzung zu öffnen, bzw. fortzusetzen. Da die Tmux Konfiguration leider nicht immer ganz einfach ist, gibt es z.B. den sehr eleganten Wrapper tmuxinator dafür.

Falls man nun beim Arbeiten mit Tmux einen Verbindungsabbruch erlebt, kann man nach einem Relogin sofort mittels “attach” die Sitzung fortsetzen.

Falls die SHH-Verbindung einfriert, kann man sich mittels spezieller Tastenkombinationen befreien: <Enter> ~. <Enter> beendet z.B. die aktuelle Sitzung.

(geschrieben aus einem ICE)

Webanwendungen sind Software, und damit prinzipbedingt fehlerbehaftet. Wenn nun ein Fehler bei einem Nutzer bzw. Kunden auftritt, wäre es wünschenswert, wenn wir als Entwickler zumindest davon erfahren. Für unsere Ruby on Rails-Anwendungen (z.B. Empfehlungsbund.de) nutzen wir seit einiger Zeit den Service von Airbrake, die ein leicht zu installierendes Plugin anbieten. Nun suchten wir für PHP etwas ähnliches. Da wir aber mittlerweile sehr viele PHP-Anwendungen hatten, kam die Motivation auf:

• Ähnliches auch für PHP umzusetzen
• die Fehler an unser eigenes System zu melden, um unabhängig von externen Dienstleistern zu sein.
• Das Ganze in einen Workflow zu bringen, sodass Fehler nicht vergessen werden

Nutzung von Redmine als Bug-API-Server

Intern nutzen wir bereits den Bugtracker Redmine (der übrigens auch auf Ruby on Rails basiert), der uns durch die vielen Features, inklusive z.B. einer Zeiterfassung, einer API zum automatischen Anlegen von Tickets und Android Apps (RedMinerDroid) überzeugt hat.

Glücklicherweise gibt es bereits ein Plugin für Redmine – Redmine Airbrake Server, dass aus dem Bugtracker auch einen Airbrake-Bug-Server macht. Letztendlich sieht es so aus, dass ein Fehler ein Ticket im Bugtracker erzeugt, bzw. ein bestehendes aktualisiert, wenn ein Fehler wieder aufgetreten ist. Das ganze funktioniert sehr gut, auch wenn man natürlich Abstriche beim Informationsgehalt und der Aufbereitung machen muss, der bei kommerziellen Services wie Airbrake oder Newrelic natürlich besser ist. Nichtsdestotrotz bleibt man über den Status der Anwendung auf dem Laufenden, und erhält die notwendigen Informationen (Stacktrace, Fehlerdokument, URL und Session-Parameter)

Umbau der Client-Bibliotheken

Da dieses Plugin die Airbrake-API emuliert, lassen sich die dafür geeigneten Plugins meist relativ leicht so umbauen, dass sie nun stattdessen zum Bugtracker funken. Für das Rails-Plugin ist dies bereits auf der Githubseite des Airbrake Redmine Plugins dokumentiert. Für PHP haben wir das so gelöst:

• Download der Airbrake-Notifer-PHP-Bibliothek
• ca. Zeile 190 in der Services/Airbrake.php die URL anpassen:

$url = "http://mybugtracker.domain.de/notifier_api/v2/notices";

• an geeigneter Stelle im Programmcode (z.B. neues Modul, Klasse etc.) wiefolgt aufrufen:

require_once ‘php-airbrake-notifier/Services/Airbrake.php’;
$api_key = <<<DOC
—-
:project: bugs
:tracker: Fehler
:api_key:            # Hier den E-Mail API Key aus dem Redmine
:assigned_to: admin  # Nutzer an den das zugewiesen wird
:login: api          # Nutzer, von dem das Ticket kommt
:reopen_strategy: production
DOC;
Services_Airbrake::installHandlers($api_key, ‘production’, ‘curl’);

Fertig :) Ab nun trudeln alle Mails als Tickets ein. Wenn Redmine richtig konfiguriert ist, dann bekommen alle Projektbeobachter Mails, sobald neue Tickets angelegt werden, bzw. Fehler auftraten.

Im letzten Jahr schrieb ich meine Diplomarbeit bei der pludoni GmbH. Dabei stand die Entwicklungsmethode "Testgetriebene Softwareentwicklung (TDD)" im Vordergrund und wurde auf die Tauglichkeit zum Einsatz in der Firma untersucht. Insbesondere hatten wir die Vermutung, dass sie eine effektive Möglichkeit zur Steigerung unserer (internen) Qualität, d.h. der Code-Qualität und langfristig effizientere Entwicklung sei.

Ergebnisse

Im Rahmen der Arbeit habe ich einen Prototypen eines Stellenportals in Ruby on Rails (3) testgetrieben entwickelt. Am Ende stellten wir dann fest, dass die qualitativen Kennzahlen, z.B. Komplexität, Anzahl der Codesmells, Testabdeckung deutlich gegenüber früheren Rails-Projekten verbessert wurden.

Ein Großteil der Arbeit konnte in das neue, gemeinsame Portal Empfehlungsbund.de übernommen werden und befindet sich damit in Produktion. Somit war die Arbeit ein Erfolg. Dem stimmten auch meine Prüfer zu :).

Details sind in der Arbeit zu finden: current.pdf.

Als Literatur zu empfehlen sind die Bücher:

• Test-Driven-Development by example, von Kent Beck,
• Rails Test Prescription, von Noel Rappin,
• RSpec Book, von David Chelimsky,
• Agile Book, James Shore, das sogar größtenteils online verfügbar ist.

sowie zahlloser, exzellenter Internetquellen.

Ausblick

Durch die prototypische Entwicklung konnten wir viel Wissen über verschiedene Testmethoden, insb. Rails, Cucumber, Selenium und Capybara, aber auch über unterschiedliche Rubygems und 3rd-Party-Librarys (thinking Sphinx, Geo-Suche, Javascript, Rails 3.1) in die Firma bringen.

Nach der Arbeit und damit dem Ende meines Studiums habe ich nun meine Vollzeittätigkeit bei der pludoni GmbH als Entwickler begonnen.

Florian stieß vor kurzem zu uns, mit einem konkreten Redesign-Vorschlag für unsere Communityportale. Damit hat er uns so beeindruckt, dass er sofort die Stelle als Designer bekam.

Er wird hinter den Kulissen eine komplett neue Nutzerschnittstelle ausarbeiten und zusammen mit dem Entwicklerteam implementieren. Außerdem schätzen wir seine vielen, kreativen Ideen und den frischen Wind, den der ins Team bringt!

Im Rahmen meiner Bachelorarbeit konnte ich mich ausführlich mit den aktuell gängigen Web-Performance Problemen beschäftigen.

Thema war: Leistungsuntersuchung von Webserveranwendungen und Optimierung auf Basis von Drupal 5(am Beispiel von ITsax.de)

Dabei konnte ich vielfältige Erkenntnisse gewinnen und unsere Webseiten erheblich beschleunigen. Das Ziel war es, die Usability zu verbessern und natürlich eine angenehme User-Experience zu ermöglichen. Ein positiver Nebeneffekt ist, dass seit 2010 die Webseitengeschwindigkeit Einfluss auf das Google Ranking hat.

Die wichtigsten Erfahrungen waren:

• Das Messen von Internetseiten ist nicht trivial. Genutzt wurde am Ende WebPageTest, welches sich als sehr effektiv herausstellte.
• Der Internetausbau ist in Deutschland leider noch nicht so rosig wie die Politik es gern hätte, daher muss auf die übertragene Datenmengen geachtet werden!
• Wenn Drupal beschleunigt werden soll, gibt es nur ein credo: Caching wo es nur geht!
• Aktuelle Techniken zur Reduzierung der Anzahl an HTTP-Anfragen verwenden(JS-,CSS-Aggregation, CSS-Sprites...).
• Bilder optimieren mit Programmen wie OptiPNG und JpegOptim, sowie das richtige Format wählen.
• Unwichtige oder ressourcenintensive Inhalte dereferenzieren, d.h. mit Ajax nachladen.

So konnte ich die Webseitenladezeiten um ca. 60% verbessern und ich denke, dass es in Zukunft weitere spannende Projekte in dem Bereich Performance geben wird.

Wenn Sie sich ein Bild dieser Maßnahmen machen wollen, besuchen sie einfach unsere Communitys :)

Kürzlich kam das Problem auf, von bestimmten Websites automatisiert auf einem Server Bildschirmfotos anzufertigen. Die Gründe dafür sind vielfältig:

• Effiziente Vorbereitung für Tests einer gesamten Website
• Vorschau-Bilder für hinterlegte Links erstellen (wie bei Facebook oder Google+ bekannt)
• Screenshots von Social-Plugins (Facebook etc), um datenschutzkonform zu werden. Der User bekommt nur ein Bild vom Social-Plugin angezeigt, es wird keine Anfrage zum Server ausgeführt, und damit ist man datenschutzrechtlich auf der sicheren Seite. Alle Hinweise im Disclaimer sind eigentlich zu spät (http://dejure.org/gesetze/TMG/13.html)

Eine bekannte Methode wäre, Firefox und einen X-Server zu installieren, um dann einen Screenshot des Desktops zu machen. Allerdings empfand ich diese Methode als unkomfortabel und instabil, weshalb ich mich nach einer anderen umsah.

Gefunden habe ich Webkit2png, ein in Python geschriebenes Skript zum automatisierten Aufruf des Webkit-Browsers, der bekanntermaßen der Unterbau des Google Chrome und Apple Safaris ist. Neben ein paar Installationsschwierigkeiten läuft das ganze nun aber ausgezeichnet, wenn auch etwas langsam.

Installation

Die Installation kurz beschrieben (für ein Debian-basiertes System)

apt-get install python-qt4 libqt4-webkit git-core xvfb
git clone https://github.com/AdamN/python-webkit2png
cd python-webkit2png

Das Tool kann nun von der Kommandozeile wie folgt gestartet werden:

./webkit2png.py -x 1024 768 -g 0 0 URL > AUSGABE.png

Die Parameter 1024 768 beziehen sich auf die Größe des simulierten Graphikservers. Die Zahlen "-g 0 0" beziffern die Höhe und Breite des Browser-Fensters. "0" bedeutet hier Auto.

Micro Webservice mit PHP

Nun will man das ganze vielleicht noch mit einem PHP-Skript einwickeln, um es einfach abzurufen zu machen.

• Man muss die Datei webkit2png.py in ein Verzeichnis mit dem zu schreibendem Skript legen
• Die Datei "webkit2png.log" muss für den Webserver schreibbar sein:
  

  touch webkit2png.log
  chown www-data webkit2png.log
  

• Nun kann das PHP Skript erstellt werden:

  <?php
    if ($_GET["url"]) {
      $width = (int)$_GET["width"];
      $height = (int)$_GET["height"];
      $url = escapeshellarg($_GET["url"]);
      $cmd = "./webkit2png.py -x 1450 768 -g $width $height $url 2>&1";
      header('Content-Type: image/png');
      passthru($cmd);
  } else {  ?>
    <h2>Nutzung</h2>
    <form method="get">
     URL: <input type='text' name='url'/><br/>
     Breite des Browser Frames (0 = Auto): <input type='text' name='width' value='0'/><br/>
     Hoehe des Browser Frames (0 = Auto): <input type='text' name='width' value='0'/><br/>
     <input type='submit'/>
     Be patient, may take a while :)
    </form>
  <?php } ?>
  

Voila, ein einfach anzusprechender Webservice, der uns Screenshots generiert und direkt anzeigt.

Früh aufstehen hieß es am Liveschaltungstag von MINTsax.de. Ich hatte noch Glück und wurde "erst" um 8 abgeholt. Stefan, Kristof und v.a. Jörg mussten da etwas früher ran. Aber schließlich mussten wir auch schon um 9 Uhr bei der 3D Micromac in Chemnitz sein.
Angekommen waren wir erst einmal damit beschäftigt, die Fertigungshalle im MINTsax.de Style zu verschönern. Kristof positionierte seine Kamera. Und das nicht nur einmal...
Allmählich füllte sich dann auch der Veranstaltungsort mit Vertretern der Presse und natürlich mit den Gründerpartnern von MINTsax.de. Nach der offiziellen Eröffnung mit einigen Worten von Jörg und den Vertretern der Partner hatten die Journalisten die Möglichkeit Fragen zu stellen und zu filmen. Sehr interessant war es, dem Sachsenspiegel beim Filmen zu beobachten...

Ich hatte die Ehre, an diesem Tag den Paparazzi spielen zu dürfen. Hier ein paar Backstage Bilder:

3D Film mit zwei Kameras auf einem Spezialstativ. Erinnerte mich ein bisschen an "Nummer 5 lebt" oder "Wally". Wir hatten Glück. In Bautzen und Dresden sonniges Wetter. Pech hatten wir mit etwa 7 Catering-Fahrern. Deren schöne Autos wollten nicht so richtig ins Bild passen. Kaum war einer Weg, kam der nächste, der sich vor den zu filmenden Eingang stellte. Natürlich hatte der keine Zeit und somit auch kein Verständnis irgendwo anders zu parken. Das warten hat sich aber gelohnt - die Sonne kam raus und machte das Scenario noch schöner.

Wir drehten zwei Tage bei der Bautzen IT.Group in Bautzen und bei der Salt Solutions in Dresden, das Erklärvideo zum ITsax.de-Prinzip. Dieses wird im Rahmen des Mitschnitt-Festivals der HTW-Dresden im Juli im 3D-Kino Ufa-Palast in Dresden gezeigt. Mehr unter http://www2.htw-dresden.de/mitschnitt/.

Um einen groben Überblick über die Codequalität zu erhalten, verwenden wir den PHP Messdetector. Dieser lässt sich per PHP PEAR recht leicht installieren, wie hier beschrieben.

Von der Kommandozeile lässt sich dieser nun recht leicht ausführen (Hier am Beispiel des Usermoduls von Drupal 5). Als erstes die Länge des Codes ("codesize")


// USAGE: phpmd files (text|xml|html) (unused|codesize|design|naming)
# phpmd modules/user/user.module text codesize
modules/user/user.module:141 The function user_load() has a Cyclomatic Complexity of 10.
modules/user/user.module:210 The function user_save() has a Cyclomatic Complexity of 54.
modules/user/user.module:210 The function user_save() has an NPath complexity of 164166.
modules/user/user.module:210 Avoid really long methods.
modules/user/user.module:617 The function user_user() has a Cyclomatic Complexity of 13.
modules/user/user.module:690 Avoid really long methods.


Hieran sieht man schön, dass die user_save Funktion alles andere als leicht wartbarer Code ist. Die Cyclomatischen Komplexität von 11, also der Anzahl an möglichen Entscheidungspunkten (if, while, for) innerhalb dieser Funktion ist eindeutig zu hoch.

Neben "codesize" gibt es noch "design", "naming" und "unused" innerhalb des Standard-Regelsatzes. Diese sind auf der PHPMD-Seite sehr gut beschrieben.

Die Tests können natürlich keine exakte Aussage machen, ob die Qualität des Codes nun "gut" oder "schlecht" ist, aber sie geben einen sehr guten Anhaltspunkt für mögliche Refaktorisierungen.

Vor kurzem ist Martin zu uns gestoßen. Er wird Akos und Stefan beim Weiterentwickeln der pludoni Produktpalette unterstützen.
Martin studiert Informatik in Dresden und wird sein Praktikum und Bachelorarbeit bei uns absolvieren. Er hat Erfahrung mit PHP und dem Dojo-Framework und ist begeistert von den bisherigen Ruby-on-Rails-Entwicklungen in der Firma.

Wir sind alle sehr gespannt, welche neuen Impulse er dem Team geben wird!