• De Morgen
• Krant van West-Vlaanderen

https://twitter.com/Kortrijk1418/

Lijkt handig, maar in de praktijk maakt Google hier een feed van met per rij 2 items: een titel en een description.
Dit staat ook zo in de docs:

Each entry represents a row in the worksheet. The title element contains the contents of the first cell in the row, and the content element contains a textual representation of the data from all the other cells in the row.

Redelijk ambetant dus

Wat ze er niet meteen bijzeggen is dat je de waardes ook apart kan verkrijgen. Het is een kwestie van de parameters in de url wat aan te passen:

Standaard ziet het er zo uit:
https://spreadsheets.google.com/feeds/list/[spreadsheet-id]/od6/public/basic?alt=rss
Het enige wat je hoeft te doen is die ‘basic’ door ‘values’ te vervangen:
https://spreadsheets.google.com/feeds/list/[spreadsheet-id]/od6/public/values?alt=rss
En voor als je een json string wil:
https://spreadsheets.google.com/feeds/list/[spreadsheet-id]/od6/public/values?alt=json

Alle cellen in een rij zijn nu apart aanspreekbaar. Ze zijn voorzien van een prefix ‘gsx’, dit komt door de namespace die ze gebruiken om de xml valid te houden.

Je moet er ook wel voor zorgen dat de eerste rij in jouw spreadsheet de kolomkoppen bevat.

English version:

Just use ‘values’ instead of ‘basic’ in the url

Rwanda
Buy a MTN sim card, insert it into an other phone and call 455 to have an internet activated sim card. (For some reason this didn’t work by activating it on my iPhone itself)
The apn you need is: ‘internet.mtn’
cost: 30 Rwf per Mb (0,052 $/Mb) (see the mtn website)

Congo
Buy a Vodacom sim card, insert it into your iPhone and just set your apn to: ‘vodanet’ (I went to a vodacom shop to activate it, but I think that’s all they did…)
cost: 0,40 $/Mb (says the Vodacom site, but I think it was less expensive)

Alles in één
Er staat een script op de server dat alle content ophaalt en dit dan wegschrijft in een bestandje. Bij een bezoek is het gewoon een kwestie van die weggeschreven content uit te lezen. Die content moet natuurlijk zo nu en dan een update krijgen, maar straks meer daar over.

Minder http requests
Een webpagina bestaat uit vele bestanden (javascripts, stylesheets…) Voor ieder bestand is er een http request nodig om dit te gaan ophalen. Dit brengt op zich al een vertraging met zich mee. Een oplossing kan zijn om alles in één groot bestand te stoppen, maar dat is verre van praktisch. Ik ben op een handig script uitgekomen dat dit oplost. Alle losse bestanden worden onderschept en in één groot bestand gestopt én als surplus gecached.

Cachen
De beginpagina is php, kortweg haalt die de inhoud uit het contentbestand, zet alles op de juiste plaats en maakt de WordPress blog aan. Alles gaat naar de gebruiker in de vorm van een html pagina, zoals alle php pagina’s. Met het cachen sla ik die gegenereerde pagina op. Bij een volgend bezoek geef ik gewoon die gecachte pagina weer. Als er niks veranderd is, dan moet er ook niks opnieuw gegenereerd worden. Ik heb die mosterd hier gehaald.

Nu moet je ooit wel eens opnieuw je pagina laten genereren. Je kan dat bijvoorbeeld na een bepaalde tijd doen of door eerst te kijken of er wel iets aangepast is. Ik heb voor dit laatste gekozen: als het contentbestand recenter is dan de gecachte pagina, dan moet de pagina opnieuw gegenereerd worden.

Content updaten
Het contentbestand moet zo nu en dan ge-update worden. Dit zou kunnen met een zogenaamde cronjob, waarbij de server een script om-de-zoveel-tijd gaat uitvoeren. Maar dit is niet ideaal: wacht ik te lang met updaten, dan is de content hier niet up-to-date. Laat ik het te vaak runnen, dan zorgt dit voor onnodige belasting van de server.
Het interval van updaten zal bepaald worden door de content die het snelst aangepast is, dit is -hier zeker- Twitter.
Bij het posten van een blog item kan je pingen, laten weten aan een of andere service dat er een nieuwe post is. Bij Twitter kan dit niet, (of toch niet dat ik weet) dus moet ik het anders doen.
Eenmaal de pagina volledig is ingeladen stuur ik een Ajax request naar de server met daarin de id van de laatste tweet die op die pagina staat. Hier heeft de gebruiker geen last van, de pagina is al compleet ingeladen. De server gaat kijken of er een tweets zijn met id’s die groter zijn dan deze die op de pagina staan. Als dit het geval is worden deze terug gezonden naar de gebruiker en in de lijst met tweets geplaatst. Op dit punt ziet de gebruiker een up-to-date lijst met tweets. Als er nieuwe tweets gevonden zijn (en alleen dan) vertrekt er opnieuw een Ajax request naar de server, maar dan om het content bestand opnieuw te genereren. Bij de volgende pagina weergave zal blijken dat het content bestand recenter is dan de cache, en krijgt men meteen de up-to-date lijst met tweets (én al de rest)

Resultaten
Ophalen, verwerken en wegschrijven van content naar contenbestand: 4.28s
Inladen beginpagina in Firefox, browsercache uitgeschakeld:

Vooral bij het cachen is het resultaat erg zichtbaar. De rest valt nog mee.
Zonder dit alles zou elke weergave van de beginpagina meer dan 5 seconden duren…

Maar…
Er zijn wel wat kanttekeningen bij: bij elke homepagina weergave vertrekt er achteraf nog een request naar de server. Deze moet dan telkens Twitter gaan aanspreken, dat is overkill. Qua bezoekers zal het hier wel nog meevallen, maar echt fijn is het niet. Er zou op z’n minst een soort tijdslimiet mogen inzitten, dat hij maar 1 keer per minuut gaat controleren of zo…
Alles is wat experimenteel, 2-3 manieren samen gesmeten, hmm. Maar alles lijkt goed te werken, we zien wel.

Update
Met @ikbenmartijn wat over-en-weer zitten tweeten, en tot de volgende inzicht gekomen:

• Ik heb de datum nodig van de laatste zijn-er-nog tweets request
• M’n eerste idee was om die datum ook bij te houden in het content bestand. Telkens als een request binnen komt voor nieuwe tweets, dan de datum daar gaan aanpassen.
• Met het aanmaken van de index pagina, gewoon die datum in de javascript zetten, en die kan dan gaan kijken of er genoeg tijd tussen de requests zou zitten.
• Enigste probleem hierbij: die index pagina is gecached natuurlijk, en dat wil zeggen dat die geen recente datum info kan hebben staan

Klein woordje uitleg misschien?

Eerst op de vraag: wat is dat hier?

• Het bleek dat de frequentie van m’n tweets omgekeerd evenredig was met die van m’n blog posts.
• Eigenlijk is bloggen slechts een deel van m’n activiteit op het web. Daarnaast tweet ik, zet ik foto’s en filmpkes online, scrobble ik muziek, check ik in, en wie weet wat er nog allemaal zal bijkomen.
• Bedoeling is om hier gewoon al die zaken te bundelen.
• ‘100% vet’ om in het thema van de fijne webwaren te blijven, dat typisch beenhouwerpapier mag zeker niet ontbreken.
• Er is wel nog wat werk aan, zo ben ik niet content van die header. Als er iemand een beter voorstel heeft: please, shoot!
• Het zal nog wat finetunen worden, her en der marcheren er dingen nog niet. Maar we zijn nu op z’n minst terug vertrokken.

Op de vraag: Wat is er eigenlijk gebeurd?

• Plots kreeg ik de vraag wat er met m’n blog aan de hand was, ik had het zelf nog niet eens opgemerkt.
• Blijkbaar had m’n vroegere host te veel security problemen met WordPress en heeft dan besloten om geen installaties meer toe te laten. In mijn geval zelfs te wissen.
• Soit, geen probleem, verhuizen naar een andere host dan maar, ik had nog wel ergens een backup staan.
• Hmm, strange
• Blijkbaar had ik de backup overschreven met de blog van de scouts, merde
• Nog een paar keer gepolst bij m’n vorige host, helaas, die konden me ook geen backup van de database bezorgen.
• Eigenlijk is dat wel jammer, al die gegenereerde content, zo maar weg?
• Bleek dat er nog redelijk wat terug te vinden is op The Wayback Machine Ik vermoed dat ik hiermee 70% kan recoveren.
• Copy-pasten dan maar…
• Voor de een of andere reden waren er geen items meer te bespeuren na juni 2008…
• Na wat googlen bleek dat ik als een bron op nieuws.be aanzien was.
• Slechts een korte inleiding op de artikels, maar enfin, het is al iets. Merci Nieuws.be