Tag: programmering

Destruction-driven development

Jeg har kodet en del før jeg begynte på informatikk, men før stuiene var mønster (patterns) et ukjent begrep for meg. Siden PHP i lang tid var det foretrukne språket ble det gjerne gjort nyvinninger nettopp i dette språket (IRC-bot kan nevnes).

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)

Koding uten kildekodekontroll

For første gang på lenge skulle jeg bare programmere litt uten å ha koden i kildekodekontroll. Det var for å se om jeg kunne få det til, og etter litt for kort tid fungerte det nøyaktig som det skulle. Siden koden gjorde jobben sin var det tid for å gjøre litt refactoring. Det var klokka 10, og koden fungerer ikke igjen enda…

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.

En titt på Google App Engine

Google kom tidligere i år med noe de kaller Google App Engine (GAE), en tjeneste som lar utviklere lage applikasjoner i Python som kan hostes hos Google. I motsetning til vanlige webhotell er det en del begrensninger som man ikke er vant til fra tidligere hva angår biblioteker.

Google App Engine

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.

Read the rest of this entry »

Test av namespace i PHP

PHP 5.3 skal komme med støtte for namespace, og under lesing om namespace i PHP 5.3 oppdaget jeg fålgende setning:

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.