BEIER-CHRISTIAN.eu

Rails 2.3.6, Rails 2.3.7 und Rails 2.3.8

Christian Beier — Tue, 25 May 2010 11:36:37 +0000

In den letzten Tagen war ziemlich viel Wirbel in der Rails Community, da drei neue Versionen veröffentlicht wurden – die letzten beiden (2.3.7 und 2.3.8) allerdings nicht ganz freiwillig.

Die Version 2.3.6 ist neben einigen Fehlerbehebungen als Vorbereitung für den Umstieg auf Rails 3 gedacht. Entsprechend sollte bei bestehenden Anwendungen (wenn ein Umstieg geplant ist) auf die neuen Deprecated-Warnungen geachtet werden. Anwendungen die keine Deprecated-Warnungen ausgeben, sollten später ohne ernsthafte Probleme unter Rails 3 funktionieren.

In der neuen Version wurden teilweise schon Funktionen von Rails 3 übernommen. So unter anderem die Funktionen für den Schutz gegen XSS, welche auf dem rails-xss-Plugin basieren. Da dort einige Bugs dem HAML-Entwickler aufgefallen sind, wurde relativ schnell eine aktualisierte Version (2.3.7) veröffentlicht. Doch damit waren die Probleme nicht beseitigt: Einer der Patchs in Rails 2.3.7 soll wiederum für einige Fehler gesorgt haben, weshalb die Version 2.3.8 hinterher geschoben werden musste.

I apologize for wasting a chunk of your day on installing what ought to have been a patch-level update only to find it breaks your app. That’s well out of line with our stable release process and it’s my fault for stepping out of it. I got caught up in a sky-is-falling response to a 2.3.6 bug that affected a handful of users and responded with a fix that exposed a new flaw to nearly all users, despite testing and sanity checking.

CBpictures, mein neues Foto-Zuhause

Christian Beier — Sun, 25 Apr 2010 14:14:18 +0000

Heute mal ein Posting in eigener Sache: Vor einigen Jahren war diese Website noch in zwei Hauptbereiche unterteilt: dem Webdesign und der Fotografie. Nachdem ich aber – da das Webdesign und die Programmierung einen höheren Stellenwert hatte – den Fotografie-Teil stark vernachlässigt hatte, entfernte ich diesen Bereich komplett. Allerdings fehlte mir die ganze Zeit immer etwas.

In den letzten Tagen habe ich an einer neuen Website für die Fotografie gearbeitet. Und jetzt ist sie – zumindest vorläufig – fertig. Wer sich also nicht nur für meine Arbeit in der Webentwicklung interessiert, sollte einmal bei CBpictures vorbeischauen …

Persönliches Fazit zum PolitCamp 2010, Berlin

Christian Beier — Tue, 23 Mar 2010 15:32:53 +0000

Am vergangenen Wochenende fand in Berlin das PolitCamp 2010 im »Radial System V« (Berlin) statt. Gleich vorneweg: Die Location und auch die Aussicht ist super und wirklich zu empfehlen. Zwei Tage nach dem PolitCamp hier meine ganz persönlichen Eindrücke in Kurzform:

