Static content in your Rails application

Our heros over at thoughtbot.com blogged about static pages and their newly released Rails engine high_voltage. High Voltage helps you dealing with simple, stupid static content pages that nobody wants but everyone needs. ;) (With static pages I’m thinking of imprint, about us, etc.)

In our projects we had a similar solution but to edit the pages more easily and without the need to deploy the whole application we’re saving the content in the database.

Because the database part was missing in high_voltage but I’ve really liked the idea to extract that feature into a rails engine I’ve created a fork last night.

My fork checks if there is a valid template file in views/pages/ - if not it checks the Database and renders the views/pages/show template.

How to use it?

Installation

script/plugin install git://github.com/bumi/high_voltage.git

Create pages
this is up to you. ;)
You can add static files to your app/views/pages/ directory or create a database entry:

HighVoltage::Page.create(:title => "Hello world", :body => "High Voltage! High Voltage!")

That’s it!

For more information check the original thoughtbot post” - You should follow their blog anyway! - And have a look at the readme.

Hope you like my addons.
What are your solutions for static pages?

Continious integration mit Hudson und Integrity

Continious Integration ist ein wichtiger Bestandteil von Software, vor allem wenn mehrere Beteiligte am Projekt Teilnehmen. Nach jedem Push wird dann der aktuelle Code vom CI-System ausgecheckt und die gewünschten rake-Tasks ausgeführt. Neben dem schon bekannten CrusieControll.rb gibt es noch zwei andere interesannte Cnotinious Integration Tools die ich kurz vorstellen möchte: Integrity und Hudson.

Integrity

Integrity ist sehr einfach gestrickt. Nach der relativ simplen installation kann man verschiedene Projekte hinzufügen. Der einzige “overhead” der noch ensteht, ist das zusammenstellen eines rake-tasks den Integrity nach jedem pull ausführt. Dieser einfacher rake-Task kann als Einstieg dienen:

Nach jedem Build können die Entwickler auch über die zu verfügung stehenden Notifier (Email, Campfire, IRC, …) über den Stand informiert werden. Weiterhin gibt es auch ein Growl-Plugin und Dashboard-Widget. Der Build der Applikation wird über Github via einem POST-Webhook zu Integrity angetriggert.

Der einzige Nachteil ist, dass bei lang-andauernden Builds der entsprechende Webserver einen Timeout erreicht. Der kann natürlich hochgesetzt werden.

Integrity

Hudson

Hudson ist eine weitere Alternative. Es ist ein Java-Basiertes CI-System und wird out-of-the-box mit einem Webserver ausgeliefert. Entsprechende Debian-Packages gibt es hier. Hudson bietet gegenüber Integrity mehr Konfigurationsmöglichkeiten, daher dauert es ein bisschen länger bis man sein neues CI-System am laufen hat. Meet-Hudson bietet eine gute Übersicht über Hudson.

Der oben schon vorgestellte Rake-Task kann ebenfalls für Hudson verwendet werden. Allerdings müssen Plugins für eine Rake- und Githubunterstützung installiert werden (Git-Plugin und Rake-Plugin).

Bei Hudson ist der initiale Konfigurationsaufwand zwar geringer als bei Integrity, dafür müssen viele Plugins installiert und konfiguriert werden um seine “perfekte” CI-Umgebung ans laufen zu bekommen. Unschön an Hudson ist die fehlende unterstützung des triggern eines Builds über einen POST-Webhook. Stattdessen kann dies nur über ein GET getriggert, was aber seitens Github nicht unterstützt wird. Eine Alternative ist das periodische abprüfen von Änderungen in der Repository.

Hudson

Benchmariking und Überwachen von Webapps mit httperf, munin und gltail

Für unser letztes Projekt war Benchmarking und klare Aussagen über die Auslastung des Servers ein wichtiger Punkt. Daher haben wir uns ein paar Tools herangezogen die uns geholfen haben unsere Webapplikation (visuell) “im Griff” zu behalten.

Benchmarking mit httperf

Httperf ist in erster Linie ein Benchmarking-Tool dass die Durchsatzrate von Requests eines Webservers messen kann. Von httperf wird mit einer fixen Rate diese Requests an den Server geschickt und mit den angekommenen Replies verglichen. Der Output gibt uns Informationen zu der Dauer dieses Tests, der Fehlrate (Anzahl der nicht erhaltenen Replies).

Einen Beispielhaften Output kann man hier einsehen.

Das Ergebnis einer Messung sind:

Sehr interessant dabei ist das Resultat der Reply rate:


Reply rate [replies/s]: min 0.0 avg 4.9 max 10.8 stddev 4.2 (40 samples)

Diese gibt uns eine Auskunft über den Durchschnitt und die Standardabweichung der Antwortzeit. Diese Messungen sind genauer je mehr Stichproben während der ganzen Messung entnommen wurden. Durch die Optimierung des Programmcodes können diese Werte dann demensprechend verbessersert und dadurch eine schnellere Antwortzeit gemessen werden. Mehr Informationen zu httperf sind aus dem Manual zu entnehmen. Weitere Informationen kann man auch im Blogpost von Grig Gheorghiu nachlesen. Wer ein bisschen tiefer in die Materie einsteigen möchte, dem empfehlen wir den Screencast von PeepcodeBenchmarking with httperf

Monitoring mit Munin

Um die Server während der Produktivbetriebs visuell im Blick zu haben empiehlt sich die Benutzung von Munin. Mit Munin ist es möglich die verschiedenen Prozesse/Daten des Servers zu visualisieren. Dazu werden so genannte munin-nodes installiert (die zu überwachenden Server). Diese Nodes werden dann auf dem Munin-Server aggregiert, verarbeitet und Visualisiert.

Munin statistic graphs

Standardmäßig bietet Munin Statistiken zu:

Eine sehr schöne Eigenschaft von Munin ist, dass dieses Tool pluggable ist, d.h. es können verschiedene Skripte eingebunden werden. Wenn man Rails-Applikationen mit Phusion Passenger laufen lässt, stehen auf Github zwei nette Skripte zur Verfügung die man einfach in Munin einbinden kann. Mehr zu Munin-Plugins kann man in diesem Blogpost nachlesen.

Quasi-Echtzeitstatistiken mit glTail

Eine nette Ergänzung zur Überwachung von Webapplikationen ist gltail. Gltail bietet eine (quasi-)Echtzeit Darstellung von log-Files jeder Art. Dies kann natürlich dazu verwendet werden, um z.B. die Apache-Logs, Production-logs, etc. zu visualizieren.

glTail

[edge Rails] the rails command now supports templates

Setting up a new Rails project is pretty boring. Installing plugins, gems, adding initializers, etc. always the same monotonous work. - not fun. 

That’s why there have been quite a lot of starter apps. Most of them are git repositories with blank Rails apps bundled with plugins and extensions. But those are unflexible and the cloning of different repos somehow feels not right. - it’s better but still not fun. 

I’ve also tried to avoid the boring setup work with several tools. My first very, very hackish attempt was kickrails. A stupid ruby script that preceduraly runs all the build commands for me. - not fun either.

But then came RG. An awesome über cool project developed by Jeremy McAnally. RG allows you to kickstart your Rails app using templates written in ruby. - fun! ;) One command and your done. RG runs the rails command and setups all the stuff to get you started based on templates.

I’ve created a fork, added some more helpers and used it for several projects. It turned out great. 

Anyway what I wanted to tell is: RG just got added to Rails core. This means the rails command now supports templates for building your inital apps. Running rails -m/–template my_super_cool.template not only generates the default rails skeleton for you but also applies the template which installs plugins, gems, extensions, initializes a git repository, etc.  - pretty awesome - fun! 

I’m as excited as I’ve been when I’ve ran the rails command for the first time. 

How do you setup your rails app? Now compare that to:
RG template
Isn’t rails great?!

 

cool stuff on GitHub: sintaxi’s gap

phonegap.com: ”bridging the gap between the web and the iphone SDK”

“PhoneGap is a free open source development tool and framework that allows web developers to take advantage of the powerful features in the iPhone SDK from HTML and JavaScript. We’re trying to make iPhone app development easy and open. For many applications a web application is the way to but in Safari you don’t get access to the native iPhone APIs, and the that’s the problem we’re trying to solve.”

Get the source from GitHub.