Neu in Kategorie Tutorials

Continuous Integration for Jasmine- and CasperJS Tests

JavaScript Test Automation using TeamCity

This article explains all steps you need to perform to setup your Continuous Integration System with TeamCity + PhantomJS + CoffeeScript (optionally) + Jasmine and/or CasperJS :)

There's an increasing demand for interactive web applications which dynamically load data using AJAX and handle user interaction with lots of fancy JavaScript stuff. That's why we have significant more Javascript code in our web apps than it was 10 years ago (you still remember how "hip" it was to use JavaScript back in 2000 as a web developer?).

Javascript code is essential for modern web applications. It needs to be tested. It wants to be tested. We needed a setup which allows to run our CasperJS and Jasmine test suites both locally and on our build server (TeamCity). This article covers the setup of TeamCity for local testing and especially automated headless testing of Javascript code in detail.

JRuby Deployment - skalierbare Anwendungen auf der JVM

In der Ruby on Rails Welt ist der Phusion Passenger mittlerweile das Mittel der Wahl. Damit wird das Deployment der Anwendung in einem Apache oder Nignx Server zum Kinderspiel. In der JRuby-Welt sieht das Deployment etwas anders aus. Man benötigt eine JVM, in der die Anwendung laufen kann.

Continuous Upgrades - Rails und JRuby

Upgrade der ObjectTime von Rails 2.3.4 zu Rails 3.2.1,
sowie JRuby 1.4.0 zu JRuby 1.6.7

Nachdem Rails in der Version 3.2 erschienen ist, haben wir uns dazu entschlossen, auch unsere mit JRuby on Rails erstellte Zeiterfassung auf den neusten technischen Stand zu bringen. Denn nur durch regelmäßige Updates aller relevanten Bibliotheken kann man dauerhaft sicherstellen, dass Rails-Anwendungen zuverlässig funktionieren und technisch auf dem neuesten Stand sind.

Und da sich gerade beim Schritt von Rails 2 zu Rails 3 im Rails-Framework einiges unter der Haube verändert hat (Neuerungen im Rails 3), z.B.

dokumentieren wir hier kurz die beim Upgrade von uns vollzogenen Schritte sowie relevante Stolperfallen.

PDF und HTML mit acts_as_flying_saucer

Nutzer lieben Webanwendungen, die PDF-Dateien erzeugen. PDFs sind wie sauber ausgefüllte Papierformulare und Nutzer können sie ausdrucken, abheften, mit in ein Meeting nehmen, ... Kurz: Nutzer können weiter so arbeiten wie vor der Webanwendung, nur irgendwie moderner. Und genau das lieben sie.

Entwickler lieben Einfachheit und wollen Aufwände gern gering halten. Mit CSS muss man sich ja in jedem Falle auseinandersetzen. Wie wäre es, auch PDFs über CSS zu gestalten, nur eben mit Seitenzahlen, Kopf- und Fusszeile, ...

In unserem Artikel JRuby on Rails PDF Generierung haben wir schon vorgestellt, wie man einzelne Partials in PDFs bringen kann. Nun zeigen wir, wie eine normale Rails-Action einfach statt Anwendungs-HTML eine PDF-Datei erzeugt.

JRuby, Rails3 und RailsWayCon 2010

JRuby

Die meisten JRuby-Nutzer kommen bekanntlich aus dem Java-Umfeld. Sie nutzen die Agilität der Scriptsprache Ruby mit der ausgereiften Infrastruktur und einer Unmenge an Bibliotheken der Java-Welt. Daher werden die meisten auch Ant kennen. In der Ruby-Welt heißt Ant Rake!

Thomas Enebo zeigt nun in seinem Blogeintrag wie man
  • Ant-Tasks mit Rake aufruft
  • Rake mittels Ant nutzt
  • Rake-Tasks als aufrufbare Ant-Targets importiert (und umgekehrt)

