Vor ein paar Tagen haben wir ein neues Feature am Empfehlungsbund freigeschaltet: Bewerbung und Lebenslaufgenerierung mit sozialen Netzwerken, namentlich Xing und Linkedin.

Dabei können sich Bewerber bei der Bewerbung auf Stellen aus ITsax.de, ITmitte.de, MINTsax.de, ... mit ihrem Xing/Linkedin-Profil bewerben. Nach Zustimmung generieren wir on-the-fly einen Lebenslauf und füllen das Bewerbungsformular mit den Stammdaten aus.

Das Ganze ist auch ohne eine Bewerbung möglich. Unter empfehlungsbund.de/cv kann mit einem Klick der eigene Lebenslauf angezeigt werden. (Dabei speichern wir ausdrücklich keinerlei Daten des Lebenslaufs – erst Recht nicht das PDF selbst).

Warum das Ganze?

Wer kennt das nicht? In der Bewerbungsphase ist man damit beschäftigt, seinen Lebenslauf auf den neusten Stand zu bringen, möglicherweise das Ganze noch bei XING/Linkedin zu hinterlegen und schlussendlich individuelle Anschreiben zu erstellen.

Immer mehr Leute haben einen exzellent gepflegte Profile auf XING/Linkedin. Warum also die Daten nur da lassen? Bevor man anfängt nun per Copy-und-Paste das Ganze in einen eigenen Lebenslauf zu gießen, wäre es da nicht schöner, nur mit einem Knopfdruck den Lebenslauf zu generieren? Wir denke ja, mal sehen was die Bewerber so denken :).

Umsetzung

Die Bewerbung wird durch den Empfehlungsbund, eine Ruby-on-Rails-Anwendung realisiert. Darum konnten wir die erstklassige Rails-Bibliothek Omniauth, mit xing und linkedin-Plugins, benutzen. Man muss den Plugins nur die anzufordernden Rechte und ggf. zu holende Daten mit übergeben:

# config/initializers/omniauth.rb
Rails.application.config.middleware.use OmniAuth::Builder do
  provider :linkedin, "apikey", "secret",
    scope: "r_basicprofile r_fullprofile r_contactinfo r_emailaddress",
    fields: %w[formatted-name associations certifications courses date-of-birth
      educations email-address honors twitter-accounts interests headline
      languages:(language,proficiency)
      volunteer:(volunteer-experiences:(role,organization,cause,description,start-date,end-date))
      main-address member-url-resources
      patents:(title,summary,date,url)
      phone-numbers picture-url positions
      publications:(title,date,summary,publisher,url)
      recommendations-received:(recommendation-type,recommendation-text,recommender:(formatted-name,headline,picture-url))
      public-profile-url skills specialties
      summary picture-urls::(original)
  ]
  provider :xing, "apikey", "secret"
end

Wie man oben sehen kann, muss man beim Linkedin-Plugin mit angeben, welche Felder man benötigt. Insbesondere volunteer und recommendations bedurfte einiger Try-and-error's, da die Dokumentation in einigen Stellen vage blieb.

Xing war da deutlich pflegeleichter, allerdings ist hier die Anmeldung einer App komplizierter, da sie bei XING einen Freischaltprozess inklusive Zusendung eines Tokens per Post beinhaltet.

Beide Plugins senden nun Ihre Daten an eine gemeinsame URL, in dem ein Adapter die verschiedenen Profilfelder in ein einheitliches Format übersetzt. Danach wird mithilfe von WickedPDF und wkhtmltopdf ein PDF generiert.

Ausblick

Dank Omniauth können natürlich auch weitere soziale Netzwerke angebunden werden. Wir hatten das Ganze auch für Facebook probiert. Allerdings gibt es (für Normalnutzer) keine Möglichkeit, die Telefonnummer oder Adresse aus der API abzufragen. Damit ist das Ganze für eine Bewerbung relativ witzlos.

Außer Linkedin und XING fielen uns auch keine (im deutschen Markt agierende) soziale Netzwerke ein, die genügend Daten für einen Lebenslauf erfassen. Vielleicht wird es in ferner Zukunft ja mal einen Weibo-CV geben ... :)

Unser Fazit

Insgesamt sind wir recht zufrieden mit dem aktuellen Lebenslauf-Export. Trotz stellenweise sehr unterschiedlichen Formaten wird ein einheitliches PDF generiert. Wenn man das Ganze während einer Bewerbung verwendet, so werden ebenfalls die Stammdaten ausgefüllt.

Jetzt bleibt nur abzuwarten, wie das Ganze bei Bewerbern und Personalern ankommt. Hauptziel ist natürlich eine Verbesserung der "Application-Experience" ;).

Im August sind wir in unser neues Büro in die Lohrmannstraße gezogen. Neue Technik, Server, Möbel und ein VDSL-Anschluss sind nun ideale Vorraussetzungen für eine Zusammenarbeit im Team.

