Blogbeiträge zum Thema

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.

Umzug ins neue Büro

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.


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

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":http://jenkins-ci.org/, 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":http://www.igniterealtime.org/projects/openfire/). Nach etwa 1.5 Arbeitstagen steht das Ganze nun. Wie wir da vorgegangen sind, möchte ich kurz skizzieren. h3. 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":https://github.com/pludoni/railsTemplate Dort wird auch gleich beschrieben, wie man Ruby mittels RVM installiert und alle anderen, möglicherweise notwendigen, Programme. h3. 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":https://github.com/pludoni/pludoni-jenkins-theme 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 h3. 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":https://github.com/pludoni/railsTemplate#necessary-gems aufgeführt. h3. Installation des Rails-Templates Das fertige "Railstemplate":https://raw.github.com/pludoni/railsTemplate/master/config.xml 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 h3. Zusammenfassender Ablauf des Build Prozesses # Jenkins checkt den letzten Stand des master-Branches aus dem Git-Repository aus # Wir bereiten Rails vor, mittels: bundle install, rake db:migrate, rake db:test:prepare # 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 #* Gleichzeitig läuft SimpleCov mit und generiert - neben dem HTML - auch Ergebnisse im RCov-Format. Dieses Format kann später das RCov Plugin verwenden # yarddoc generiert die aktuellste Dokumentation # brakeman generiert Sicherheitstipps zur Anwendung # Rails-Best-Practices generiert Informationen zur Code-Qualität und Verbesserungsvorschläge # cap deploy wird ausgeführt, und so der letzte Stand auf den Live-Server gepackt # Die verschiedenen Publisher sammeln die Ergebnisse ein # 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

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. h3. 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:

Frameworkunabhängige Fehlerberichtung mit PHP und Redmine

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":http://www.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 h3. Nutzung von Redmine als Bug-API-Server Intern nutzen wir bereits den Bugtracker "*Redmine*":http://www.redmine.org/ (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":https://github.com/milgner/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) h3. 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":https://github.com/geoloqi/php-airbrake-notifier * ca. Zeile 190 in der Services/Airbrake.php die URL anpassen: