Artikel mit dem Tag ruby
Aktuell stelle ich mir oft die Frage, ob ich Software für WordPress entwickle oder eine eigene Anwendung in Ruby on Rails schreibe. Beides hat seine Vor- und Nachteile. Ich entwickle seit 10 Jahren Software in PHP, seit etwa 5 Jahren auch in Ruby on Rails, was ich aufgrund seiner vielen bekannten positiven Eigenschaften bei komplett neuen Anwendungen auf jeden Fall vorziehen würde. Aus diesem Grund stellt sich mir diese Frage, obwohl Rails und WordPress auf den ersten Blick ja nicht unbedingt in der gleichen Kategorie von Tools anzusiedeln sind, auf den zweiten aber beides Frameworks mit ähnlichen Voraussetzungen sind.
WordPress hat eine riesige Community, viele Nutzer und einen hohen Bekanntheitsgrad. Wenn man beispielsweisse ein WordPress-Plugin schreiben möchte, kann man sich durch schon vorhandene Plugins wuseln und von bestehendem Code Anregungen holen und evtl. sogar Teile verwenden – natürlich nur unter Einhaltung des Copyrights. Möchte man dieses Plugin verkaufen, hat man mit WordPress eine sehr große und täglich wachsende Menge an potenziellen Kunden. Ein weiterer Vorteil ist die große Menge an Einsatzgebieten von WordPress. WordPress kann als Blog verwendet werden, als normale Webseite mit oder ohne CMS, als Forum, als Gallery, als Community und und und. Das meiste natürlich mit fertigen Plugins. Warum also etwas eigenes entwickeln, wenn es alles schon gibt? Zumal ja fast jede Webseite sowieso einen Blog und somit auch WordPress hat und benötigt. Die Nachteile bei WordPress liegen ganz klar bei der mangelnden Performance und – für mich persönlich – an der etwas veralteten Scriptsprache PHP. Logisch kann man die Performance mit ein paar Tricks, passenden Plugins und besserer Server-Hardware tunen, dennoch ist WordPress den eigenen Lösungen in PHP oder Ruby On Rails klar unterlegen. Gerade wenn der Content in der Datenbank wächst – und ich meine hiermit eine Menge von 1000+ Artikeln – wird WordPress zur Slow-Motion-Bremse.
Ruby on Rails ist hingegen, wenn man es richtig anstellt, ein richtiger Turbo und Spaßfaktor. Das Coden in Ruby macht einfach einen Riesenspaß, was die Produktivität um einiges steigert. Das DRY-Prinzip richtig angewendet, muß hier bei gleicher Funktionalität auch weniger Code geschrieben werden. Man kann also sagen, das mit Rails einfacher in hoher Qualität Software entwickelt werden kann. Ebenso gibt es für fast alle Belange fertige Plugins und Librarys, die man beliebig erweitern und verwenden kann. Die Menge der Entwickler ist zwar hoch und wird immer höher, aber es gibt lange noch nicht so viele wie für WordPress. Ruby On Rails wird eher von Profis eingesetzt, Hobby-Entwickler hingegen greifen schnell zu PHP und WordPress. Desweiteren benötigt man für Rails immer eine gesonderte Server-Konfiguration, weshalb die meisten bekannten Webhoster hier ausscheiden. Noch ein negativer Punkt ist, das es für Rails keine gute Blog-Software gibt. Zwar sind einige wenige Versuche vorhanden, die an WordPress jedoch bei weitem nicht heranreichen. Schade eigentlich, eine gute Blog-Software in Ruby wär was feines und sicher ein schönes Projekt.
Also bleibt ganz klar eines zu sagen. Möchte man Software vielen Millionen Menschen verfügbar machen oder womöglich verkaufen, empfiehlt sich der Einsatz von WordPress. Legt man jedoch Wert auf Performance, Spaß beim Coden und hat Profis zur Hand, ist Rails eine gute Wahl. Also ist meine erste Überlegung in der Richtung ab jetzt: “Möchte ich die Software nur für mich oder auserwählte Kunden nutzen oder an tausende Kunden verkaufen?”.
Was meint Ihr dazu? Lieber WordPress oder Rails bzw. anderen Sprachen oder Frameworks? Freu mich über Kommentare!
Oft kommt es als Webmaster vor, das man eine Liste mit URL’s auf Fehler prüfen muß. Um zum Beispiel eine Liste mit URL’s auf tote Links bzw. 404 Not Found Fehler zu prüfen, kann man folgendes in Ruby geschriebene Script zu Hilfe nehmen. Das Script fällt in die Kategorie Quick Hack und ist unbedingt ausbaufähig.
require 'net/http'
def check_for_notfound(url)
uri = URI.parse(url)
response = Net::HTTP.get_response(uri)
case response
when Net::HTTPNotFound:
return true
when Net::HTTPRedirection:
puts check_for_notfound('http://' + uri.host + response['location'])
else
return nil
end
end
File.open(ARGV[0]) do |f|
f.each do |line|
result = check_for_notfound(line)
if !result.nil? and result == true
puts line
end
end
end
Wer ein besseres Script hat oder etwa eine Möglichkeit weiß, wie man dies mit wget lösen kann, bitte einen Kommentar hinterlassen. Danke!
Update:
Wie ich Dank eines anderen Blogs erfahren konnte, ist das mit wget natürlich auch schnell und sogar mit einem Einzeiler lösbar:
wget -r -nd --delete-after --no-parent --no-cookies --input-file=urls.txt
Ob man nun Ruby oder wget nutzt, hängt ganz davon ab, ob man es in eine Software integrieren möchte oder ob es nur einem schnellen administrativen Todo dienen soll.
Sinatra hat offiziell den Landmark Release 1.0 erreicht. Das schmale Web Application Framework ist eine echte Alternative zu Ruby On Rails, insbesondere wenn man kleinere und schnellere Projekte erstellen möchte.
Ich selbst habe es einige Male getestet, aber aus Zeitmangel für’s Lernen leider noch nicht im Einsatz.
Eine einfache Webseite ist in Sinatra leicht geschrieben:
require 'rubygems'
require 'sinatra'
get '/hi' do
"Hello World!"
end
Mehr Infos unter http://www.rubyinside.com/sinatra-1-0-released-3162.html.
Wer auf die Twitter-API zugreift kennt das Problem des ständigen Polling der API, d.h. man muß in der Software mit Hilfe von Cronjobs oder ähnlichem aller paar Sekunden nach neuen Tweets schauen.
Das hat sich letztes Jahr zum Glück mit der Twitter Streaming API geändert. Nun kann man per Stream auf die Tweets zugreifen, eine tolle Sache!
Um den Stream mit Ruby zu nutzen gibt es ein Gem von Intridea genannt TweetStream. Mit diesem Gem ist es sehr einfach möglich Tweets zu lesen, sogar ein Daemon ist enthalten.
require 'rubygems'
require 'tweetstream'
# The third argument is an optional process name.
TweetStream::Daemon.new('user','pass','tracker').track('keyword1','keyword2') do |status|
# Do something like dump the status to ActiveRecord
# or anything else you want.
end
Wo man es herbekommt, wie man es installiert und nutzt erklären Sie in Ihrem Blog:
TweetStream: Ruby Access to the Twitter Streaming API
Happy Streaming!
Die tolle Ruby-Funktion time_ago_in_words bzw. distance_of_time_in_words und distance_of_time_in_words_to_now aus dem Rails-Framework zeigt die vergangene Zeit seit einem bestimmten Zeitpunkt in Worten an. Wer das Ganze für Rails-Versionen kleiner 2.2 in deutsch haben möchte, kann folgende ins Deutsche übersetzte Funktion einfach in den ApplicationHelper unter app/helpers/application_helper.rb einfügen:
def distance_of_time_in_words(from_time, to_time = 0, include_seconds = false)
from_time = from_time.to_time if from_time.respond_to?(:to_time)
to_time = to_time.to_time if to_time.respond_to?(:to_time)
distance_in_minutes = (((to_time - from_time).abs)/60).round
distance_in_seconds = ((to_time - from_time).abs).round
case distance_in_minutes
when 0..1
return (distance_in_minutes == 0) ? 'weniger als einer Minute' : 'einer Minute' unless include_seconds
case distance_in_seconds
when 0..4 then 'weniger als 5 Sekunden'
when 5..9 then 'weniger als 10 Sekunden'
when 10..19 then 'weniger als 20 Sekunden'
when 20..39 then 'einer halben Minute'
when 40..59 then 'weniger als einer Minute'
else '1 Minute'
end
when 2..44 then "#{distance_in_minutes} Minuten"
when 45..89 then 'ca. 1 Stunde'
when 90..1439 then "ca. #{(distance_in_minutes.to_f / 60.0).round} Stunden"
when 1440..2879 then '1 Tag'
when 2880..43199 then "#{(distance_in_minutes / 1440).round} Tagen"
when 43200..86399 then 'ca. 1 Monat'
when 86400..525599 then "#{(distance_in_minutes / 43200).round} Monaten"
when 525600..1051199 then 'ca. 1 Jahr'
else "#{(distance_in_minutes / 525600).round} Jahren"
end
end
Nicht über den Funktions-Namen wundern, time_ago_in_words ist ein Alias für distance_of_time_in_words.
Update:
Viel einfacher wäre es natürlich, die I18n-Funktionen, die ab der Rails-Version 2.2 oder besser 2.3 enthalten sind zu nutzen. Hierfür muß man einfach in der Datei config/environment.rb den String
config.i18n.default_locale = :de
(nach Rails::Initializer.run do |config| und vor end) einfügen und eine Datei unter config/locales/de.yml mit folgendem Inhalt anlegen:
# German translations for Ruby on Rails
# by Clemens Kofler (clemens@railway.at)
de:
datetime:
distance_in_words:
half_a_minute: 'eine halbe Minute'
less_than_x_seconds:
zero: 'weniger als 1 Sekunde'
one: 'weniger als 1 Sekunde'
other: 'weniger als {{count}} Sekunden'
x_seconds:
one: '1 Sekunde'
other: '{{count}} Sekunden'
less_than_x_minutes:
zero: 'weniger als 1 Minute'
one: 'weniger als eine Minute'
other: 'weniger als {{count}} Minuten'
x_minutes:
one: '1 Minute'
other: '{{count}} Minuten'
about_x_hours:
one: 'etwa 1 Stunde'
other: 'etwa {{count}} Stunden'
x_days:
one: '1 Tag'
other: '{{count}} Tage'
about_x_months:
one: 'etwa 1 Monat'
other: 'etwa {{count}} Monate'
x_months:
one: '1 Monat'
other: '{{count}} Monate'
about_x_years:
one: 'etwa 1 Jahr'
other: 'etwa {{count}} Jahre'
over_x_years:
one: 'mehr als 1 Jahr'
other: 'mehr als {{count}} Jahre'
prompts:
second: "Sekunden"
minute: "Minuten"
hour: "Stunden"
day: "Tag"
month: "Monat"
year: "Jahr"
Quelle: Original-Datei mit noch mehr Übersetzungen (auch für Active-Record-Messages und in anderen Sprachen) gibt es hier.
Bild von Darren Hester auf flickr.
Wenn sich die Domain oder Url einer Website geändert hat, empfiehlt sich eine Weiterleitung auf die neue Adresse mit dem HTTP-Statuscode 301 (Moved Permanently). Der Code 301 deshalb, damit auch Suchmaschinen wie Google wissen, das sich die Adresse für immer geändert hat und nur die neue Url verwendet werden soll. Google berücksichtigt hier auch den Pagerank und ordnet diesen der neuen URL zu.
Die Technik
Technisch gesehen werden vom Webserver im HTTP 2 Zeilen an den Client (Nutzer mit Browser, Suchmaschine) gesendet. Eine mit dem Statscode und eine mit dem Ziel der Weiterleitung:
HTTP/1.1 301 Moved Permanently
Location: http://www.neue-url.de/pfad/zur/datei.htm
Eine HTTP-Sitzung per Telnet auf Port 80 sieht dann zum Beispiel so aus:
# telnet alte-domain.de 80
Trying 12.34.56.78...
Connected to alte-domain.de.
Escape character is '^]'.
GET / HTTP/1.1
Host: alte-domain.de
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Feb 2009 20:06:55 GMT
Server: Apache/2.2.11
Location: http://neue-domain.de/
Content-Length: 225
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://neue-domain.de/">here</a>.</p>
</body></html>
Connection closed by foreign host.
mod_rewrite – die Lösung
Um dies mit Hilfe des Webservers Apache zu lösen, hilft uns das Modul Rewrite, kurz mod_rewrite. Hat man Zugriff auf die Konfigurationsdatei des Webservers, kann man die Rewrite-Weiterleitung im VirtualHost, in der Directory- oder Location-Direktive vornehmen. Anonsten erstellt man eine .htaccess-Datei und nimmt die Konfiguration hier vor.
Um mod_rewrite zu aktivieren, benötigen wir folgende zwei Zeilen:
RewriteEngine on
RewriteBase /
Weiterlesen >>
Hola! Ich bin Nico und du liest gerade meinen Blog über Webentwicklung, Webdesign, Linux und alles was mit dem Internet zu tun hat. Seit 1997 entwickle ich Websites und habe in dieser Zeit in den verschiedensten Bereichen gearbeitet. Ob nun Webdesign, Software-Entwicklung, Server-Administration, Marketing und SEO, alles macht Spaß und ergänzt sich wunderbar. Neben diesem Blog betreibe ich noch diverse andere Projekte wie zum Beispiel die