Natürlich gab es dann auch einiges aufzubauen: Tische, Schränke, Stühle sowie natürlich - die Technik. Nagelneue Desktoprechner, Docking-Stations, 27 Zoll Monitore, Netzwerktechnik, NAS und ein neuer Server samt unterbrechungsfreier Stromversorgung ließen die Augen der gestandenen ITler höherschlagen.

Server und Netzwerk

Insbesondere für unseren IT'ler Martin war es eine Freude, den Server und die Netzwerkstruktur einzurichten. Einige individuelle Anforderungen haben das Ganze etwas herausfordernder gestaltet:

• Nutzerauthentifikation soll mit LDAP stattfinden
• Alle Homelaufwerke sollen auf dem NAS liegen, d.h. beim Anmelden wird das Home-Laufwerk der Nutzer on-the-fly gemountet
• Jeder Nutzer soll sich also prinzipiell an jedem der Computer anmelden können. Diese Virtualisierung der Arbeitsplätze ist ein wichtiger Punkt, da in unserem Team die Leute auch viel aus dem Home-Office arbeiten können bzw. Studenten nur Teilzeit im Büro sind.
• Während der ersten Wochen hatten wir noch kein (Festnetz)-Internet im Büro und mussten uns auf UMTS und Tethering beschränken. Das hat das Herunterladen von Linux-Distributionen und (Windows)-Updates extrem erschwert. Dafür haben wir uns dann ein lokales Ubuntu-Repository aufgebaut. Mitterweile liegt aber schon VDSL an, sodass das ganze kein Problem mehr ist.

Neben der Nutzerverwaltung sollte der Büroserver auch folgende Dienste übernehmen:

• Continuous Integration Server (virtualisiert) mit Jenkins
• zentrale Remote Desktop Installationen für verschiedene Windowsvarianten (XP mit IE6,7 z.B.) mit Virtualbox
• Source-Code-Management Server (Gitlab)
• Entwicklungsserver, an dem die Entwickler mit SSH/TMUX auch Remote Pairing betreiben können.
• Bugtracker (redmine)
• Jabber-Server und Chaträume (hubot darf hier natürlich nicht fehlen)

Einrichtung des Servers und der PCs im Multitasking-Betrieb

Nutzung

Wir Entwickler erhoffen uns von dem Büro eine bessere Zusammenarbeit und persönlichere Kommunikation. Nachwievor nutzen viele der Entwickler und Werkstudenten die Home-Office Angebote. Trotzdem treffen wir uns gerne im Büro, um dort über die neusten Weiterentwicklungen und anstehende Software-Designs zu beratschlagen. Insbesondere das Training der Praktikanten ist nun deutlich effektiver, als dies über Remote Pairing möglich war. Auch gemeinsame Mittagessen und Austausch über neuste Internet-Memes fehlen natürlich nicht :).

Netzwerkkabel, die es zu verbinden galt

Mit einem immer größer werdenden Team kommen neue Probleme auf:

• Tests werden nicht immer ausgeführt, weil grad “keine Zeit dafür ist”. Dann schlagen Tests mitunter fehl
• Interessante Code-Statistiken und Dokumentationen werden seltener generiert und werden so schneller out-of-date
• Trotz einer Versionsverwaltung gibt es ab und an Konflikte
• Jedes Teammitglied soll selbst deployen können. Dabei soll aber sichergestellt, das kein Stand eines anderen überschrieben wird.

Es muss also ein Continuous Integration (CI) Server her!
Die beste Wahl, wenn man nach einer erweiterbaren OpenSource self-Hosting Variante sucht, ist anscheinend Jenkins, das durch seine vielfältigen Plugins hervorsticht.

Unsere Hauptprojekte basieren auf Ruby bzw. Rails, d.h. es gibt keinen eigentlichen Build-Prozess. Allerdings möchten wir folgende Tasks automatisieren:

• Ausführung aller Tests, inkl. der langsamen Browsertests (System/Integrationstests)
• Generation von Code-Statistiken, Testabdeckung, Dokumentation
• Deployment im Erfolgsfall ins Livesystem mittels eines schon vorhandenen Capistrano-Skriptes

Das Ganze soll dann möglichst mittels Jabber steuerbar sein (Als Jabber-Server verwenden wir OpenFire).

Nach etwa 1.5 Arbeitstagen steht das Ganze nun. Wie wir da vorgegangen sind, möchte ich kurz skizzieren.

Installation

Auf einem Debian/Ubuntusystem muss lediglich die Paketquelle eingetragen werden, und dann kann das ganze über apt-get installiert werden. Die gesamte Prozedur haben wir hier beschrieben:

github.com/pludoni/railsTemplate

