Open-Source-Technologien bei pludoni

Bei der Software-Entwicklung in unserer Firma setzen wir auf verschiedene Open-Source Sprachen, Bibliotheken, Frameworks und Bibliotheken. Einige dieser exzellenten Tools möchte ich hier mal vorstellen und unsere Beweggründe für die Wahl anführen.

Softwareentwicklung

Alle Websites basieren inzwischen auf dem Webframework Ruby on Rails. Seit 2011 haben wir nach und nach alle neuen Produkte damit entwickelt und noch in 2014 die Alt-Reste Drupal 5/6 abgeschaltet und durch Ruby on Rails ersetzt. Dadurch, dass alle Projekte relativ homogen aufgebaut sind und Rails eine feste Struktur vorgibt, ist es leichter für Entwickler in Projekte einzusteigen. Zudem hat Rails inzwischen 10 Jahre auf dem Buckel, die Pfade sind also ausgetreten, gut dokumentiert und das Ganze sehr stabil, aber zugleich ist die Entwicklung damit nachwievor äußerst produktiv. Die Wahl von Rails hat sich für uns als vorteilhaft herausgestellt, da das Framework auch nach 10 Jahren noch stark weiterentwickelt wird und das umfangreiche Gem-Ökosystem eine Einbindung von Bibliotheken Dritter leicht macht.

Das Thema Software-Test und die damit ermöglichte Continuos Integration spielt für uns eine große Rolle. Als Test-Framework ist einheitlich Rspec im Einsatz, zum einen, weil es eine einfache und strukturierte Benennung der Tests ermöglicht, Grenzfälle oft besser durch die Community dokumentiert sind (Rspec + Threads/Capybara/Database-Cleaner/Mails/Mocks/..) und es einen besseren Test-Runner (Formatierung der Ausgaben, Colorization, Ausführen von getaggten Tests).

Die Continuos Integration wird durch Jenkins ausgeführt, der letztendlich nur Rspec ausführt und div. Code-Statistiken einsammelt (Metric-Fu, SimpleCoverage, Bundle-Audit) und nach Erfolg deployt. Da wir z.T. zeitlich asynchron und remote arbeiten, werden einige Features als Merge-Request durch mich im Gitlab abgenommen bzw. diskutiert. Zu einem kleinen Teil der Zeit führen wir auch Pair-Programming durch, meist aber mit der Maßgabe von Wissenstransfer oder beim Prototyping von neuen Features (Spikes).

Da Ruby bekanntermaßen nicht das beste Ökosystem für Multi-Threading ist, ist es Usus, lange dauernde Tasks durch separate Worker-Prozesse abfertigen zu lassen. Früher hatten wir dazu Resque im Einsatz, seit kurzem aber Sidekiq. Sidekiq funktioniert prächtig, wird sehr aktiv maintained und bietet eine zeitgemäße UI zur Einsicht der Worker.

Datenbanken

Gestartet mit PHP-Software, hatten wir früher ausschließlich MySQL im Einsatz. Der Empfehlungsbund, der vor ein paar Jahren noch die Aufgabe hatte, unsere PHP-Portale fernzusteuern, setzt daher aktuell immer noch auf MySQL. Alle anderen Web-Portale nutzen aber PostgreSQL als Hauptdatenbank. Die Vorteile, die wir sehen, waren und sind:

• Höhere Transaktionsgeschwindigkeit (damit auch nach Umstellung eine 2x schnellere Testausführung)
• NoSQL-Features, wie Hstore und JSON-Datentypen, die wir gerne für diverse Dokumentenbasierte Daten verwenden (z.B. Fragebögen auf Jobwert.info + Trendea mit variablen Feldern, oder Profilfelder)
• Wird aktiv weiterentwickelt (im Vergleich zu Oracle MySQL)
• “Echtes” SQL mit harten NOT NULL Validierungen und GROUP BY Regeln.

Neben dieser relationalen Datenbank verwenden wir noch ElasticSearch und Redis. ElasticSearch powert die Suche des Empfehlungsbundes + Community-Portale. Redis dagegen verwenden wir meist als Cache-Store, bzw. zu Lagerung von transienten Daten.

Betriebssysteme und Sysadmin

