Tweets via Twitter API mit C# versenden
Vor kurzem hatte ich geschrieben, wie man mit .NET und Visual Basic 2008 ein Tweet verschickt. Wegen der vielen Anfragen: ja, mit .NET und C# (und Microsofts Visual Studio 2008) sieht das fast identisch aus, nämlich so:
private void cmdSenden_Click(object sender, EventArgs e)
{
String TwitterUsername = „DeinTwitterUsername“;
String TwitterPasswort= „***“;
Byte[] UpdateNachricht, Antwort;//WebClient anlegen
WebClient myWebClient = new WebClient();//Except100 ausschalten, sonst gibt es u. U. Fehlermeldungen
System.Net.ServicePointManager.Expect100Continue = false;//Benutzername und Passwort als Credentials zuweisen
myWebClient.Credentials = new NetworkCredential(TwitterUsername, TwitterPasswort);//ggf. Sonderzeichen und Umlaute des zu sendenden Tweets richtig coden
UpdateNachricht = Encoding.UTF8.GetBytes(„status=“ + txtTweet.Text);try
{
//Antwort senden
Antwort = myWebClient.UploadData(„http://api.twitter.com/1/statuses/update.xml“, UpdateNachricht);
//Die Antwort von Twitter ausgeben (XML-Daten):
MessageBox.Show(System.Text.Encoding.ASCII.GetString(Antwort));
}
catch (Exception ex)
{
//Wenn es nicht klappt Fehler ausgeben
MessageBox.Show(ex.Message);
}} // private void cmdSenden_Click end
Import von System.Net nicht vergessen!
Tweets mit VB.NET senden (Visual Basic 2008)
Aufgrund meiner Artikel über Perl und Twitter wurde ich gefragt, ob dies so einfach auch mit .NET möglich wäre. Auch das ist ziemlich unkompliziert. Im Folgenden ein Beispiel, wie mit Visual Basic ein Twitter-Update verschickt werden kann (im folgenden Beispiel verwende ich Microsofts Visual Basic 2008 Express Edition , das ganze wäre mit C# sozusagen identisch).
Legen Sie dafür eine neue „Windows Forms-Anwendung“ an und legen Sie dort eine Textbox (txtTweet) und eine Button (cmdSend) wie dargestellt an:
Folgender Code sendet das Tweet in Twitter:
Private Sub cmdSenden_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdSenden.Click
Dim TwitterUsername, TwitterPasswort As String
Dim UpdateNachricht, Antwort As Byte()TwitterUsername = „DeinTwitterUsername“
TwitterPasswort = „***“‘WebClient anlegen
Dim myWebClient As New Net.WebClient‘Except100 ausschalten, sonst gibt es u. U. Fehlermeldungen
Net.ServicePointManager.Expect100Continue = False‘Benutzername und Passwort als Credentials zuweisen
myWebClient.Credentials = New Net.NetworkCredential(TwitterUsername, TwitterPasswort)‘ggf. Sonderzeichen und Umlaute des zu sendenden Tweets richtig coden
UpdateNachricht = System.Text.Encoding.UTF8.GetBytes(„status=“ + txtTweet.Text)Try
Antwort = myWebClient.UploadData(„http://api.twitter.com/1/statuses/update.xml“, UpdateNachricht)‘Die Antwort von Twitter ausgeben (XML-Daten):
MsgBox(System.Text.Encoding.ASCII.GetString(Antwort))Catch ex As Exception
‘Wenn es nicht klappt Fehler ausgeben
MsgBox(ex.Message)End Try
End Sub
WordPress Blogposts per Perl-Script modifizieren
Vor ein paar Tagen hatte ich beschrieben, wie man schnell und einfach per XML-RPC und der MetaWeblog API mit einem Perl Script einen neue Artikel in ein WordPress-Blog einfügt. Wie bereits kurz erwähnt hatte ich dabei ein Problem: Mit der MetaWeblog API habe ich es nicht geschafft, gleich beim Anlegen des Artikel die Kategorie festzulegen (und bin über jeden Tipp dankbar). Deshalb habe ich mit einer anderen API experimentiert, die WordPress ebenfalls kennt: Die Movable Type API von Sixapart. Hier ist dies mit „mt.setPostCategories“ problemlos möglich:
my $res2 = XMLRPC::Lite
->proxy($proxyurl)
->call(‘mt.setPostCategories’, $postid, $wpusername, $wppassword, [ {categoryId => $kategorie} ])
->result;
Die $postid ist ja bekannt, so dass der Code kombiniert mit dem Anlegen etwa so aussehen könnte:
#!/usr/bin/perl -w
use strict;
use XMLRPC::Lite;my $wpusername = „mustermann“;
my $wppassword = „meinpasswort“;
my $wpblogid = „meinblog“;
my $blogurl = „http://maxmustermann.wordpress.com/xmlrpc.php“;# Neuer Blogbeitrag
my $articeltext =“Hallo Blog, wie geht’s. Hier steht viel Text!“;
my $articeltitle =“Mein erster Blogbeitrag“;
my $articeldatum =“20100220T12:34:56″;
my $articelkeywords =“Hund, Katze, Maus“;my $rpcall = XMLRPC::Lite
->proxy($blogurl)
->call(‘metaWeblog.newPost’, $wpblogid, $wpusername, $wppassword,
{ description => $articeltext, title => $articeltitle, dateCreated => $articeldatum, mt_keywords => $articelkeywords}, 1)
->result;if (defined ($rpcall)) {
print „Erfolgreich – Artikel-ID: $rpcall \n\n“;
} else {
print „Fehler: $!“;
die();
}my $postid=$rpcall;
my $kategorie=47; # Kategorie-ID
my $rpcall2 = XMLRPC::Lite
->proxy($blogurl)
->call(‘mt.setPostCategories’, $postid, $wpusername, $wppassword, [ {categoryId => $kategorie} ])
->result;if (defined ($rpcall2)) {
print „Erfolgreich Kategorie gesetzt!\n\n“;
} else {
print „Fehler: $!“;
die();
}print „\n\n“;
Aber wie gesagt nur ein Workaround – eigentlich müsste dies in einem Schwung gehen.
Bugfix für WordPress Theme MistyLook durch CSS-Trick
Für kleine Blogprojekte setzte ich sehr gerne das nett gemachte WordPress Theme „MistyLook“ von Sadish ein. Leider hat dies einen kleine Bug: Verwendet man Bilder-Galerien, so wird der Schatten-Effekt durch ein Link-Border überdeckt, was ziemlich hässlich aussieht. Möchte man dies mit dem CSS User-Stylesheet Editor von WordPress beheben, steht man vor einem Problem. Fügt man
div #gallery-1 img { border-width:0px; }
ein, so bringt das leider gar nichts: Das CSS für die Gallery wird (vereinfacht gesprochen) erst nach dem User- und Theme-Stylesheet geladen und überschreibt so dies. Folgendes einfaches Beispiel illustriert das Problem:
<head>
<title>Test</title>
<style>/* Style 1: */
div #meintext strong { color:red; }/* Style 2 (nicht änderbar): */
div #meintext strong { color:green; }</style></head>
<body>
<div>
<span>Hallo <strong>Welt</strong></span>
</div>
</body>
Die kleine Rätselaufgabe: Sie möchten, dass das Wort „Welt“ rot dargestellt wird, dürfen jedoch weder die Definition „Style 2“ noch den HTML-Quelltext sondern nur die Zeile nach „Style 1“ verändern. Geht das? Read more…
Twitter mit Perl – Tutorial Teil II: Direct Messages versenden
Ein sinnvolle Erweiterung zu dem im Teil I vorgestellten Perl-Script, mit dem man direct messages via Twitter versenden kann wäre folgendes: Bevor man die direct message abschickt soll geprüft werden, ob der Empfänger mir überhaupt noch folgt – ansonsten kann ja keine direct message verschickt werden. So einfach geht das:
#zuerst prüfen, ob Empfänger noch mein follower?
$usera=“Simon_A_Frank“;
$userb=“kulturzwitscher“;
$response = $ua->get(„http://twitter.com/friendships/exists.xml?user_a=$usera&user_b=$userb“);if ($response->is_success) {
print „Noch follower: „.$response->content.“\n“;
} else {
print „Abbruch – kein Follower mehr (oder ein anderer Fehler): „;
print $response->status_line;
die();
}
Für die Überprüfung von Friendships / Follower ist übrigens nicht unbedingt ein Login erforderlich (nur bei Twitterusern mit geschützten Tweets).
Und hier nochmals den gesamten Code aus Teil I des Tutorials ergänzt um die Follower-Überprüfung:
#!/usr/bin/perl
use LWP::UserAgent;
my $ua = LWP::UserAgent->new;#sinnvolle LWP Settings
$ua->timeout(10);
$ua->env_proxy;# Empfänger
$form{user}=“Simon_A_Frank“;#Nachricht (max 140 Zeichen)
$form{text}=“Hallo Simon!“;#Absender – Twitteruser und Passwort
$twitteruser=“deintwitterusername“;
$twitterpw=“deinpw“;
$ua->credentials( „twitter.com:80″, „Twitter API“, $twitteruser => $twitterpw);#zuerst prüfen, ob Empfänger noch mein follower?
$usera=“Simon_A_Frank“;
$userb=“kulturzwitscher“;
$response = $ua->get(„http://twitter.com/friendships/exists.xml?user_a=$usera&user_b=$userb“);if ($response->is_success) {
print „Noch follower: „.$response->content.“\n“;
} else {
print „Abbruch – kein Follower mehr (oder ein anderer Fehler): „;
print $response->status_line;
die();
}#Erfolg – dann die direct message senden:
$response = $ua->post(„http://twitter.com/direct_messages/new.xml“,\%form );if ($response->is_success) {
#Hat geklappt!
print „DM erfolgreich verschickt!“;
} else {
#ging nicht …
print „Nicht erfogreich, Fehler: “ . $response->status_line;
}
Twitter mit Perl – Tutorial Teil I: Direct Messages versenden
In den letzten Wochen habe ich für unterschiedliche Kunden und Projekte diverse Twitter-Anbindungen entwickelt. Zu PHP gibt es viele Anleitungen, aber da ich cronjob-basierte Scripts traditionell gerne in Perl schreibe und viele Anfragen dazu hatte (insbesondere wegen dem Projekt kulturgezwitscher) hier ein kurzes Tutorial, wie man eine direct message senden kann:
Ich verwende LWP::User Agent mit folgenden Einstellungen:
#!/usr/bin/perl
use LWP::UserAgent;my $ua = LWP::UserAgent->new;
#sinnvolle LWP Settings – aber nicht unbedingt notwendig:
$ua->timeout(10);
$ua->env_proxy;
Hier stehen der Twitter-Benutzername und das Passwort des Absenders, der für das Login (credentials) benötigt wird:
#Absender – Twitteruser und Passwort
$twitteruser=“deintwittername“;
$twitterpw=“deintwitterpw“;
$ua->credentials( „twitter.com:80″, „Twitter API“, $twitteruser => $twitterpw);
Dann die Nachricht und den Empfänger bestimmen:
#Empfänger
$form{user}=“Simon_A_Frank“;#Nachricht (max 140 Zeichen)
$form{text}=“Hallo Simon!“;
Jetzt wird der Request gepostet und die Antwort von Twitter empfangen:
if ($response->is_success) {
#Hat geklappt!
print „DM erfolgreich verschickt!“;
} else {
#ging nicht … Fehlermeldung:
print $response->status_line;
}
Wenn es nicht geklappt hat kann es z. B. sein, dass der Empfänger kein Follower ist, dann sind natürlich keine direct messages möglich. Wie man dies abfragen kann gibt im nächsten Teil dieses Tutorials zu lesen.
Online-Kulturmarketing und klassische Musik
Ein wenig Werbung in eigener Sache: Vor einiger Zeit bin ich gefragt worden, ob sich meine Überlegungen zum Online-Kulturmarketing auch für den Bereich klassische Musik bzw. Orchester übertragen lassen. In der aktuellen Ausgabe des Magazins „das Orchester“ ist nun von mir eine Antwort auf diese Frage in Form eines kurzen Artikels mit dem Titel „Erst denken, dann webzweinullen“ erschienen (Details und Bestellmöglichkeit finden Sie auf der Website des Verlages).
P.S. Die Fußnoten mit Wikipedia-Zitaten hat der Verlag ergänzt…
Mashups für Kulturmarketing und Vermittlung?
Vor kurzen hatte ich bei einer Tagung der Gesellschaft für Geoinformatik einige Beispiel zeigen können, wie sich Mashups für Kulturvermittlung und Marketing einsetzten lassen. Die Vorteile, die in Mashups stecken liegen auf der Hand, jedoch wurde ich darauf hingewiesen, dass auch die Risiken und Probleme nicht ungenannt bleiben sollten. Dies konnte ich mangels Zeit leider nur am Rande (ausführlich dazu konnte ich mich auf einen Vortrag auf der MAI-Tagung vor zwei Jahren dazu äußern) und führe hier nochmals wichtige Vor- und Nachteile auf:
Zum einen gibt es bisher nur wenige APIs im Kulturbereich, da die meisten kulturellen Websites sind noch walled gardens sind, so dass der Austausch derzeit meist kompliziert ist. Wie meine in dem Vortrag genannten Beispiele zeigen müssen zum anderen viele Projekte im Kulturbereich erst eigene große Datenbanken aufbauen, um dann tatsächlich interessante Mashups erstellen zu können. Weitere Risiken können wie folgt skizziert werden:
- Es besteht immer die Gefahr, dass die Anbieter offener APIs die Nutzungsbedingungen ändern oder den Dienst ganz einstellen, so dass die API für das eigene Mashup nicht mehr eingesetzt werden kann;
- Es besteht ein Risiko, dass erfolgreiche und beliebte offene APIs nach einiger Zeit kostenpflichtig werden;
- Es besteht eine Abhängigkeit vom „Zulieferer“: die Nutzung der Dienste auf fremden Servern (Ausfälle, Performance) oder plötzliche Änderungen (z. B. Werbung);
- Mashups, die keinen eigenen Content einsetzten, können schnell nachgebaut werden oder vom API-Anbieter übernommen werden.
Vor allem der erste Punkt ist nicht zu unterschätzen. Trotzdem überwiegen die Vorteile, die sich in folgenden drei Punkten zusammenfassen lassen:
- Mehrwert: Neue, größtenteils kostenlose Inhalte (Karten, Bilder, etc.) können geschickt „vermischt“ Mehrwert erzeugen;
- Kostenersparnis: Die Nutzung vorhandener Applikationen (z. B. Geodaten/ Karten) spart hohe Eigenentwicklungskosten;
- Neue Besucher: Die Verlinkung mit der „Mashup-Community“ kann neue Wege zu (neuen) Besuchern eröffnen.
Als Fazit lässt sich deshalb abschließend sagen: Auch wenn Mashups bestimmt nicht für jedes Projekt im Kulturbereich geeignet sind, gerade weil es für „kulturelle“ Websites noch wenig leicht zugängliche Quellen gibt, können sinnvoll eingesetzte Mashups einen Mehrwert schaffen, um die Webpräsentation von Museen zu erweitern und neue Benutzergruppen zu erreichen. Dass das Thema Mashup nicht nur ein kurzer „Hype“ ist, lässt die vor kurzem erschienene IT-Prognose der amerikanische Marktforschungsfirma Gartner erahnen. In dieser werden die IT-Trends vorgestellt, die höchstwahrscheinlich in den kommenden drei Jahren das Anwenderleben nachhaltig beeinflussen werden. Zu den wichtigsten zehn Trends für 2009 wird erstmals auch das Mashup-Konzept gezählt, speziell im professionellen Einsatz, den sogenannten „Enterprise Mashups“. Nach Gartner überwindet 2009 „das Mashup-Konzept […] im Unternehmens¬einsatz das Experimentierstadium“ und wird immer mehr zu Standard – ein weitere Grund, warum man auch im Kulturbetrieb die Entwicklung zumindest im Auge behalten sollte.
Vor kurzen hatte ich bei einer Tagung der Gesellschaft für Geoinformatik einige Beispiel zeigen können, wie sich Mashups für Kulturvermittlung und Marketing einsetzten lassen. Die Vorteile und Möglichkeiten in Mashups stecken liegen auf der Hand, jedoch wurde ich darauf hingewiesen, dass auch die Risiken und Probleme nicht ungenannt bleiben sollten. Dies hatte ich mangels Zeit leider nur am Rande (verweise aber auf einen Vortrag von 2008) und führe hier nochmals wichtige Vor- und Nachteile auf:
Zum einen gibt es bisher nur wenige APIs im Kulturbereich, da die meisten kulturellen Websites sind noch walled gardens sind, so dass der Austausch derzeit meist kompliziert ist. Wie die drei oben genannten Beispiele zeigen müssen zum anderen viele Projekte im Kulturbereich erst eigene große Datenbanken aufbauen, um dann tatsächlich interessante Mashups erstellen zu können. Weitere Risiken können wie folgt skizziert werden:
- Es besteht immer die Gefahr, dass die Anbieter offener APIs die Nutzungsbedingungen ändern oder den Dienst ganz einstellen, so dass die API für das eigene Mashup nicht mehr eingesetzt werden kann;
- Es besteht ein Risiko, dass erfolgreiche und beliebte offene APIs nach einiger Zeit kostenpflichtig werden;
- Es besteht eine Abhängigkeit vom „Zulieferer“: die Nutzung der Dienste auf fremden Servern (Ausfälle, Performance) oder plötzliche Änderungen (z. B. Werbung);
- Mashups, die keinen eigenen Content einsetzten, können schnell nachgebaut werden oder vom API-Anbieter übernommen werden.
Vor allem der erste Punkt ist nicht zu unterschätzen. Trotzdem überwiegen die Vorteile, die sich in folgenden drei Punkten zusammenfassen lassen:
· Mehrwert: Neue, größtenteils kostenlose Inhalte (Karten, Bilder, etc.) können geschickt „vermischt“ Mehrwert erzeugen;
· Kostenersparnis: Die Nutzung vorhandener Applikationen (z. B. Geodaten/ Karten) spart hohe Eigenentwicklungskosten;
· Neue Besucher: Die Verlinkung mit der „Mashup-Community“ kann neue Wege zu (neuen) Besuchern eröffnen.
Als Fazit lässt sich deshalb abschließend sagen: Auch wenn Mashups bestimmt nicht für jedes Projekt im Kulturbereich geeignet sind, gerade weil es für „kulturelle“ Websites noch wenig leicht zugängliche Quellen gibt, können sinnvoll eingesetzte Mashups einen Mehrwert schaffen, um die Webpräsentation von Museen zu erweitern und neue Benutzergruppen zu erreichen. Dass das Thema Mashup nicht nur ein kurzer „Hype“ ist, lässt die vor kurzem erschienene[1] IT-Prognose der amerikanische Marktforschungsfirma Gartner erahnen. In dieser werden die IT-Trends vorgestellt, die höchstwahrscheinlich in den kommenden drei Jahren das Anwenderleben nachhaltig beeinflussen werden. Zu den wichtigsten zehn Trends für 2009 wird erstmals auch das Mashup-Konzept gezählt, speziell im professionellen Einsatz, den sogenannten „Enterprise Mashups“. Nach Gartner überwindet 2009 „das Mashup-Konzept […] im Unternehmenseinsatz das Experimentierstadium“ und wird immer mehr zu Standard – ein weitere Grund, warum man auch im Kulturbetrieb die Entwicklung zumindest im Auge behalten sollte.
[1] zitiert nach Born, Achim: Durchgreifende Veränderung. IDC Prognose für 2009. In: i’x, Jg. 2008, Ausgabe 10, S. 44–45.
Minimallösung softwaregestütztes Projektmanagement
Letzte Woche hatte ich im Rahmen einer Beratungstätigkeit mehrfach ungewollt Gelegenheit, über Sinn und Zweck von Projektmanagement zu diskutieren. Ich möchte die ganze Diskussion hier nicht aufrollen, aber eins betonen: Mit Projektmanagement ist es genauso wie mit Web 2.0. Wer zuerst überlegt, welche Software oder welches Tool er einsetzte möchte und erst dann sich Gedanken macht, was Projektmanagement eigentlich bedeutet, endet in einer Sackgasse. Wer also meint, es lange, eins der hier vorgeschlagenen Tools downzuladen, wird nicht weit kommen. Sich ein klein wenig mit den Grundlagen des Projektmanagement rumzuschlagen ist unverzichtbar.
Wenn es dann los geht empfehle ich dringen, die Finger von Excel zu lassen. Das ist zwar ein sehr feines Programm, aber eben eine Tabellenkalkulation und für softwaregestütztes Projektmanagement wie für viele andere Sachen nur durch Vergewaltigung einsetzbar (Name der Krankheit: Excelitis). Wer kein Geld für teure Software ausgeben möchte und deshalb z. B. auf den Kauf von „Microsoft Project“ oder anderen kommerziellen Programmen verzichtet dem empfehle ich das kostenlose Open-Source Tool OpenProj, die nicht ganz so leistungsstark wie MS Project ist aber durchaus brauchbar. Bis vor ca. zwei Jahren habe ich als Alternative zu MS Project die Freeware OpenWorkbench empfohlen, das leider nicht mehr richtig weiterentwickelt wird und m. E. nicht richtig rund läuft, aber irgendwie auch einsetzbar wäre. Wer auch Projektstrukturpläne mit kostenlosen Tools malen will dem lege ich das freie MindMap Tool FreeMind nahe. Etwas umständlich in der Bedingung, aber alles im allen ganz brauchbar.
Wer nicht nur eine Software für den Projektmanager haben möchte sondern das ganze Projektteam einbinden möchte und deshalb statt einer clientbasierten Lösung eine serverbasierte einsetzten möchte der kann auch zu diversen Open Source und Freeware Tools greifen. Mein Tipp ist ein Klassiker, nämlich phProjekt, das viel mehr als ein Projektmanagement-Tool ist sondern eigentlich eine Groupware.