Noch einmal zur Location: Die Räume dort sind angenehm groß und trotz der hohen Anzahl der Teilnehmer fand man auch immer problemlos einen vernünftigen Sitzplatz. Stehen oder auf dem Boden sitzen musste ich jedenfalls in keiner einzigen Session. Auch für eine vernünftige Stromversorgung wurde dank der »Netzsteckers« gesorgt. Meine vorsorglich mitgebrachte 10 Meter Stromleitung konnte jedenfalls im Rucksack bleiben. Daumen hoch dafür.
Wie bei einer solchen Veranstaltung üblich, ist das WLAN instabil und langsam. Ständig ist man rausgeflogen und musste sich erneut einloggen. Zudem war es kriechend langsam. Aber da man das ja eigentlich vorher schon weiß, und ich mich entsprechend vorbereitet habe, war dies für mich jetzt nicht besonders tragisch. So war der Nervfaktor bei mir zumindest nach 10-Minuten erledigt.
Problematischer war schon die Verteilung der Sessions: Die interessanten Themen finden immer zur selben Zeit statt. Gerade am ersten Tag war das recht nervig. Zudem wäre zu überlegen, dass bei Sessions mit Promifaktor (z.B. Frau Schröder) keine weiteren Sessions daneben stattfinden. Denn für die bleibt sowieso kein Besucher mehr übrig.
Auch war es ziemlich blöd, dass zwischen den Sessions keine Pause war. So konnte man nach einer Session kaum mit dem Referenten sprechen, ohne die Hälfte der nächsten Session verpassen zu müssen. Hier sollte im nächsten Jahr ein Puffer von vielleicht 10-15 Minuten eingeplant werden. Zudem ist man den ganzen Tag so nur von Session zu Session gehetzt.
Im Vorfeld der Konferenz konnten die geplanten Sessions mit einem neuen und interessanten Tool »Liquid Session« eingereicht und bewertet werden. Warum auf dieses Meinungsbild dann aber in der Konferenz aber nicht zurückgegriffen wurde, bleibt mir verschlossen, was eigentlich recht schade ist. Eine Idee wäre auch, jeder Session einen Tag zu geben. Dieser könnte nicht nur bei Twitter verwendet werden, sondern auch um zusätzliche Informationen zu einer Session an einem zentralen Ort (Liquid Session) zur Verfügung zu stellen.
Recht schade fand ich auch, dass für die meisten Sessions zu wenig Zeit vorgesehen war (das Problem wird aber wahrscheinlich immer bestehen). So sind die Diskussionen leider immer sehr weit an der Oberfläche geblieben und auf wirklich interessante Aspekte konnte so nicht tief genug eingegangen werden. Auf wirklich konkrete Feststellungen und Ergebnisse sind so leider ausgeblieben. Vielleicht habe ich da aber auch einfach mit zu hohen und vielleicht auch falschen Erwartungen (ich bin ja doch eher als Entwickler an handfesten Dingen interessiert) herangegangen.
Das PolitCamp habe ich hauptsächlich als eine Veranstaltung zum Kontakte knüpfen und Netzwerken verstanden. Leider ist aufgrund des vollen und interessanten Sessionplan dies leider etwas zu kurz bei mir gekommen. Vielleicht sollte auch schon in der Planung der Veranstaltung dafür mehr Raum gegeben werden.

Insgesamt war das PolitCamp aber sehr interessant, spannend und wirklich gut gelungen. Eine solche Veranstaltung in der Größenordnung muss man auch erst einmal so reibungslos über die Bühne bringen. Allein das verdient schon sehr großen Respekt an die Organisatoren des PolitCamp 2010.

Für alle die nicht beim PolitCamp dabei sein konnten: Die Videos von den Sessions und Diskussionsrunden in der großen Halle stehen alle bei Politik.de zur Verfügung.

»Ruby Best Practices« zum Download

Christian Beier — Tue, 23 Mar 2010 12:42:41 +0000

»Ruby Best Practices« zeigt erprobte und praxistaugliche Ansätze und Lösungen für die Programmierung mit Ruby. Ein besonderer Augenmerk wird auf das Test-Driven-Development (TDD) gelegt, aber auch die Bereiche APIs, Debugging und Internationalisierung werden behandelt. Das Buch von Gregory T. Brown ist jetzt als Open Source eBook bei Github veröffentlicht worden. Das gedruckte »Original« gibt es weiterhin bei O’Reilly.

Eigenentwicklung vs. Standardsoftware

Christian Beier — Wed, 17 Mar 2010 07:00:47 +0000

Vor der Entwicklung einer umfangreichen Website oder Community steht am Anfang immer die Frage: Soll das System komplett selbst entwickelt werden (Individuallösung) oder auf eine fertige Lösung – die meist nur noch angepasst werden muss – zurückgegriffen werden. Diese Entscheidung klingt einfach, kann aber im weiteren Betrieb weitreichende Auswirkungen und Konsequenzen auf die Erweiterbarkeit, Kosten und den wirtschaftlichen Erfolg eines Projektes haben. Welche Entscheidung nun die Richtige ist, hängt von verschiedenen Faktoren ab:

Welche Funktionen muss das System / die Website besitzen?
Was sind die relevanten Anforderungen und was ist »nice to have«?
Wie sind die Randbedingungen (einen Server, welche Programmiersprache, etc.)?
Welches Budget und Zeit für die Realisierung stehen zur Verfügung?

Diese Punkte sollte noch vor einer Entscheidung vollständige geklärt und mit allen Projektbeteiligten abgestimmt sein.

Vorteile einer Eigenentwicklung

Know-how: Durch die Eigenentwicklung erhöhen sich die Fähigkeiten der beteiligten Personen. Sie lernen von Grund auf die Problematiken kennen und können so schnell und kompetent bei Problemen und Störungen eingreifen. Sie stecken praktisch in der Software drin. Dieses Wissen betrifft nicht nur die Anwendung an sich, sondern auch das Wissen über die verwendete Technologien und Programmiersprachen erhöht sich. Dies kann wiederum in Drittprojekten vermarktet werden.
Schlanke Software: Durch die Eigenentwicklung bleibt die Software schlank. Es wird nur die Funktionalität entwickelt und integriert, die auch wirklich benötigt wird. Dagegen möchte Standardsoftware ein möglichst breites Spektrum an Funktionen und Einsatzzwecke abdecken, was meist zu einer erheblichen Überdimensionierung und zu mittelmäßigen Kompromissen führt.
Keine Abhängigkeit: Bei kommerziellen Softwareanbietern besteht die Gefahr, dass diese ihre Strategie ändern oder gar Insolvent werden. Grundsätzlich besteht immer die Abhängigkeit, in welche Richtung die software weiterentwickelt wird und auch die möglichen Sicherheitsrisiken kennt meist nur der Anbieter (dies gilt meist auch bei Open Source Software). Bei einer Eigenentwicklung hat man selbst die Kontrolle über den Quellcode und die Weiterentwicklung.
Bessere Wartbarkeit: Änderungen und neue Funktionen können meist in kürzerer Zeit als bei einer Standardsoftware integriert werden. Die Software kann flexibler mit dem Projekt bzw. Unternehmen wachsen.
Adaptierbarkeit der Standardsoftware: In den seltensten Fällen bringt die Software alle benötigten Funktionen und Konfigurationen mit. Sie muss meist an die eigenen Bedürfnisse erst angepasst werden. Auch dies kostet Zeit und der Entwickler muss sich erst in die Dokumentation und den Aufbau des Codes einarbeiten. Gerade bei kommerziellen Systemen ist dies vielfach erst gar nicht möglich, da der Quellcode geschützt ist. Hier wäre man wieder vom Softwareanbieter abhängig.
Differenzierung von Wettbewerbern: Durch die Entwicklung eigener Funktionen kann sie ein Unternehmen mit einer Eigenentwicklung viel bessern von Konkurrenten abgrenzen.

Nachteile von Eigenentwicklungen

Entwicklungskosten: Je nach Komplexität der Software können die Entwicklungskosten sehr hoch sein. Zudem lassen sich diese zu Beginn eines Projektes nur sehr schwer und ungenau einschätzen, da viele Probleme erst während des Entwicklungsprozesses auftreten und nicht eingeplant werden können.
Zeitbedarf: Nicht nur die Kosten, sondern auch der Zeitbedarf ist am Anfang nur sehr schwer abschätzbar. Bei der Planung sollten daher grundsätzlich sehr großzügige Pufferzeiten eingeplant werden. Auch neue Methoden des Projektmanagement wie z.B. SCRUM können helfen. Ansonsten bedeutet ein steigender Entwicklungsaufwand auch sehr schnell eine Zeitverschiebung.
Qualitätsprobleme: Die Entwicklung von fehlerfreier Software ist nicht möglich. Und je komplexer die Software ist, desto länger kann es auch dauern, bis das System in der Pilotphase (in dieser die Software unter realen Bedingungen im Einsatz ist) die notwendige Stabilität erreicht hat. Dieser Problematik kann durch entsprechende Entwicklungs-Methoden wie z.B. Unit Tests begegnet werden.
Abhängigkeit: Was auf der einen Seite ein Vorteil ist, ist auf der anderen ein Nachteil. Bei einer Eigenentwicklung man man sich von den Mitarbeitern bzw. Firmen abhängig, die das System entwickelt haben. Zusätzlich steigt bei den Mitarbeitern die Kompetenz und damit ihr Marktwert. Dies kann sich in steigenden Gehaltsforderungen oder einer Kündigung ausdrücken. Selbst bei einer umfangreichen Dokumentation der Software, muss sich ein neuer Mitarbeiter oder eine neue Firma erst in die Denkweisen der alten Entwickler einarbeiten.
Technologiewechsel: Der technologische Wandelt in der IT-Industrie ist sehr schnell. Dadurch kann eine Software bzw. eine eingesetzte Technologie recht schnell veralten. Und je älter sie ist, desto schwieriger wird es Entwickler zu finden, die sich mit der Wartung beschäftigen können.

Vorteile von Standardlösungen

Zeitgewinn: Je nach dem wie vollständig die festgelegten Anforderungen von der Softwarelösung abgedeckt werden, kann das System sofort oder nach kurzer Zeit eingesetzt werden.
Niedrigere Kosten: Sofern die Standardsoftware viele der benötigten Funktionen erfüllt und auch den qualitativen Anforderungen gerecht wird, sind die Kosten für die Einführung und Betrieb meist geringer, als bei einer Eigenentwicklung.
Qualität: Weil Standardprodukte bei verschiedenen Anwendern im Einsatz sind, wurden viele Fehler von diesen bereits entdeckt und entfernt. Daher ist die Qualität gerade am Anfang bei Standardsoftware höher, als bei Eigenentwicklungen.
Regelmäßige Verbesserungen: Jeder Einzelne profitiert bei Standardlösungen von der Kreativität und Ideen aller. Zudem verteilen sich die Entwicklungskosten neuer Funktionen auf viele Kunden.

Nächster Halt: Ruby on Rails 3.0

Christian Beier — Tue, 09 Mar 2010 13:03:31 +0000

Mit Rails 3.0 ist ein großes, neues Release für das beliebte Ruby Framework im Anmarsch. Neben vielen Fehlerbehebungen gibt es auch viele neue Funktionen und Verbesserungen. Eine der größten Neuerung ist wohl die neue Abfragesprache für Active Record. Dazu gibt es einen verbesserten Router, der besonders gut RESTful Anwendungen abbilden kann und eine neue Mailer API. Mit dieser können dann auch endlich Multipart Nachrichten ohne Bauschmerzen versendet werden.

Die aktuelle Beta von Rails 3.0 ist noch nicht für produktive Anwendungen geeignet. Aber um sich schon einmal mit den neuen Möglichkeiten und Funktionen vertraut zu machen, kann ein früher Blick sicherlich nicht schaden. Zu beachten ist jedoch, dass die aktuelle Version und die neue Vorabversion von Ruby (als Grundlage für Ruby on Rails) nicht zeitgleich betrieben werden können. Daher ist die Installation über RVM (Ruby Version Manger) zu empfehlen.

rvm install 1.9.1
rvm 1.9.1
gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
gem install rails --pre

Schon ist Rails 3.0 lauffähig und es kann eine neue Rails Anwendung erstellt oder bestehende portiert werden. Um zur aktuellen Ruby-Version zurückzukehren, muss »rvm system« im Terminal eingegeben werden. Wie genau eine bestehende Anwendung portiert werden kann, zeigt ein 25-minütiger Screencast bei PeepCode, der kostenlos erhältlich ist.

Die Neuerungen von Ruby on Rails 3.0

Active Record

Die wohl auffälligste Änderung von Rails 3.0 ist de neue Abfragesprache für Active Record. Statt bisher alle in eine »find«-Methode zu schreiben, werden die einzelnen Bestandteile einer Datenbankabfrage in einzelne Methoden zerlegt.

Books.find(:all, :order => "updated_at desc", :limit => 15) #-> Rails 2.x
Books.order("updated_at desc").limit(15) #-> Rails 3.x

Books.find(:first, :conditions => ["title = ?", 'Ruby 3.0'], :order => "updates_at desc") #-> Rails 2.x
Books.where("title = ?", 'Rails 3.0').last #-> Rails 3.x

Ein paar Beispiele für die neue Abfragesprache von Ruby on Rails 3.0

Aber keine Angst: Zumindest bis zur Version 3.1 von Rails soll die bisherige API weiter unterstützt werden.

Routing

Auch das Routing wurde etwas aufgeräumt und übersichtlicher gestaltet. Unter anderem wurde auf das »map« am Anfang einer Route verzichtet. Ansonsten gibt es viele neue Funktionen und Möglichkeiten, unter anderem lassen sich Requests besser nach bestimmten Mustern verarbeiten und Routes zuweisen.

map.root :controller => "pages", :action => "index" #-> Rails 2.x
root :to => "pages#index" #-> Rails 3.0

map.login "/login", :controller => "sessions", :action => "login" #-> Rails 2.x
match "/login" => "sessions#login", :as => :login #-> Rails 3.x

#-> Rails 2.x
map.resources :books, :collection => { :filter => :get } do |books|
books.resources :reviews
end

#-> Rails 3.x
resources :books do
get :filter, :on => :collection
resources :reviews
end

Code-Beispiele für die neue Routes API von Rails 3.0

Action Mailer

Obwohl die Entwicklung von Rails Anwendungen eher Spaß als Arbeit ist, waren der Versand von E-Mails bisher die am meisten gemiedene Aufgabe. Mit Rails 3.0 gibt es eine neue API, die den Versand von E-Mail vereinfachen soll. So gibt es jetzt einen eigenen Ort unter »app/mailers« und es werden bei Bedarf die E-Mails als Multipart (Text und HTML-Teil) versendet. Sehr schön finde ich es auch, dass ein Mail in Rails jetzt als Objekt behandelt wird:

Notifier.deliver_signup_notification(recipient) #-> Rails 2.x
Notifier.signup_notification(recipient).deliver #-> Rails 3.x

# Beispiel für eine Multipart E-Mail in Ruby on Rails 3.x
def multipart_email
mail(:to => recipient.email) do |format|
format.text { render :text => "Text-Alternative der E-Mail" }
format.html { render :text => "

Dies ist eine HTML-E-Mail

" }
end
end

Das sind so die größten Neuerungen von Ruby on Rails 3.0. Natürlich gibt es noch viele weitere zu entdecken. Zudem hat sich einiges unter der Oberfläche getan und die Geschwindigkeit von Rails wurde verbessert. Was sich alle genau ändert, wird im offiziellen Release Note verraten.

Hobo 1.0: Mehr Spaß mit Ruby on Rails

Christian Beier — Mon, 08 Mar 2010 07:43:32 +0000

Wer dachte, mit Ruby on Rails lassen sich Webanwendungen schon schnell und einfach entwickeln, hat bisher noch nicht von Hobo gehört. Hobo ist eine Erweiterung für Rails (in Form eines Gem) und bringt viele praktische Dinge mit, die den Entwickleralltag erleichtern: z.B. fertig eingerichtete Authentifizierung, Rechtesystem, AJAX-Interface, …

Aktuell liegt Hobo in der Version 1.0 vor und hat den Stable Status erreicht. Somit kann Hobo ohne größere Bedenken auch produktiv eingesetzt werden. Die Erweiterung eignet sich sowohl für das schnelle Prototyping, wie auch für komplette Anwendungen. Mitgebracht wird eine eigene Markup Sprache: DRYML (»Dont Repeat Yourself Markup Language«). Diese hilft dabei, die Entwicklung von Templates zu abstrahieren und stark zu beschleunigen.

Sehr schön finde ich auch, dass sich die Entwickler nicht nur rein auf Hobo konzentriert haben, sondern mit »Hobo Cookbook« auch gleich eine sehr hilfreiche Ressource geschaffen haben. Im Cookbook befinden sich sich praktische Codeschnipsel und Hilfestellungen für die Arbeit mit Hobo.

Für den Einstieg in Hobo ist auch der 18-minütige Screencast bei Vimeo sehr zu empfehlen. Und wer sich erst von den Ergebnissen – die mit Hobo erreicht werden können – überzeugen möchte, schaut am besten in der Galerie vorbei.

jQuery: Ausgewählte Option aus Select-Box auslesen

Christian Beier — Wed, 03 Mar 2010 20:44:52 +0000

Manche Dinge sind eigentlich recht einfach, aber man tut sich mit ihnen schwer. So ist es zum Beispiel, wenn es darum geht, den ausgewählten Wert auf einem Select-Feld mit jQuery auszulesen. Nehmen wir an, das Dropdown-Feld sieht wie folgt aus:

<label for="obst">Obst</label>
<select name="obst" id="obst">
<option value="1">Orange</option>
<option value="2">Apfel</option>
<option value="3">Banane</option>
</select>

Ausgelesen kann der aktuelle Wert – eigentlich wie bei jedem anderen Input-Feld auch – mit val():

$('select#obst').val();

Ausgabe des Value-Wertes

Soll aber der Text, anstatt der Value ausgegeben werden, funktioniert die val-Funktion nicht mehr. Hier kann aber mit dem “:selected” Selektor gearbeitet werden:

$('select#obst :selected').text();

Ausgabe des Textes vom ausgewählten Listenpunkt

Ein weiteres mögliches Szenario bei der Arbeit mit Select-Boxen ist die Ausgabe von mehreren ausgewählten Optionen:

$('select#obst :selected').each(function(i, option) {
// Verarbeitung der Optionen
alert(option.value + ' ' + option.text);
});

Ruby on Rails, Passenger unter Debian/Ubuntu

Christian Beier — Mon, 01 Mar 2010 07:23:56 +0000

An dieser Stelle eine kleine Anleitung für die Installation von Ruby on Rails unter Debian/Ubuntu mit Passenger als Connector für den Apache Webserver.

Für die Installation der Debian-Pakete nutze ich aptitude. Der Paketverwalter apt-get sollte an dieser Stelle aber genauso gut funktionieren. Wenn du also apt-get statt aptitude einsetzt, bitte statte aptitude immer apt-get schreiben. ;)