Alle unsere Server verwenden Ubuntu in einer LTS-Version. Fast alle Entwicklungs- und Server-Software wird explizit für Ubuntu angeboten, und die Einbindung der PPAs ermöglicht es im Ausnahmefall auch leicht aktuellere Pakete zu beziehen. Zur Provisionierung nehmen wir Ansible, dass insbesondere durch sein Agentless Deployment, großer Anzahl an Modulen und guter Dokumentation besticht.

Für das Application Monitoring nehmen wir zum einen Graylog2, zum anderen für das Tracking von Exceptions Errbit. Über Graylog2 habe ich Anfang 2015 einen Vortrag bei der Web-Developer Community in Dresden gehalten. Durch Graylog konnten wir schwer zu debuggende Fehler und insbesondere das vorherige Nutzerverhalten nachverfolgen. Dabei laufen alle Apps in einem Graylog-System zusammen, sodass man auch das Verhalten beim Springen durch mehrere Apps nachverfolgen kann (Empfehlungsbund → ITsax.de → Kanaleo.de). In Zukunft wird eine stärke Analyse und auch das Einbinden von System-Logs hier noch eine Rolle spielen.

Als Webserver ist vorrangig Nginx mit Passenger als Application-Server im Einsatz. Nach einigen Experimenten mit Unicorn und Thin ist für uns Passenger einfach das Tool schlechthin – “it just works”. Passenger übernimmt selbst das Starten und Stoppen der einzelnen Apps und auch eine Art Auto-Scaling ohne das man selbst mit Init-Scripten Hand anlegen muss.

Frontend

Alle neueren Apps verwenden Twitter Bootstrap als Basis-CSS System. Der Vorteil hierbei ist wieder die Homogenität und das Transfer von Wissen zwischen Projekten: Einmal erlernte Verwendung der CSS-Klassen und des responsive Grid-Layouts sind transferierbar und bilden eine gemeinsame Sprache bei der Diskussion über Frontend-Development. Für unser kleines Entwicklerteam (und ohne einen 100%-Frontend/UX-Entwickler) bietet Bootstrap eine extrem gut dokumentierte und produktive Ausgangsbasis für alle Web-Projekte.

Normalerweise verwenden wir Sass/Scss als CSS-Transpiler, da es:

1. Schon bei Rails mit integriert ist,
2. Nesting von Selektoren erlaubt sowie
3. Variablen und Kontrollstrukturen erlaubt.

Gerade beim Deployment von unseren Community-Portalen, ITsax.de, ITmitte.de, etc., die alle dieselbe Code-Basis, aber unterschiedliches Branding verwenden, werden diese Variablen sogar mittels Ruby (theme.css.sass.erb) direkt aus einer Konfigurationsdatei gelesen und alle Styles letztendlich davon abgeleitet.

JavaScript-seitig verwenden wir meist das ebenfalls bei Rails von Haus aus gelieferte CoffeeScript. Nach meiner Erfahrung sind einige Fehlerquellen damit umgangen, und Killerfeatures, wie String-Interpolation und Loop-Comprehensions möglich. In Zukunft wird aber hier das Thema EcmaScript 6 eine Rolle spielen.

Viele Seiten verwenden kein eigenes client-seitiges Framework, denn seien wir mal ehrlich – Für eine Job-Website, deren Hauptaufgabe das Anzeigen von statischem Content – Stellenanzeigen – ist, gibt es meiner Ansicht nach nur wenig Ausreden, NoScript-Nutzer oder Nutzer älterer Browser auszugrenzen. Das Thema graceful degradation ist da für uns sehr wichtig.

Nichtsdestotrotz ist Angular.js bereits an 2 Stellen im Einsatz:

• Unsere Mobile Anwendung auf Basis von Cordova/Phonegap verwendet Angular.js
• Faire-Karriere.de verwendet auf der Jobsite Angular und verwendet die Empfehlungsbund.de-API direkt

Intern probieren wir auch gerade Javascript-Apps auf Basis von Flux-Architekturen aus (React), die wir bestimmt in Zukunft mal verwenden werden.

Fazit

Seit der Gründung der Firma in 2008 setzen wir zur Entwicklung unserer Produkte auf OpenSource-Technologien. Der Lernaspekt und das Ausprobieren von neuen Dingen ist Teil unserer Entwicklungsphilosophie. Dabei versuchen wir, alles objektiv und ohne Dogma zu sehen – wenn uns produktivere, einfachere oder bessere Tools über den Weg laufen, probieren wir sie aus und versuchen das gelernte in den Alltag einfließen zu lassen.