For en tid tilbake nevnte jeg en av mine “gode” idéer fra den gang for noen med-studenter, og øyeblikkelig kom navnet “destruction-driven development” opp. Konseptet er i og for seg ikke noe jeg har sett igjen i løpet av årene på Gløshaugen, samt at gjennomføringen er bundet mot utvikling på nett, fortrinnsvis i skripingspråk.

Av og til er det greit å hente inn noen standard-filer som blir til over tid (av litt for mange asiater på Aardvark kalt “custom framework”) for å lage til en demo, simpel to-siders løsning eller lignende, og i den forbindelse fant jeg at jeg ofte glemte å kjøre metoden som skulle vise resultatet til en bruker (mye “feilretting”). Med dette knyttet opp mot Smarty endte jeg opp med å ønske å lage sider slik:

<?php

require_once("autoload.php");
Template::setTemplate("page.tpl");

$t = Template::getInstance();
$t->assign("title", "Forside");
$t->assign("text", "Lorem ipsum...");

?>

Konseptet er å la presentasjon foregår på et punkt hvor man er sikker på at all logikk er kjørt, og hvilket bedre punkt enn ved kjøring av  Garbage Collector (GC) finnes? Ved å la destruction-metoden til template-objektet, som er en subklasse av Smarty, til å kjøre display()-metoden trenger ikke kodesnutten over å gjøre det, samt at jeg slipper å duplisere kode for å vise vise innhold. Se gjerne det vedlagte eksempelprosjekt som benytter Smarty.

Jeg ser i utgangspunktet to problemer med overstående kode, hvilket er grunnen til at jeg ikke vil bruke dette konseptet i prosjekter:

1. Det vil gjøre prosjektet vanskeligere å feilrette.
2. Implementasjonen av GC kan endre seg, og ved å oppdatere PHP kan man oppleve at alle sider er blanke. (Les: flere ting som potensielt kan gå galt)

Personer med Android og som benytter busstilbudet i Trondheim.

Selv om det er noe snevert har jeg merket at jeg har vært fokusert på å gi et godt tilbud til de som benytter den, og føler ansvar for å levere et bedre produkt og opplevelse i hver nye versjon. I helgen kunne jeg se at Android Market kunne rapportere følgende status for applikasjonen (i grensesnittet for utviklere):

Applikasjonen er det første programmet jeg har laget for Android, noe som har satt tydelige spor i kildekoden. Grensesnittet har også vært gjennom en del endringer, dagens utseende prøver å være tro mot platformen den kjører på, men i begynnelsen var jeg opptatt av å lage egen look&feel, noe som kostet mer i koden enn jeg likte inntil jeg fant ut hvordan det egentlig skal gjøres.

Ikke bare det grafiske har endret seg, men også hvordan jeg henter svar på spørsmålene som kommer inn. I begynnelsen ble Yahoo Pipes benyttet ved hjelp av en Bussorakel-pipe, men tilbakemeldinger tilsa at den var treg, mellomlagret litt for lenge, og var offline litt for ofte. Fra og med siste utgave benytter jeg i stedet en kodesnutt som kjører på min hosting, og denne faller tilbake på NTNU sin versjon om Team Trafikk sin skulle bruke for lang tid på å svare eller er offline.

Etter at jeg gikk fra hvit bakgrunn til mørk bakgrunn har jeg sett at applikasjonen er avinstallert av flere (før lå jeg på ca. 85% aktive installasjoner), noe som minner meg på at det ikke er lett å få tilbakemeldinger fra brukere. Jeg skulle gjerne sett at Google la mer til rette for dette, for i grensesnittet for utviklere er det kun stjernene som vises, dog ikke hvor mange man har fått av hver, og alle kommentarer er utilgjengelig. Skal man øke kvaliteten på applikasjonene tror jeg dette må ordnes i lengden.

Noe jeg ikke har sett i andre applikasjoner er at man kan trykke frem menyen, og derfra kunne dele programmet med andre gjennom en QR-code som andre kan scanne ved hjelp av en strekkodeleser på sin telefon. Dette lar seg også gjøre fra nettsider, og ved å scanne denne kan du få programmet på din telefon.

Per i dag er det også hele 4 ulike applikasjoner på Android Market som bringer tjenesten til Android, hvor min og Busstider av Martin Mikkelborg Syvertsen ser ut til å være de raskeste applikasjonene (bruker samme kilde).

Jeg  må også takke for alle tilbakemeldinger jeg har fått fra Martin og Rune Martin Andersen, samt flere av mine med-studenter. Uten tilbakemeldinger kommer jeg ikke noen vei, og jeg håper flere benytter anledningen i fremtiden.

Så var det laget; tilgang på NRK sin nett-TV som om tilgangen til innholdet skulle ligge lokal. I mitt forsøk på å gjøre om NRK Nett-TV til et virtuelt filsystem har jeg valgt å bedrive “screen scraping” av nettsidene, og ender opp med én spilleliste for hvert program som er lagt ut.

Jeg har valgt å benytte Python, sammen med modulene Fuse-Python og BeautifulSoup, så dette kan man sette opp på sin egen maskin som kjører Linux eller MacOS.

Filene er lagt ut i kildekodekontrollen på GitHub, og er delt opp i to filer:

• nrk.py – Bibliotek for å aksessere NRK Nett-TV
• nrkfs.py – Koden som oppretter og fórer det virtuelle filsystemet

For å montere filsystemet kjører man enkelt og greit:

./nrkfs.py nrk

Filen må være kjørbar, og “nrk” vil i dette tilfellet bli mappen som skal være monteringspunktet, denne mappen må allerede være opprettet. Gevinsten er ikke vanskelig å forestille seg:

Det er bevisst ikke opprettet noen debian-pakke eller egg-pakke av dette lille prosjektet enda, det får komme etter litt mer testing om det skulle være noen interesse for det.

Oppdatering: Debian-pakke er tilgjengelig for nedlasting fra GitHub sammen med instruksjoner for installasjon.

Håper noen har ønske om å teste dette ut og kan komme med tilbakemeldinger, er svært interessert i det som ikke måtte fungere.

I et forsøk på å gjøre Ordnett lettere tilgjengelig for meg selv kodet jeg i høst en liten kodebit som lar meg gjøre oppslag direkte fra terminalen, som jo alltid er oppe.

Bruk av ordnett fra terminalen.

Jeg har nå lagt ut denne kodebiten i kildekodekontrollen på GitHub, og de som måtte ønske å benytte den kan laste den ned. Det er fortsatt noen feil og mangler, men programmet i seg selv gjør jobben. Jeg skal få ordnet med noe versjonering og debian-pakker etterhvert for de som foretrekker det.

For de som måtte håpe at dette er et magisk program som gir ekstra tilganger, så beklager jeg. De som er koblet opp i NTNU sitt nettverk vil få opp alle alternativene som er i koden, mens andre må forvente at tilganger koster penger med mindre nettleverandøren har en avtale.

Bruken av programmet er veldig enkel, for eksempel kan oppslag i norsk-engelsk-ordbøker, oppslag i bokmålsordboka og i alle tilgjengelige se slik ut:

ordnett -ne fritid
ordnett -bok fritid
ordnett fritid

Om noen skulle ta en titt på koden, så vet jeg at ikke alt er like bra, jeg skrev mesteparten kort tid etter at jeg begynte å programmere i Python, men får håpe det blir bedre etterhvert.

Ting som jeg vet mangler:

• Mulighet for å legge inn innlogging
• Det er fortsatt en del tegn som kommer opp feil
• Underveis i formateringen hender det at mellomrom fra nettsidene forsvinner

Så, for å plukke relevante tips fra boka The Pragmatic Programmer av Andrew Hunt og David Thomas:

(23) Always Use Source Code Control
Source code control is a time machine for your work – you can go back.

(47) Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

Jeg lover; aldri igjen uten kildekodekontroll.

Google App Engine

GAE tilbyr ikke en vanlig relasjonsdatabase (som MySQL, MS SQL osv) men noe som kalles Datastore, denne er i tillegg begrenset til å ikke hente ut mer enn maks 1000 poster fra en “tabell”. Biblioteket som Google stiller med støtter heller ikke sesjoner (sessions), men man kan bygge dette ut ved å legge ved egne biblioteker. En annen artig begresning er at koden ikke kan lese eller skrive til disk. Når dette er sagt stiller man med Memcache, noe som kan sammenlignes med delt minne tilgjengelig fra alle instansene som kjører (for Google kan finne på å kjøre opp applikasjonen på mange for å skallere).