Dort wird auch gleich beschrieben, wie man Ruby mittels RVM installiert und alle anderen, möglicherweise notwendigen, Programme.

Konfiguration

Nach der Installation läuft Jenkins auf Port 8080 des Servers. Anfangs braucht man noch kein Login, welches man aber so schnell wie möglich unter Configuration/Security einrichten sollte.

Dann kann man auch schon Plugins über das Konfigurationsmenü installieren. Wenn anfangs die “Available Plugin”-Liste leer sein sollte, dann kann man im Tab “Advanced” unten rechts auf “Check Now” klicken.

Hier ein paar interessante Plugins

• Jenkins GIT plugin
• HTML Publisher plugin – damit lassen sich sehr leicht komplette generierte html-Ordner speichern und archivieren für die es kein eigenes Plugin gibt, z.B. für simple-cov, yarddoc, Rails-Best-Practices Ergebnisse
• Jenkins Jabber notifier plugin – Damit erscheint ein Jabber Bot in einem Konferenzraum unserer Wahl, der auf Knopfdruck Builds starten kann
  • Jenkins instant-messaging plugin – Vorbedingung für Jabber Plugin
  • Nach der Installation unter Configure noch die Zugangsdaten zum Jabberaccount, sowie den Konferenzraum, angeben
• Green Balls – erfolgreiche Builds werden bei Jenkins “blau” dargestellt. Damit werden sie “Grün”, was für uns intuitiver ist.
• Simple Theme Plugin – hiermit kann man ein eigenes css/js angeben und so das Styling von Jenkins verbessern
  • Ein guter Platz für das CSS ist der userContent-Ordner im Jenkins Homeverzeichnis (/var/lib/jenkins/userContent), der automatisch von außen erreichbar ist
  • Unser aktuelles Theme ist hier verfügbar
• AnsiColor – Damit werden farbige Konsolenausgaben ebenfalls farbig im Interface dargestellt (rspec, capistrano-colors)
• Brakeman Plugin – sammelt Statistiken über potenzielle Sicherheitsprobleme der Rails Anwendung mittels des brakeman Gems
• Jenkins ruby metrics plugin – Leider etwas veraltet und nicht mehr sinnvoll mit Ruby 1.9 nutzbar. Allerdings kann mit etwas Anpassung das Plugin benutzt werden, um Test Coverage Statistiken zu sammeln und bei Unterschreitung eines gewissen Prozentsatzes zu warnen sowie um einige Standard-Code-Statistiken darzustellen (LOCs, methods per class etc)
• Rvm – Ruby Version Manager
• Jenkins Wall Display Master Project – Eine Spezielle, Wall-Monitor optimierte Ansicht, die sehr visuell darstellt, ob Tests aller Projekte noch erfolgreich sind

Konfiguration der Rails Anwendung

Um die diversen Statistiken zu generieren, sind auch auf der Railsseite einige Anpassungen notwendig. Diese sind unter https://github.com/pludoni/railsTemplate#necessary-gems aufgeführt.

Installation des Rails-Templates

Das fertige Railstemplate kann nun in den Jenkins-Ordner kopiert nach /var/lib/jenkins/jobs/RailsTemplate/config.xml.

Danach kann dieses “Projekt” als Basis für einen neuen Job im Jenkins gewählt werden. Dann sind nur noch wenige Anpassungen notwendig:

• Git Pfad, RVM Version
• Jabber Raum

Zusammenfassender Ablauf des Build Prozesses

1. Jenkins checkt den letzten Stand des master-Branches aus dem Git-Repository aus
2. Wir bereiten Rails vor, mittels: bundle install, rake db:migrate, rake db:test:prepare
3. Specs werden mittels des CI-Reporters ausgeführt. Dieser generiert xml-Files, die Jenkins verwenden kann. Dadurch erhalten wir direkt im Jenkins eine detailierte Übersicht über fehlgeschlagene Tests
   1. Gleichzeitig läuft SimpleCov mit und generiert – neben dem HTML – auch Ergebnisse im RCov-Format. Dieses Format kann später das RCov Plugin verwenden
4. yarddoc generiert die aktuellste Dokumentation
5. brakeman generiert Sicherheitstipps zur Anwendung
6. Rails-Best-Practices generiert Informationen zur Code-Qualität und Verbesserungsvorschläge
7. cap deploy wird ausgeführt, und so der letzte Stand auf den Live-Server gepackt
8. Die verschiedenen Publisher sammeln die Ergebnisse ein
9. Der Bot meldet den Erfolg an den Chat

Das ganze kann aus dem Chat mittels “!build Empfehlungsbund” angestoßen werden.

Damit haben wir nun einen Build-Prozess, mit dem wir sehr zufrieden sind. Wir werden in nächster Zeit alle wichtigen Projekte darauf umstellen.

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: