man bedim len?

Seit einiger Zeit nutze ich für ein paar Feeds ein Perlskript mit dessen Hilfe ich Feeds aus einem Blog im Twitter verlinke. Das Skript heisst originellerweise dann auch feed2twitter.pl . Das Skript wird von Hand über die Shell oder über Cron aufgerufen.

Ein Beispielaufruf könnte so aussehen:

   ./feed2twitter.pl --twitter=xwolf --feed=http://blog.xwolf.de/tag/piraten/feed/ --hashtag=piraten --quiet

Das Skript ließt dabei zunächst den Feed meines Blogs in der Kategorie “Piraten” ein. Danach nimmt es den Titel jedes Artikels und die URL um daraus eine Twitternachricht zu erzeugen. Die Nachricht wird dann auf meinen Twitteraccount gepostet.

Wenn Artikel und URL länger sind als 140 Zeichen, wird der Bestandteil des Titels optional gekürzt. Um zu verhindern, daß bei mehreren aufeinander folgenden Aufrufen über Cron dieselben Artikel nochmals getweetet werden, speichert das Skript ein Index aller bereits gesendeten Artikel ab.

Das Skript ist kann ab sofort bei Github heruntergeladen werden: https://github.com/xwolfde/feed2twitter

Zum Einsatz ist sehr wahrscheinlich die Nachinstallation des Perlmodules Net::Twitter::Lite notwendig. Ausserdem muss man die eigene Kopie des Skriptes bei https://dev.twitter.com/ registrieren um sich einen eigenen  API-Key, einen Consumer-key und den Consumer-Schlüssel zu besorgen.

Es ist möglich, unterschiedliche Feeds und unterschiedliche Twitter-Accounts zu nutzen. Ein möglicher Einsatzzweck des Skriptes wäre daher z.B. auch der, Artikel verschiedener Blogs oder mit RSS-publizierte Nachrichten abzurufen und über ein gemeinsamen Twitter-Account zu promoten.

Eventhinweis:
Vom 19.10.2011 bis 21.10.2011 findet im Frankfurt der nächste deutsche Perl-Workshop statt.

Weitere Informationen finden sich auf der Website vom YAPC.

Die Call for Paper-Phase ist derzeit offiziell eröffnet: Call for Papers / Participation. Vorträge können bis zum 14.08. eingereicht werden.

Für den Kongress JavaZone 2010 wurde dieses Jahr ein nettes Musicvideo gemacht:

Ganz nett.
Aber mal ehrlich: Sagt das Video nicht eine ganze Menge über Java-Coder aus? Das Video gibt da ja einige treffliche Tipps. Anlehnungen an den Film Matrix zum Beispiel. (Wie alt ist der Film noch? 10 Jahre?). Um in der Szenerie von Matrix zu bleiben: Die Java-Coder sind danach also die Leute, welche die blaue Pille nahmen, am nächsten morgen in ihrem Bett aufwachten und zurück zu ihrer Arbeit bei einem Software-Unternehmen gingen. Dort blieben sie den Rest ihres Lebens und hakten auf ihren Tastaturen rum, während sie mit (virtuellem) Zuckerbrot und Peitsche getrieben werden.
Irgendwie gefällt mir diese Interpretation :=)

Um noch ein Contra zu geben, hier ein Video über Perl.
Dieses Video ist dann auch kein digitales, virtuelles Chaos in der Programmiersklaven getrieben werden.

Perl ist halt was für echte Menschen, mit Herz und Gefühl.

Wer mehrere Webauftritte auf unterschiedlichen Plattformen betreibt, hat mitunter das Problem, das selbe Texte auf verschiedenen Auftritten stehen sollen. Diese möchte man aber natürlich nicht dauernd kopieren oder mehrfach pflegen.

Auf Basis der Perl-Module HTML::TreeBuilder und LWP::UserAgent hab ich daher ein Skript geschrieben, welches definierte Webseiten einließt und über ein SSI-Befehl dann in der jeweiligen Seite anzeigt: import-url.pl.

Das Skript besteht aus drei Teilen: Zuerst wird die Liste der auszulesenden URLs aus einer CSV-Datei eingelesen. Welche dieser URL eingebunden wird, liefert die ID, welche im Aufrufparameter des Skriptes liegt. Eine direkte Angabe der URL wäre zu gefährlich, da ansonsten Dritte beliebige URLs importieren könnten, bzw. die Webseite für ungewollte Webpipes ausnutzen könnten.
Im zweiten Teil wird über LWP die URL ausgelesen:

 	use LWP::UserAgent;
    	my $ua = LWP::UserAgent->new;
    	$ua->agent($CONST{'Agentname'});
    		# Create a request
    	my $req = HTTP::Request->new(GET => $url);
	    	# Pass request to the user agent and get a response back
    	my $res = $ua->request($req);
	    	# Check the outcome of the response
	my $plaincontent;
    	if ($res->is_success) {
      		$plaincontent = $res->content;
        } else {
       	 	return "No response";
        }

Der Inhalt wird dann mit HTML::TreeBuilder analysiert.
Die Webseiten, die ich betreibe haben eine klar definierte Semantik, in der der eigentlich Inhalt von einem <div id=”content”> … </div> umschlossen wird. Danach suche ich um alle Teile der Webseite wegzulassen, die bspw. Menu oder Metainformationen enthalten:

	use HTML::TreeBuilder;
	my $tree = HTML::TreeBuilder->new;
	$tree->no_space_compacting(1);
	$tree->parse($htmltext);
	$tree->eof;

	my $subpart;
	my $bereich = $tree->look_down('_tag', 'div',
		sub {
			return unless $_[0]->attr('id') =~ /content/;
		}
	)	;
	my $out = join  '', map(
		ref($_) ? $_->as_HTML(undef,undef,{}) : $_,
		$bereich->content_list
	);
	if (not $out) {
		$out=$bereich->as_HTML;
	}
	$tree->delete;

Die Variable $out enthält somit den Inhalt der Seite.
Wenn die Seite keine Bilder oder Links enthielte, wäre ich damit fertig. Diese muss ich aber noch anpassen.
Dazu suche ich in einer while()-Schleife und ein paar Regular Expressions einfach nach den Vorkommen von src=”" und href=”" innerhalb der HTML-Tags.
Das sieht dann im wesentlichen so aus (Beispiel nur für die Suche nach Links):

		while ($content =~ /href="([^"]+)"/i)  {
			$link =$1;
			$pre = $`;
			$post = $';

			if (($link =~ /^\//i)  && ($link !~ /^([a-z]+):\/\//i) && ($link !~ /^mailto/i)) {
				$link = "href=\"".$base.$link."\"";
			} elsif (($link !~ /$base/i) && ($link !~ /^([a-z]+):\/\//i) && ($link !~ /^mailto/i)) {
				$link = "href=\"".$uripath."/".$link."\"";
			} else {
				$link = "href=\"$link\"";
			}
			$content = $post;
			$tcontent .= "$pre$link";
		}
		$tcontent .= $content;

$content ist der HTML-Text, $content ist dabei das Ergebnis. Ausgehend von der ursprünglichen URL verfüge ich ausserdem über die beiden Variable $base und $uripath, welche die Adresse der Website und die URI der Seite enthalten.

Das Skript ließe sich nun noch leicht erweitern. Zum Beispiel über spezifische RegExp pro einzulesender URL oder auch um eine noch genauere Filterung des Inhaltes nach anderen Bereichen.

Die Erstellung von Webseiten erfolgt im Wesentlichen durch die Sprache HTML, welche primär der
Dokumentengestaltung übernimmt. Die Grundsyntax und die Semantik von HTML werden vom
World Wide Web Consortium (W3C) in den HTML-Normen festgelegt.
Obwohl diese Normen durch die verschiedenen Browserhersteller oft erweitert werden, bleiben
die funktionelle Möglichkeiten von HTML auf denen einer statischen Oberfläche.

Interaktivität, wie z.B. die Verarbeitung (aber nicht die Ausgabe!) von Formularen obliegt
anderen Mechanismen, welche wir im Folgendem vorstellen werden.

Clientseitige Mechanismen

Clientseitige Mechanismen sind Programme, bzw. Skripten, welche auf dem Rechner desjenigen ausgeführt
werden, welcher eine Seite abruft, in der Aufrufe dieser Skripten getätigt werden. Der Webserver
auf dem die Seiten liegen, wird also nicht durch diese Skripten belastet. Allerdings sind dadurch die
meisten Anwendungen, die auf Datenbanken arbeiten, nicht möglich.

Folgende Tabelle zeigt die derzeitig üblichen Verfahren im Überblick:

Serverseitige Mechanismen

Serverseitige Mechanismen sind Funktionen und Programme, die vom Webserver ausgeführt werden
und dessen Ausgaben an den Gast der Webseite weitergeleitet werden. Im Gegensatz zu clientseitigen
Mechanismen obliegt es allein dem Server alle nötigen Zugriffe zu machen, so daß dieser
auch die Last trägt.

Serverseitige Mechanismen bieten aber den Vorteil, daß die Datenhaltung zentral ist und
die Ausgaben unabhängig von dem verwendeten Browser sind. Eine Kombination von Serverseitigen
mit Clientseitigen Mechanismen ist zudem möglich und üblich. (Zum Beispiel beim Einsatz von
komplexen Online-Umfragen).

Obwohl sich inzwischen nur mehr 4 Servertypen durchgesetzt haben (Apache, Novell, Microsoft IIE,
Netscape), ist die Zahl der verfügbaren Mechanismen um einiges größer.
Aber auch hier sind schon Trends feststellbar. Die folgende Tabelle zeigt die derzeit am häufigsten
verwendeten Techniken und Standards für die clientseitige Ausführung: