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!

No related posts.

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.

No related posts.

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.

No related posts.

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!

No related posts.

  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.

No related posts.

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 /

Die erste Zeile aktiviert das Modul und die zweite setzt den Basis-Pfad, für den die folgende Rewrite-Konfiguration dienen soll. Möchten wir beispielsweise nur für das Verzeichnis /homepage/blog/ eine Weiterleitung erstellen, benötigen wir folgende Einstellung:

RewriteEngine on
RewriteBase /homepage/blog/


Als nächstes definieren wir unsere Regel für die Weiterleitung. Diese beinhaltet das Suchmuster und den Ersatz, d.h. die Original-Url und die neue Adresse der URL-Weiterleitung. Das tolle ist, das hier Reguläre Ausdrücke verwendet werden können. Die Syntax ist wie folgt:

RewriteRule <suchmuster> <ersatz>


Eine Domain-Weiterleitung mit mod_rewrite würde zum Beispiel so aussehen:

RewriteRule ^(.*)$ http://www.neuedomain.de/$1 [R=301,L]


Eine Weiterleitung eines Verzeichnisses so:

RewriteRule ^homepage/blog(.*)$ http://www.neuedomain.de/homepage/blog$1 [R=301,L]


Das mit dem Modul Rewrite noch mehr Möglichkeiten z.B. dynamischer Weiterleitungen bestehen, verdeutlicht folgendes Beispiel:

RewriteRule ^([a-z\-]+)/([a-z\-]+)/(.*)$ http://www.neuedomain.de/$3?site=$1&sub=$2 [R=301,L]


Jede Regel ist aber vorher gut zu durchdenken, da bei Fehlkonfiguration die Performance des Apache in Mitleidenschaft gezogen oder sogar zum Absturz, z.B. durch Endlosschleifen, gebracht werden kann. Mehr Informationen und viele Möglichkeiten mehr gibt es in der mod_rewrite Apache-Doku.

Andere Möglichkeiten einer Weiterleitung

Ist mod_rewrite nicht installiert, oder keine Berechtigung zur Benutzung gegeben, müssen andere Lösungen her.

Weiterleitung mit PHP

Mit PHP könnte man oben beschriebene Weiterleitungen mit Hilfe der header-Funktion lösen.

<?php
header('HTTP/1.1 301 Moved Permanently', true);
header('Location: http://www.neue-url.de/pfad/zur/datei.htm', true);
?>

Weiterleitung mit Perl / CGI

Auch mit Perl könnte man die Weiterleitung mit Hilfe eines Headers direkt per print lösen:

#!/usr/bin/perl

print "HTTP/1.1 301 Moved Permanently\n";
print "Location: http://www.neue-url.de/pfad/zur/datei.htm\n";

Weiterleitung mit Ruby

In Ruby kann man dies zum Beispiel so realisieren:

#!/usr/bin/env ruby

require 'cgi'
cgi.header({'HTTP/1.1 301 Moved Permanently','Location'=>'http://www.neue-url.de/pfad/zur/datei.htm'})

Clientseitig ohne 301-Status: Javascript

Eine clientseitige Weiterleitung könnte mit Javascript realisiert werden. Nachteil ist hier, das bei deaktiviertem Javascript die Weiterleitung nicht funktioniert.

<script type="text/javascript">
<!--
window.location.replace("http://www.neue-url.de/pfad/zur/datei.htm");
// -->
</script>

Clientseitig ohne 301-Status: Weiterleitung per Meta-Tag

Hierfür wird im Head Bereich des HTML-Codes ein Meta-Tag eingefügt, der durch Semikolon getrennt die Zeit angibt, die der Browser bis zur Weiterleitung warten soll und die URL des Ziels der Weiterleitung. Auch diese methode empfehle ich nicht, da dies wie auch Javascript Interpretationssache des Browsers ist, diesen tag zu beachten (Wobei alle Standard-Browser dies tun).

<head>
<meta http-equiv="refresh" content="3; url=http://www.neue-url.de/pfad/zur/datei.htm">
<!-- andere Tags im Header -->
</head>

Meine Empfehlung: Immer mod-rewrite nutzen, da serverseitig, gut konfigurierbar und vielseitig einsetzbar. Sollte dies nicht vorhanden oder möglich sein, können die anderen genannten Möglichkeiten einer Weiterleitung (PHP oder andere serverseitige Script- bzw. Programmiersprache, Javascript, Meta-Tag – in der Reihenfolge) weiterhelfen.

Happy Redirecting!

No related posts.