Jeg oppdaget GAE gjennom en artikkel i Python Magazine, og fant det utrolig interessant, men av mangel på applikasjoner å utvikle ble det lagt litt på hylla helt til for noen dager siden når jeg kom over en video på YouTube som viste ting i praksis, og da måtte det bare testes.

For å vise litt av mulighetene i GAE skal jeg utvikle en liten applikasjon som viser et tilfeldig sitat fra datastore, og som lar Google sine brukere logge på for å legge inn nye sitater. Det skal også være en link til hvert sitat.

For å utvikle kan man laste ned App Engine SDK, og da Google støtter kun Python i skrivende stund blir dette utviklingsspråket som må benyttes.

Til å begynne med lager jeg en modell, en representasjon av “tabellen” jeg skal benytte.

class Quote(db.Model):
id = db.IntegerProperty()
user = db.UserProperty(required=True)
name = db.StringProperty()
text = db.StringProperty(multiline=True, required=True)
timestamp = db.DateTimeProperty(auto_now_add=True)

Det er lite spennende her, men det er verdt å merke seg at UserProperty lar deg lage en representasjon av Google sine brukere. Så snart modellen er laget kan jeg begynne å legge inn data i den ved hjelp av kode. For å lage siden må jeg definere en klasse for dette.

class Add(Base):
def get(self):
self.render("add.html")

def post(self):
q = Quote(
text = self.request.get("text"),
name = self.request.get("name"),
user = users.get_current_user()
).put()
self.redirect("/view/" + str(q.id()))

Ved GET-etterspørsler vil get-metoden benyttes, og den returnerer en nettside. Ved POST-etterspørsel vil det bli opprettet et nytt objekt med informasjon, og ved hjelp av put() blir objektet lagret i datastore, for så å sende brukeren til en side som viser det nye objektet.

Det er viktig å merke seg at det ikke finnes noen mulighet for auto increment som man kjenner fra andre databaser, så id-feltet som ser ut til å ligge lagret i modellen inneholder None (null). For å simulere auto increment er det laget to metoder som tar var på den siste id-verdien i memcache.

def getLast():
last = memcache.get("last")
if last:
return last
return setLast()

def setLast():
id = Quote.all().order("-id").get().id
memcache.set("last", id, 3600*24)
return id

Ved hjelp av setLast blir den siste verdien hentet ut og lagt inn i memcache, som kan beskrives som delt minne mellom instansene av applikasjonen (Google starter ikke bare én). getLast har som formål å returnere verdien fra memcache, men ser til at den blir satt opp den ikke er satt. For å fylle opp id på Quote-objektet må jeg i tillegg bytte ut put-metoden til modellen.

def put(self):
self.id = memcache.incr("last")
if not self.id:
setLast()
self.id = memcache.incr("last")
return self.put()

Selv om jeg setter en id-verdi på objektet har objektet allerede en annen id som er tilgjengelig gjennom objekt.key().id(), og det er objektet fra objekt.key() som returneres ved put(). Den genererte id-en fra Google trenger følge på hverandre slik man gjerne opplever når man utvikler lokalt.

For å vise et gitt sitat er det ønskelig å benytte id-verdien som objektet automatisk har fått, og for å hente sitater ut gjør denne verdien det enkelt.

class View(Base):
def get(self, id):
quote = Quote.get_by_id(int(id))
if not quote:
raise Exception("Requested quote doesn't exists")
self.render("view.html", dict(quote=quote))

Quote.get_by_id() er en metode som gjør det veldig greit å hente et gitt objekt uten å måtte skrive en hel spørring. Dersom objektet som etterspørres ikke eksisterer er det ønskelig å lage et avvik, dette blir tatt hånd om av en metode i Base-klassen som er laget for å slippe å skrive mye kode:

class Base(webapp.RequestHandler):

def render(self, tpl, values = {}):
values["user"] = users.get_current_user()
values["url_login"] = users.create_login_url(self.request.url)
values["url_logout"] = users.create_logout_url("/")

self.response.out.write(
template.render("template/" + tpl, values)) # Lispy!

def handle_exception(self, exception, debug_mode):
self.response.out.write(
template.render("template/error.html", dict(error=exception)))

Denne klassen er laget kun for å slippe å skrive kode mange ganger (DRY). handle_excception tar imot avvik og lar meg håndtere disse på en fornuftig måte. render-metoden er en metode for å gjøre koden enklere, men også for å sikre at det blir sendt med noen ekstra variabler som link til innlogging og brukerinformasjon.

En av begrensningene til Datastore er at det mangler mulighet for å sortere i en tilfeldig rekkefølge (“SELECT … ORDER BY rand()”). Det er flere som har prøvd å løse denne mangelen, men siden jeg har laget meg en tilnærming til auto increment på tabellen må jeg klare å lage en tilfeldig verdi mellom den laveste og den høyeste mulige verdien.

class Front(Base):
def get(self):
rnd = random.randint(getFirst(), getLast())
quote = Quote.all().filter("id >= ", rnd).order("id").get()
if not quote:
quote = Quote.all().filter("id < ", rnd).order("id").get()
self.render("front.html", dict(quote=quote))

Den er muligens noe omfattende, men det er en tilnærming for å sikre at man alltid finner minst et sitat (så lenge det er noen i tabellen).

For å fortelle hvilke klasser som skal benyttes ved kall mot serveren må applikasjonen vite om disse, dette gjøres ved å legge inn informasjon om dette i filen;

application = webapp.WSGIApplication([
("/", Front),
("/add", Add),
("/view/(\d*)", View),
(".*", Error),
], debug=True)

def main():
run_wsgi_app(application)

if __name__ == "__main__":
main()

I tillegg må det være med en app.yaml som forteller enda litt til om applikasjonen:

application: rndquote
version: 1
runtime: python
api_version: 1

handlers:
- url: /style
static_dir: style

- url: /add
script: quote.py
login: required

- url: /admin.*
script: $PYTHON_LIB/google/appengine/ext/admin
login: admin

- url: /.*
script: quote.py

Det er verdt å merke seg at “login: required” gjør det at man må være innlogget for å få opp siden, hvilket er grunnen til at det ikke er noen kode for brukerhåndtering og annet i koden.

I tillegg til noen metoder og et par andre småting er applikasjonen ferdig, og den kan testes på rndquote.appspot.com. All nødvendig kildekode for å kjøre programmet kan lastes ned (må ha SDK i tillegg).

GAE er ikke kommet i endelig utgave enda, og det er satt en del begrensninger (maks 650 000 kall mot datastore og 2 500 000 sidekall per døgn), i tillegg er det enkelte ting som ikke er der som man normalt forventer å ha tilgjengelig når man utvikler for veven.

Til tross for begrensninger er det ingen tvil om at dette er gøy å leke med, og det er ikke vanskelig å se for seg en del ting som egner seg å lage for GAE.

Av ting som er nytt, kan man finne:

• Mulighet for å legge inn eksamener i fag som ikke har undervisning
• Mulighet for å legge inn fag for flere semester, i denne omgang også neste semester
• Jeg har tatt i bruk Prototype for å skrive mindre JavaScript

I stedet for å utvikle i PHP, har jeg denne gangen valgt å benytte Python og rammeverket Pylons. Pylons har valgt en MVC-tilnærming, og kan i likhet med mange andre rammeverk minne om Ruby On Rails.

For de som ikke går på NTNU men som likevell har lyst til å teste den kan man finne oversikt over fag og timeplaner på den offisielle siden for timeplaner ved NTNU.

Same namespace name can be used in multiple files.

For å teste dette hentet jeg ned snapshot av PHP 6.0 og kompilerte den direkte på ene maskinen (ups…). Deretter laget jeg noen filer.

index.php:

<?php
function __autoload($class) {
require_once("bar.php");
}

require_once("foo.php");

test::foo::test();
test::bar::test();
?>

foo.php:

<?php
namespace test;

class foo {
public static function test() {
echo "foo";
}
}
?>

bar.php:

<?php
namespace test;

class bar {
public static function test() {
echo "bar";
}
}
?>

Resultatet av kjøringen ble “foobar”, så da kan man altså “fylle opp” et namespace ved behov.

Nå gjenstår det bare å få tak i PHP 5.3 som ferdige pakker til Ubuntu.