Backing up Google calendars localy

Here's my bash script (running silently by cron) to make backups of (two of) my google calendars.
(I've omitted my personal stuff)

#! /bin/bash
BACKUP_DIR="/path/to/your/backup/dir"
BASE_URL="http://www.google.com/calendar/ical/"

FILENAMES=(gHome gWork)
KEYS=(restof/url/to/your/cal/basic.ics restof/url/to/your/other/cal/
basic.ics)

if ((${#FILENAMES[@]} != ${#KEYS[@]}))
then
echo "Not equivalent amount of keys as desination files... Exiting"
exit 1
fi

SUFFIX=".ics"
DATESTR=`date "+%C%y%m%d%H%M%S"`

cd $BACKUP_DIR

for ((I = 0;  I < ${#FILENAMES[@]}; I++))
do
FILE="${FILENAMES[$I]}-$DATESTR$SUFFIX"
URL="$BASE_URL${KEYS[$I]}"
curl -s $URL > $FILE
done

This creates two files in the specified directory: gHome-20070801133717.ics and gWork-20070801133717.ics

Simple but useful applescript to be run by qucksilver trigger

I drink a lot (too much probably) coffee while working. I also like to lock down my computer while away fetching a refill, and I also listen to music while working. So, to simplify things a bit, I just created this simple applescript:

if appIsRunning("iTunes") then
tell application "iTunes" to pause
end if
tell application "ScreenSaverEngine" to run


on appIsRunning(appName)
tell application "System Events" to (name of processes) contains appName
end appIsRunning

and then assigned running it to a key-combo in Quicksilver.

Google Developer Day 2007

Har just genomlyssnat Google Developer Day (i mitt fall i Paris), jag är lite snurrig i huvet just nu men jag tror att detta är vad som man har pratat om...

APIer...
Allt handlar om APIer. Vad Google tillhandahåller är sätt att använda data som de tillhandahåller på olika sätt. Det kan vara kartor, kalender, mail, sök, osv.

De vill att man använder denna data. Good stuff. Så vad som finns att tillgå är API:er för detta, som vi utvecklare kan använda. Till exempel (inte nytt, men jag försöker vara tydlig här): Man presenterar någonting som har geografisk bäring, nånting handlar om en plats på jorden, vips - lägg in en karta med platsen/sträckan utmarkerad (http://maps.google.com/). Det fina i kråksången är att man som besökare inte är tvungen att att klicka sig vidare för att få se kartan, och vad som är ännu finare är att man som utvecklare inte är tvungen att fixa och greja och dona och böka för att få in kartan på sidan där den hör hemma. Lite javascript och snipp snapp så är man klar (ok första gången är det lite mer fix, men detta är mycket enkelt att återanvända). Det är detta som är principen bakom Googles API:er. Ta en befintlig funktionalitet som redan finns och gör den lätt att integrera för utomstående. Sen kan man naturligtvis göra lite intelligentare lösningar än i exemplet ovan, men det fattar nog ni också.

Exemplen är många (http://code.google.com). Vad som startade det hela var tydligen någon som bakvägen gjorde om ('reverse-enginered') den första versionen av google maps. Han letade lägenhet och slog ihop (mashup) en mäklartjänst med kartorna. Kartmakarna på google var imponerade och bestämde att de skulle förenkla processen och vips två eller några till år senare så finns ett 10-tal API:er att tillgå för diverse Googletjänster.

Googles tjänster för utvecklare (API:erna mot tjänsterna) är baserat på tre teknologier: SOAP (som var den första och som nu inte används för nya produkter), REST/Atom och Ajax (JavaScript).

GData...
omfattar en grupp tjänster ("Google Base") där APIerna är baserade på konventionen REST ("Representational State Transfer") och standarden Atom (som RSS fast standardiserat) med tillägg (egna namespaces) för tjästespecifik data (tex kalender-info-specifika taggar i xml-en).


Och
så presenterades Google Gears, vilket möjliggör användande av Google (web-) applikationer (nu endast Reader) offline. En slags skrivbar cache som kan fyllas på innan man kopplar ner och som uppdaterar externt när man är online igen. Det är ett plug-in till de stora browsrarna (ff, ie, safari) och funkar på Linux, Mac och Windoze. Tydligen så kan denna funktionalitet också utnyttjas när man bygger Flex/... apps, vilket demonstrerades av nån cto från Adobe (som såklart mer använde tiden till att visa att det går att köra dessa rda:s från skrivbordet men iaf).

Så presenterades (kanske inte nytt, vad vet jag) "Mapplets", som är som Google Gadgets fast för kart-tjänsten. Cool, åtminstånde ur ett kommersiellt perspektiv. Kanske ur andra perspektiv också, men jag är inte fantasifull nog just nu.

Och: GWT rockar! (newsflash newsflash). Ett paradis för oss javautvecklare. Måste bara hitta ett användningsområde... Fan! det är klart det finns sådana, men så är det ju det där med server-sidan som verkar jobbigt om man inte har en isp med servlet-stöd, eller...? Det ska ju inte behövas, men någon form av backend behöver man ju, och jag har inte riktigt förstått hur de två integreras enkelt mha gwt. Ska testa och återkomma.

Andra tips
Om ni ska flyga med Sterling från Kastrup så se till att vara i *GOD* tid, innan avgång, de har nämligen nån form av gemensam incheckniing för samtliga sina flighter vilket genererar en helt otrolig kö i terminal 2... Alla andra bolag har en fin liten kö till sina respektive flighter. Hos Sterling tvingas man beblanda mig med de som ska till unkna hålor så som Stockholm, Amsterdam, Gatwick och jag vet inte vad. Tog över en timme att komma fram till kassan. Att sedan planet lyfte två timmar senare än annonserat framställde ju dom inte i en *bättre* dager precis.