Ein weiterer interessanter Artikel von Charles Nutter gibt Tipps um eine bessere JRuby-Startzeit zu erreichen. Im Artikel JRuby Startup Time Tips zeigt er, wie man mittels JVM Java_OPTS die Startperformance beschleunigen kann.

Ruby on Rails 3

Die Rails 3 Beta ist nun schon eine Weile zum Ausprobieren freigegeben. Falls Euch vor dem geplanten Update eurer Rails 2.3.x Anwendung Fragen wie
  • Was muss man beim Update beachten?
  • Wo finde ich Anleitungen zur Rails 3 Umstellung?
  • Welche Plugins und Gems laufen schon mit Rails 3?
durch den Kopf gehen, hier ein paar interessante Links zu Rails 3.

Auf rubyonrails.de gibt es eine super Sammlung von Tutorials, Screencasts und Blogeinträgen.

Die Webanwendung http://railsplugins.org/ bietet eine gute Übersicht, welche Plugins schon für Rails 3 bereit sind. Diese Liste kann von allen aktiv erweitert und aktualisiert werden. Des Weiteren wird zu jedem Plugin angegeben, ob es threadsicher ist, mit Ruby 1.9 und/oder JRuby läuft.

RailsWayCon 2010

RailsWayConf 2010Wer sich lieber selbst ein Bild von der aktuellen JRuby/Rails-Entwicklung machen will, findet sicherlich wieder viele interessante Vorträge auf der diesjährigen RailsWayCon vom 31. Mai bis zum 2. Juni in Berlin.

GlassFish-Gem 1.0.0

Das GlassFish-Gem von Vivek Pandey ist in der Version 1.0.0 erschienen.

Neuerungen sind neben einigen BugFixes:
  1. die Implementierung mittels des neu erschienen Glassfish v3 Servers
  2. die Startzeit wurde um ca. 15% verbessert
  3. die Unterstützung von Rack (Ruby Webserver Interface) ist komplett
  4. es ist möglich, Glassfish mittels eines Codeblockes auszuführen
    GlassFish::Server.start(:address=>"127.0.0.1", :port=>4000) do
      use Rack::CommonLogger
      use Rack::ShowExceptions
      map "/hello" do
        use Rack::Lint
        run Proc.new {[200, {"Content-Type" => "text/html"}, "Hello"]}
      end
    end
    
  5. der Sinatra-Support wurde verbessert
  6. auf der Kommandozeile kann die IP Adresse mitgegeben werden
  7. die Konfiguration von Grizzly (NIO based HTTP Lib) kann mittels der glassfish.yml festgelegt werden
  8. man findet es nun auch bei GemCutter
Was ist eigentlich das GlassFish-Gem?

JRuby Anwendungen kundenspezifisch anpassen

Branding und Customizing einer JRuby on Rails Anwendung

Wenn man Rails-Anwendungen für Kunden betreibt, muss man frühzeitig an kundenspezifische Anpassungen denken. Neben dem kundenspezifischen Design (Farben und Logos aus dem Corporate Design, "Branding") spielen dabei auch konfigurierbare Feature-Sets ("Customizing") eine wichtige Rolle. Natürlich wird jeder Kunde sowohl seine eigene Datenbank bekommen als auch seinen eigenen Rails-Server: Sicherheit geht vor! Jedoch will man als Entwickler nicht deswegen mehrere Kopien des Quelltextes auf dem aktuellen Stand halten müssen. In diesem Artikel wollen wir unser Branding-Konzept am Beispiel unserer Zeiterfassung ObjectTime vorstellen. An den Stellen, wo wir es einsetzen, hat es sich bereits ausgezahlt.

Statische Migrationen, flexible Anwendung

Da wir unsere Projekte meist im Team bearbeiten, standen wir schon öfter vor folgendem Problem:
Ein Entwickler startet ein neues Projekt und legt das Model User an. Da das Projekt am Anfang steht, hat der User erst mal nur ein Login. In der Migration wird auch gleich ein "admin"-User angelegt. Ein paar Tage später wird entschieden, dass beim User auch Vor- und Nachname benötigt werden. Also legt der Entwickler eine Migration an, die dem User diese Felder hinzufügt und das User-Model erhält Validierungen, damit die Vor- und Nachnamen auch befüllt werden.

