Twapperlyzer

Der Mobile YTK Browser ist so weit fertig und läuft auch ganz gut, bis auf ein paar Design Probleme die ich aber erst gegen ende angehen werde mal sehen was sich bis dahin noch so in JQM tut. Das letzte große Problem sind große Archive. Bis ca. 1000 Einträgen kommt die Antwort noch in einer akzeptablen Zeit an (Wobei man bedenken muss das ich es Momentan mit einer 2000 DSL Anbindung teste in Produktion dürfte die Zahl größer als 1000 sein aber irgendwann kommt ein Limit). Danach muss ich wohl stückeln und die Ergebnisse dann zusammen setzten. Dazu habe ich mir jetzt erstmal überlegt nach dem ersten Anfrage die tweetid+1 vom letzten Tweet zu nehmen und damit die nächsten zu holen. So lange bis alle Nachrichten runtergeladen sind.
UPDATE:
Tja war wohl nichts node ist asynchron und daher kann ich ja nicht wissen wie die letzte tweetid aussieht da alle quasi gleichzeitig angefragt werden. Jetzt kann ich noch über die Tage gehen und hoffen das ich pro Tag nicht zu viele Nachrichten bekomme.
UPDATE:
Mit ein wenig Rekursion habe ich es doch hin bekommen, ohne die Tage durch zu gehen. Die Callback-Funktion wird einfach immer weiter durch gereicht bis alle Nachrichten da sind und dann erst zurückgegeben. Hier kann man sich das ansehen.

Die neue Beta von JQM ist draussen und so weit auch ganz fein und die Listen sind viel schneller was für mich ja auch sehr wichitg ist aber ein Seiteneffekt hat mich seit Gestern ganz schön aus manövriert. Meine Seite wurde nicht mehr angezeigt und die Fehlemeldung war auch nicht sehr hilfreich irgendwo ganz tief in Jquery Mobile. Ausgelöst wurde es dadurch das ich direkt nach dem $(document).ready Event auf eine andere Seite wechseln will. Die Lösung war erst auf das $(window).load(function() Event zu warten also bis alles fertig gerendert ist um dann die Seite zu wechseln. Ich bin auf die Lösung gekommen weil ich mein Minimal Beispiel das zu dem Fehler führt erst irgendwo hochgeladen habe und dann dachte ich mir eigentlich könnte ich doch jsfiddle.net benutzten Das genau für sowas sehr Praktisch ist. Also habe ich das eingerichtet und erstaunt festgestellt das mein Minimalbeispiel da problemlos läuft. Also hab ich in den generierten Source geschaut und die Sache mit dem  $(window).load(function() Event dazu gelerent.

Ich versuche mal einen Überblick über die Your TwapperKeeper(YTK) API Version 0_5_5 zu geben so wie ich sie aus dem Code heraus interpretiere. Ich hab leider keine Doku gefunden. Der Parameter id ist als einziger nicht optional und erwartet die Nummer eines Archivs in dieser YTK Instanz.

#sm [start month - number]
#sd [start day - number]
#sy [start year - number]
#em [end month - number]
#ed [end day - number]
#ey [end year - number]
----------------------------
#lang [ISO-639-1 2 letter code included in tweet metadata]
#max_id [maximum twitter id]
#since_id [minimum twitter id]
#offset [set to varius numbers seams to have no effect]
#o [order_by - a = ascending, d = descending (default)]
#nort [set to 1 to remove all tweets starting with RT]
#text [tweet text to search for]
#from_user [twitter username of sender]
#lat | long | rad [must include each parameters individually - radius in km] seams not to work reduces the results to zero
#debug [ set to 1 seams to have no effect]


Mein eigentlich schöner Ansatz mit NowJS und Variablen die damit serverseitig gesetzt werden funktioniert leider nur bedingt. Bis die Daten beschafft worden sind wird nämlich nicht gewartet sondern einfach die letzten Werte angezeigt. Das wird so wohl zu usabilty Problemen führen.

Node ist schnell und wartet auf niemanden. Genau das wird grade zum Problem. Ich verwende NowJS für die Komunikation zwischen Client und Server. Das Konzept gefällt mir auch sehr gut, eine schöne Beschreibung war: “Es ist wie eine Dropbox für Funktionen und Variablen”. Ich speichere eine Variable in einem bestimmten Namespace auf dem Client und kann anschließend vom Server darauf zugreifen. Das Anschließend ist aber genau das Problem, den ein wenig Zeit braucht das synchronisieren der Variable schon und wie gesagt Node ist schnell und wartet auf niemanden. Ich könnte jetzt wait benutzen um ein wenig Zeit auf dem Server zu verbrennen aber das ist extrem hässlich. Zudem weiß ich ja nicht wie schnell die Verbindung ist von daher ist dieser Ansatz nicht zu gebrauchen. Der andere Ansatz ist auf eine Variablen Änderung auf der Serverseite u lauschen. Oder heraus finden ob ich zum setzten der Variable eine Funktion benutzen kann die auch eine Callback Funktion entgegennimmt.

In Jquery gibt es mit getJSON() eine einfache Möglichkeit Daten nachzuladen. Unter Node habe ich so eine Funktion nicht gefunden. Wahrscheinlich gibt es sie jetzt habe ich mir eine eigene geschrieben:

function getJSON(url,callback){
request({ uri:url }, function (error, response, body) {
var myresponse = new Object();
if (error && response.statusCode !== 200) {
myresponse.status = "error";
myresponse.msg = "Could not connect to: "+url;
}
if(body[0]=="{" || body[0]=="["){
myresponse.status = "ok";
try {
myresponse.data = JSON.parse(body);
} catch (err) {
myresponse.status = "error";
myresponse.msg = "JSON not valid";
}
}
else{
myresponse.status = "error";
myresponse.msg = "JSON not valid";
}
callback(myresponse);
});
}


Ich wollte heute nur noch schnell eine Infinite scrolling Funktion einbauen. Grundlage dafür ist natürlich das man weiß wann das wie weit der Benutzer noch vom Ende der Seite entfernt ist. Nach langem suchen bin ich auf das bereits verlinkte Plugin gestoßen und habe da die passende Vorschrift gefunden.  Jetzt kann ich also genau sehen wie viel Prozent der Benutzer noch vom Ende der Seite entfernt ist aber leider lässt sich das Event aus irgendwelchen Gründen nur an Document binden so das es immer regiert. Daher muss ich anschließend noch testen ob ich mich auf der richten Seite befinde. Sollte dem so sein und ich weniger als 20% vom Ende der Seite entfernt bin werden nun automatisch neue Nachrichtenin in die Liste hinzugefügt.

$(document).bind("scrollstop", function() {
// From https://github.com/paulirish/infinite-scroll
pixelsFromWindowBottomToBottom = 0 + $(document).height() - ($(window).scrollTop()) - $(window).height();
pixelsFromWindowBottomToBottomInPercent=Math.round(pixelsFromWindowBottomToBottom/($(document).height()/100));
if($.mobile.activePage.attr("id")=="showMsgsPage"){
if(pixelsFromWindowBottomToBottomInPercent<20){
addMsgs(apiGetArchiveTest);
}
}
});


P.S. Ich weiß wirklich nicht ob es die ganze Arbeit Wert gewesen ist den ein Button in Footer tut es genauso gut aber schön das jetzt klappt ist es trotzdem!

Gestern habe ich erschreckend viel Zeit darauf verwendet mir eine Arbeitsumgebung zusammen zu stellen. Sie sollte in einer VM laufen, da ich die Umgebung dann auch sicher ist wenn ich meine Hostumgebung irgendwie kaputt bekomme. Ich hab mich für ein Ubuntu Server in der VirtualBox entschieden. Damit ich auch gut damit Arbeiten kann habe ich mir die Ports die ich brauche weitergeleitet, das konnte man in den Netzwerkeinstellungen der VM machen:

Nach der Installation in der VM

sudo apt-get install g++ curl openssl libssl-dev apache2-utils libxml2-dev build-essential

Anschließend das node-and-npm-in-30-seconds.sh  Script runtergeladen und ausgeführt:

echo 'export PATH=$HOME/local/bin:$PATH' >> ~/.bashrc
. ~/.bashrc
mkdir ~/local
mkdir ~/node-latest-install
cd ~/node-latest-install
curl http://nodejs.org/dist/node-latest.tar.gz | tar xz --strip-components=1
./configure --prefix=~/local
make install # ok, fine, this step probably takes more than 30 seconds...
curl http://npmjs.org/install.sh | sh

und dann über npm install -g die gewünschten Pakete installieren. Das war bei mir aber nur eingeschränkt erfolgreich, denn ich wollte esspresso installieren. Das schlug fehl bis ich

sudo apt-get install libexpat1-dev

nach installiert habe und ich wollte die cloud9 IDE ausprobieren. Bis dabei dann aber auf diesen Bug gestoßen. Also musste ich es über GitHub installieren. Nach dem cloud9 läuft muss man es noch so konfigurieren das es auch auf der richtigen IP lauscht den die Standard Einstellung  127.0.0.1 bringt einem auf der VM nicht viel. Also:

 ./cloud9.sh -l <IP> -w <workspace>

Jetzt sollte man recht problemlos aus dem Browser der Hostmaschine in der VM entwickeln können.

Ich habe in den letzten Tagen folgendes gelernt. Man sollte immer darauf achten das man die zusammengehörige JavaScript und CSS Datei aus einer jQuery Mobile Version benutzt. Ansonsten kommt es zu Seiteneffekten die ziemlich  unberechenbar sind. Außerdem kann man in einem Formular eine externe Datei als Ziel (action) angeben, sie wird aber nur dann angezeigt wenn es auch eine jQuery Mobile Seite ist.

Ich hab heute mal versucht CoffeeScript praktisch einzusetzen und habe ein bereits existierendes  Twapperkeeper test Script umgearbeitet.  Das Ergebnis ich sollte an meinen automatischen Tests arbeiten.  Es hat ne weile gebraucht bis ich es soweit hatte das der CoffeeScript Compiler es gefuttert hat (Besonders die Sache mit den Leerzeichen, die stimmen müssen. Es half mir sich alle Leerzeichen anzeigen zulassen).  Es lief aber trotzdem nicht und konnte einfach keinen Syntax Fehler mehr finden. Bis ich dann auf die Idee kam das Ursprüngliche JS nochmal zu testen. Das lief auch nicht mehr. Eine DEBUG  Ausgabe später musste ich dann das lesen: ‘API OFFLINE DUE TO HEAVY SERVER LOADS’. Tja kein wunder das der JSON Parser sich daran verschluckt. Auf der Seite und bei Twitter steht nichts ich finde das könnten die auch mal automatisieren. So wie die Fachschaft anzeigt ob sie offen ist oder nicht sollte Twapperkeeper anzeigen ob die API geht oder nicht.

Zurück zu CoffeScript leicht war es nicht (waren ja auch meine ersten Versuche) aber das Ergebnis kann sich sehen lassen. Von 35 Zeilen Code reduziert auf 28, bei meiner Meinung, nach besserer Lesbarkeit.

UPDATE: So hab jetzt den Twapperkeeper Ruby Wraper in einen JS Wraper verwandelt. nur testen kann ich ihnn noch nciht. mal sehen wann die Twaperkeeper API wieder geht.