Im Entwickler-Blog bloggen Mitarbeiter und Entwickler über gewonnene Erkenntnisse oder technischen Problemen bei der Umsetzung interessanter technischer Features.

Bei pludoni habe ich eine schöne und lernintensive Zeit verbracht

Foto von martins

Nach mehr als 1000 Tagen bei der pludoni GmbH ist nun für mich, mit dem Ende meines Studiums, die Zeit gekommen Abschied zu nehmen.
Mit diesem Blogbeitrag möchte ich die Zeit bei pludoni noch einmal Revue passieren lassen.

Im vierten Semester meines Bachelorstudiums ging es daran ein Praktikum, sowie eventuell ein Unternehmen zu finden, bei dem ich die Bachelorarbeit schreiben könnte.
Nachdem ich mich bei einigen großen Dresdner Unternehmen vorgestellt und mich bei keinem richtig wohlgefühlt hatte, wurde ich bei pludoni auf einer bequemen Couch bei einer Tasse chinesischem Tee empfangen.

Damit begann für mich eine aufregende Zeit mit allem was die Softwareentwicklung zu bieten hat.

Angefangen habe ich mit der Einarbeitung in Drupal 5 und die Entwicklung von eigenen Modulen. Das erste größere Modul war der Newsroom, wie er hier in Aktion zu sehen ist:
http://www.itsax.de/newsroom

Als die Bachelorarbeit näher rückte, konnte ich mir ein Thema aussuchen und entschied mich für eine Performanceanalyse der Portalstartseite, da diese die meisten Zugriffe zu diesem Zeitpunkt hatte.
Das Thema der Arbeit war: "Leistungsuntersuchung von Webserveranwendungen und Optimierung auf Basis von Drupal 5 (am Beispiel von ITsax.de)" und ich konnte es insgesamt mit der Note 1,1 abschließen.

Im Anschluss habe ich weiterhin als Werkstudent für pludoni gearbeitet und wir haben in einem kleinen Team aus den einzelnen getrennten Communityportalen, wie z.b. www.itsax.de und www.itmitte.de, ein komplexes System entwickelt, um den Ansprüchen des Communitywachstums gerecht zu werden.
Um dieses Wachstum zu ermöglichen, wurde von Grund auf eine neue Schaltzentrale entwickelt: der www.empfehlungsbund.de.
Vorher musste jedes Portal einzeln administriert werden und der Wartungsaufwand stieg mit jedem zusätzlichen Portal stetig an.
Die Zentralisierung ermöglicht es nun einfach neue Portale auszurollen und bietet einen zentralen Anlaufpunkt für die Communitymitglieder.

Mit diesem Projekt begann für mich und die ganze Firma die Arbeit mit Ruby on Rails. Innerhalb kurzer Zeit und mit einem Pilotprojekt haben wir uns einen Überblick über Rails verschafft und dann angefangen den empfehlungsbund zu entwickeln.

Wir haben uns mit der Zeit von Test Driven Development über Deployment bis hin zu Continous Integration alle wichtigen Abläufe angeeignet und müssen uns beim Joel Test nicht vor Firmen mit mehr Ressourcen verstecken.

Dann kam das neue Büro und ich habe mich in die Administration der Ubuntu-Umgebung gestürzt und so ein OpenSource Umfeld für die Mitarbeiter geschaffen.
Gleichzeitig wurde für das Büro ein Developmentserver angeschafft, auf dem jetzt die Entwicklung stattfindet.

Zusätzlich habe ich mit Phonegap und jQuery Mobile eine App, sowie die mobile Version des Empfehlungsbundes in einer ersten Version erstellt.
Die Empfehlungsbund App wurde mittlerweile schon über 500 mal heruntergeladen und liefert erste Einblicke in das harte Geschäft der App-Entwicklung und Vermarktung.

Da die Communitys mit der Zeit immer mehr wurden, habe ich als Nebenprojekt noch an einem Community-Event Managementsystem gearbeitet, welches die Planung der Communitytrainings und Open-Network-Events vereinfacht und beschleunigt. So können zum Beispiel automatisch Einladungen verschickt werden und die Teilnehmerlisten werden vollautomatisch generiert.

Anfang 2013 wurde dann www.faire-karriere.de freigeschaltet, welches nun mein letztes Projekt bei pludoni wurde.
Bei www.faire-karriere.de handelt es sich um eine Bewertungs- und Feedbackplattform für Mitarbeiter, Geschäftskontakte und Bewerber.
Die Besonderheit ist, dass sich die teilnehmenden Arbeitgeber verpflichten, aktiv am Freischaltungsprozess von Bewertungen teilzunehmen, um so den kostenfreien Betrieb zu ermöglichen.

Die letzten Monate habe ich meiner Masterarbeit zum Thema "Evaluierung und prototypische Implementation einer Volltextsuche für Stellenanzeigen unter Berücksichtigung von Toleranzen und Relevanz der Suchanfragen" gewidmet, die ich ebenfalls bei pludoni schreiben konnte.
Genauer gesagt handelt es sich um eine Umstrukturierung der kompletten Suchfunktion sowie eine Zusammenführung der existierenden Suchlösungen.
Dabei wurde auf Basis von elasticsearch ein neues Suchmodell für Stellenanzeigen entwickelt, was es der Firma ermöglicht, eine nachvollziehbare und dennoch mächtige Suche anzubieten.
Neue Features sind zum Beispiel eine Rechtschreibkorrektur während der Suche, Operatoren um die Suche den eigenen Wünschen anzupassen sowie ein ausgefeiltes Sternebewertungssystem.

Damit geht eine spannende und aufregende Zeit zu Ende und ich mache mich auf zu neuen Abenteuern in der Bundeshauptstadt.

Ich möchte dem pludoni Team, für die tolle Zusammenarbeit während und außerhalb der Arbeitszeiten, ein herzliches Dankeschön aussprechen und werde natürlich noch eine Runde Kuchen vorbei bringen :).
Martin Schneider

Mein Schülerbetriebspraktikum bei der pludoni GmbH

Mein Name ist Vincent Thelang und ich habe in den letzten 2 Wochen mein Schülerbetriebspraktikum bei der pludoni GmbH in Dresden Reick in dem Bereich Webentwicklung durchgeführt.

Ich habe aktiv an dem neuen Projekt „Faire-Karriere“ mitgearbeitet und mitentwickelt.
Folgende Tools habe ich in den 2 Wochen für das Projekt programmiert:

  • Einen Captcha zum Schutz vor Spam und Bots
  • Ein Blog der als Gem auch in anderen Projekten verwendet werden kann.
    • Ein Editor mit integriertem Bilder-Upload damit der Blogger nicht mehr ein Bild auf den FTP hochladen muss
    • Mit dem Twitter Bootstrap Framework
    • der Blog unterstützt auch Tagging und hat auch Teaser Texte.
  • Ich habe auch noch ein Mail Skript programmiert zum Benachrichtigen der Kunden
    • dieses schickt via Cronjob an all die Nutzer, wo sich etwas am Profil geändert hat automatisch eine Mail
    • es wird auch eine History angelegt das ein Kunde nicht jeden Tag eine Mail bekommt
    • Dies kann natürlich auch in dem Profil des Nutzers eingestellt werden und auch wer eine E-Mail bekommt

In den 2 Wochen habe ich sehr viel zu meinen Programmierkenntnissen mit Ruby on Rails dazu gelernt unter andern auch:

  • JavaScript
    • CoffeeScript
    • JQuery
  • Haml (HTML)
  • Postgre SQL
    • Joins
    • Group
    • etc.
  • Bash
  • Reguläre Ausdrücke

Besonders interessiert hat mich das Testgetriebene Entwickeln, da ich dies noch nicht zum Programmieren von Webanwendungen benutzt habe. Ich hatte auch die Möglichkeit zusammen mit Stefan Wienert ein Open Source Projekt zu verbessern: Simple Captcha.

Ich habe in den letzten 2 Wochen auch mit der Versionsverwaltung Git gearbeitet welche ich in dem Umfang noch nicht benutzt habe.

Zu dem war das ganze Betriebspraktikum eine neue Erfahrung für mich gegenüber des Schulalttags und dem herkömmlichen Informatik Unterricht.

Ich würde das Praktikum jedem empfehlen der sich schon mal mit der Webentwicklung auseinander gesetzt hat und schon Erfahrung mit Programmiersprachen gesammelt hat.

Bewerbung mit XING / Linkedin Lebenslauf

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" ;).

Umzug ins neue Büro

Foto von stefanw

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

Jenkins CI-Server mit Rails, Capistrano deployment und Tonnen von Statistik

Foto von stefanw

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.

Stabile SSH-Verbindung von unterwegs

Foto von stefanw

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)

Frameworkunabhängige Fehlerberichtung mit PHP und Redmine

Foto von stefanw

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:

$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.

Code-Qualität durch Testgetriebene Entwicklung nachhaltig erhöhen

Foto von stefanw

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.

Wir begrüßen unseren neuen Werkstudenten-Web-Designer: Florian

Foto von stefanw

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!

Auf der Überholspur

Foto von martins

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 :)