Zuerst installieren wir die benötigten Pakete:

aptitude install ruby rubygems irb ruby-dev php5 mysql-server rake build-essential libopenssl-ruby apache2-prefork-dev libapr1-dev libaprutil1-dev libxslt1-dev libxml2-dev libxml2 libxml2-dev

Dann ein freundliches

gem update --system

zur Sicherheit.

Jetzt noch die erforderlichen Gems herunterladen und installieren (unter anderem Rails und Passenger):

gem install rails builder haml hpricot passenger mysql sqlite3-ruby nokogiri will_paginate --include-dependencies

Das Ganze dauert ein ziemliches Weilchen. Anschließend muss noch das Setup von Passenger gestartet werden:

passenger-install-apache2-module

Nachdem der Installer erfolgreich durchgelaufen ist und du alle Anweisungen vom Installer beachtet hast und alles korrekt durchgeführt hast, sollte Rails bei dir jetzt laufen.

Einrichtung einer Apache vHost

Damit du dein Rails-Projekt auch erreichen kannst, muss noch kurz in Apache ein vHost zu dieser Domain eingerichtet werden. Lege dazu unter /etc/apache2/sites-available/ eine neue Datei z.B. mit dem Namen mein_projekt an.

ServerName www.mein-projekt.de
DocumentRoot /var/www/mein_projekt/public

AllowOverride all
Options -MultiViews

/etc/apache2/sites-available/mein_projekt

Wichtig ist, dass du das Verzeichnis auf rails_projekt/public legst. Zum Schluss musst du noch einen Symlink anlegen:

ln -s /etc/apache2/sites-available/mein_projekt /etc/apache2/sites-enabled/mein_projekt

und den Apache reloaden /etc/init.d/apache2 force-reload.

Usability-Test mit Menschen mit Behinderungen

Christian Beier — Sat, 27 Feb 2010 20:30:43 +0000

Die Agentur aperto hat unter dem Titel »Einfach-teilhaben.de im Usability-Test mit Menschen mit Behinderung« einen sehr interessanten Praxisbericht veröffentlicht. Leider sind solche Daten aus der Praxis (wenn Barrierefreiheit und Usability zusammenkommen) recht selten, weshalb der Bericht umso spannender ist.