Nun kommt ein zweiter Entwickler zum Projekt hinzu. Er checkt die Sourcen frisch aus und will seine Entwicklungs-DB migrieren. Schon die erste Migration schlägt fehl, da diese den "admin"-User ohne Vor- und Nachnamen anlegen will. Auch später im Produktivsystem funktioniert diese Migration nicht mehr.
Noch spannender wird es, wenn im Laufe der Zeit durch ein Refactoring ein Model ganz entfernt wurde. Alle vorangehenden Migrationen, die irgendwie auf die Klasse zugreifen wollen, schlagen fehl. Kurzum: Die Anwendung entwickelt sich dynamisch, während die Migrationen zum jeweiligen Anwendungsstand in Stein gemeißelt werden.

Datenbankmigration im Browser

Für die Verwaltung der Änderungen an der Datenbank gibt es in Rails das mächtige Konzept der Migrationsskripte. Da dies Ruby-Skripte sind, steht einem der volle Funktionsumfang von Ruby und Rails zur Verfügung. Allerdings benötigt man zum Durchführen einer Migration eine Rails-Umgebung mit Zugriff auf die Datenbank, in der man die Migrationsskripte ausführen kann. Während der Entwicklung ist das keine Hürde, aber bereits in Test- und spätestens in Produktionsumgebungen könnte das zum Problem werden.

Besonders wenn man Rails mittels JRuby in eine Java-Umgebung eingeführt hat, wird in der Produktionsumgebung auf der Konsole kein Rails verfügbar sein. Viele Unternehmen reglementieren zudem den Zugriff auf die Datenbank, so dass Entwickler die Produktionsdatenbank nicht erreichen können oder die Zugangsdaten nicht kennen. Die Anwendung kann aber auf die Datenbank zugreifen - warum nicht die Migration über die Anwendung auslösen?

Rails-Datenbankkonfiguration auslagern

DB-Konfiguration im Team - JRuby mit JNDI

Rails stellt einen einfachen Zugriff auf alle Konfigurationsdaten zur Verfügung. So stehen auch unsere Datenbank-Zugänge in der database.yml. Dies ist wunderbar, wenn man schnell ein Projekt aufsetzen will und anschließend allein mit seinem eigenen Webserver entwickelt. Doch was ist, wenn ein etwas größeres Team an einer Anwendung entwickeln möchte, aber nicht jedes Mitglied ein Login-Passwort Paar der Art "test" - "test" auf seiner lokalen Test-Datenbank vergeben möchte?
Hier bietet Doug Alcorn eine elegante Lösung, in dem er Blöcke innerhalb der YAML-Datei verwendet: Er definiert einen Standard-Loginblock, den er dann in die jeweilige Datenbank-Konfiguration für Development, Test und Production einfließen lässt. Allerdings wird vorher noch der Inhalt einer zweiten Datei eingefügt, die jeder Entwickler in sein config-Verzeichnis legen kann. In dieser kann der Loginblock beliebig überschrieben werden.
Bookmark and Share

Sponsor

Gesponsort von ObjectFab GmbH

Letzte Kommentare

  • Florian Gilcher: Hi, ich hängs hier mal für alle Posts an: Danke Mehr lesen
  • Stean Wienert: Cool :) Schreibe ich mir direkt mal in den Kalender. Mehr lesen
  • Dominik: Da in dem Benchmark auf Nokogiri zurückgegriffen wird (das in Mehr lesen
  • Andre: Schön, dass jetzt endlich die Classpath-bugs gefixt sind! Macht sich Mehr lesen
  • iGEL: Auf GitHub sind auch aktuelle Versionen verfügbar. Sucht euch hier Mehr lesen