Artikel der Kategorie Webentwicklung
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.
Eben entdeckt: Bei Ubuntu und Debian ist in PHP standardmässig die Garbage Collection deaktiviert. Diese sorgt dafür, das die Sessionfiles für abgelaufene Sessions automatisiert gelöscht werden. Bei Ubuntu und Debian löst ein Cronjob diesen Löschvorgang.
Ein Problem entsteht allerdings, wenn man eigene Verzeichnisse für die Sessionfiles definiert. Hier werden die Files dann nicht gelöscht und bleiben bestehen, was das Verzeichnis – je nach Traffic – schnell auf ein paar Tausende Dateien anwachsen lassen kann.
Um die Garbage Collection in PHP zu aktivieren, muss folgender Eintrag in der php.ini (für Apache unter /etc/php5/apache2/php.ini) geändert werden:
VORHER
;session.gc_probability = 0
session.gc_divisor = 100
NACHHER
session.gc_probability = 1
session.gc_divisor = 100
Diese Änderung bewirkt, das bei jedem hundertsten Start einer Session die Sessionfiles gelöscht werden.
Zusätzlich muss dann noch der Cronjob deaktiviert werden. Hierzu einfach /etc/cron.d/php5 mit dem Editor deiner Wahl bearbeiten und die letzte Zeile auskommentieren:
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime
# Look for and purge old sessions every 30 minutes
#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
Was der Grund für diese Deaktivierung bei Ubuntu oder Debian war konnte ich auf die Schnelle nicht herausfinden, werde es aber in einem Update nachliefern.
Wenn in Linux-Distributionen solche Änderungen vorgenommen werden, sollte man aber passende Toolsets liefern, um alle Variationen abzufangen. So ist das nur eine halbe Sache, wenn ich nichts übersehen habe. Der Bug wurde auch schon im Ubuntu-Bugtracker aufgenommen, aber noch keinem zugeordnet.
Weiterführende Links:
Mit Hilfe von Cronjobs können auf Unix- und Linux-Systemen Vorgänge automatisert und zu einem bestimmten Zeitpunkt immer wiederkehrend ausgeführt werden. Diese Vorgänge können einzelne Befehle, Shell-Scripts, Programme, PHP- und sonstige Scriptsprachen-Scripts oder auch eine Anreihung von Linux-Befehlen sein. Beispielsweisse werden Backups, die täglich oder sogar stündlich geschehen sollen meist per Cronjob ausgeführt.
Weiterlesen >>
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!
Für Webentwickler ist es immer wichtig zu wissen, welche Browser am meisten genutzt werden. Bisher war dies immer der Internet Explorer in der Version 6 oder 7. Doch seit einigen Wochen oder sogar Monaten hat sich der Firefox in der Version 3.5 den ersten Platz erkämpft. Mit dem heutigen Datum sieht die Top 5 der meist genutzen Browser laut der 4stats Browser Statistik mit Version so aus:
1. 26.20% Firefox 3.5
2. 17.42% Internet Explorer 8.0
3. 16.96% Internet Explorer 7.0
4. 13.23% Internet Explorer 6.0
5. 11.56% Firefox 3.0
Safari liegt mit 3.44% auf Platz 7, gefolgt von Opera (1.9%) und Google Chrome (1.7%).
Der Wechsel an die Spitze ist sicher auf die Schnelligkeit des Firefox und den wachsenden Bekanntheitsgrad zurückzuführen. Wir dürfen gespannt sein, ob es bei einem erneuten Versions-Update des Firefox so bleibt und ob der Internet Explorer dank Windows 7 vielleicht doch Platz 1 wieder in Beschlag nimmt. In der Browser Statistik der Marktanteile ohne Versionsnummer ist der Internet Explorer mit fast 48% immer noch auf Platz 1. Aber auch hier ist der Firefox mit ca. 40% dicht dran. Das Rennen der Browser geht weiter!
Seit gestern ist eine Schwachstelle in Ruby On Rails bekannt, die dem Angreifer über Cross-Site-Scripting (XSS) ermöglicht, HTML-Code in die betroffene Webseite bzw. Applikation zu integrieren. Betroffen sind alle Ruby On Rails Versionen ab 2.0.0. Nicht betroffen sind Applikationen, die unter Ruby Version 1.9 laufen. Aktuelle Patches, sowie Fixes für die Versionen 2.3.4 und 2.2.3 sind bereits veröffentlicht.
Die Schwachstelle befindet sich in den Escaping-Funktionen der Form-Helper. Der Angreifer kann durch manipulierte Unicode-Strings die Escaping-Prüfungen umgehen und so beliebiges HTML injecten.
An alle die Rails im Einsatz haben: Bitte umgehend updaten!
gem update
Brian Mastenbrook, der die Lücke entdeckt hat, hat eine Injection bei Twitter innerhalb 15 Minuten geschafft und sofort Twitter und 37signals (Bekannte Rails-Entwickler-Company rund um das Rails-Mastermind David Heinemeier Hansson) benachrichtigt. Wie Brian schreibt, hat 37signals weder einen Ansprechpartner für Sicherheit, noch angemessen auf seine Hinweise per Mail reagiert, was mich doch etwas enttäuscht. Erst eine Mail an das Security-Team von Ruby On Rails brachte den Stein ins Rollen.
Links:
- Offizielle Security-Meldung von RubyOnRails inkl. Patches und allen Infos
- Blog-Post von Brian Mastenbrook
- Update: Offizieller Blog-Post auf der Ruby On Rails Webseite
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.
Am 9. April 2009 gibt es viele nackte Webseiten zu sehen, wenn es wieder heisst “CSS Nackig Tag” – Webseiten sind auch ohne Design leserlich. Die Idee dahinter ist, den Webstandard, genauer den korrekten Gebrauch von (X)HTML, semantischem Markup, hierarchischer Struktur und den Inhalt zu fördern.
An diesem Tag werden alle teilnehmenden Webseiten Ihre Stylesheets entfernen, die das Design jeder Webseite festlegen. Anmelden kann man sich leider nicht mehr, mitmachen aber trotzdem. Ich bin dabei!
Mehr Informationen, sowie Tools und Verweise auf WordPress-Plugins gibt es hier in deutsch und hier in englisch im Original.
Wenn man PHP-Code bzw. bestehende oder neue PHP-Dateien in WordPress einbinden möchte, macht man das am besten im aktuellen Theme von WordPress. Man legt ein sogenanntes Seiten-Template an, welches man bei der Bearbeitung der Seite in WordPress wählen kann. In diesem Template befindet sich dann das gewünschte PHP-Script. 
