Nyt brød – bedre end det forrige

Mine tidligere forsøg udi brødets kunst har udviklet sig til nedenstående:

Surdej

1.25 dl æblemost
0.75 dl mørk øl (f.eks. Rød Odense, Abbey Ale, Brown Ale e.l.)
3 dl vand
75 g rugmel
75 g fuldkornshvedemel
150 g hvedemel

Alle ingredienser blandes sammen og røres godt igennem med et piskeris. “Dejen” skal have en grød-lignende konsistens. Hæld dejen i en beholder med låg. Stil den på køkkenbordet, og lad den stå og gære i 3-5 dage – jo længere jo bedre. Undervejs vil dejen bundfælde, så 1 gang dagligt skal du røre i den.

Brødet

10 g gær
20 g salt
1 knivspids sukker
200 g surdej (den som du lige har lavet ovenfor)
5 dl vand
50 g fuldkornshvedemel
ca. 600-700 g hvedemel

Put gær, salt og sukker i en stor skål, og rør rundt til gæren er smeltet (salt og gær flyder sammen). Hæld surdej, vand og fulkornshvedemel i og rør rundt imens. Lad dejen stå i ½ time. Tilsæt derefter hvedemel lidt af gangen, mens du rører grundigt. Tilsæt mel indtil dejen binder godt men stadig er lidt klistret.

Dæk skålen med et vådt viskestykke og sæt i køleskabet og hæve i 24 timer.

Efter 24 timers hævning:

Tag en bageplade frem og kom bagepapir på. Tag forsigtigt dejen op og slå den ned. Del dejen i 2 dele, form dem som brød og læg dem på bagepladen. Dæk brødene til med et viskestykke og lad dem efterhæve lunt i 1-2 timer. De vil nok flade lidt ud, men de skal nok hæve flot op i ovnen.

Efter 1-2 timers efterhævning:

Tænd ovnen og lad den varme op til 200 grader. Fjern viskestykket og sæt bagepladen i ovnen. Bag brødet ved 200 grader i ca. 35-40 minutter.

Eksperimenter med følgene:

  • Bag brødet med damp. Sæt en foliebakke med kogende vand ind i bunden af ovnen mens du bager. Det giver en mere smidig skorpe.
  • Lad sidste ½ times efterhævning foregå under damp (det kaldes raskning). Sæt en foliebakke med kogende vand på bagepladen mellem brødene, og dæk det hele til med en stor plastikkasse.
  • Hvis du har en god røremaskine, så brug endelig den – lad stadig dejen “ælte” i mindst 10 minutter

Vedligeholdelse af surdejen

I opskriften bruger du ikke al surdejen, og det er helt bevidst. Du kan nu spæde blandingen op med mere udfra samme opskrift som beskrevet øverst. Hvis du gør det, så vil den nye blanding allerede være klar til brug 1-2 dage efter. Så dermed går det hurtigere, når først du har startet processen.

Surdejen kan opbevares i køleskabet, når den først har gæret op.

Nye muligheder for outsourcing og joint-ventures i Bangladesh

I slutningen af januar var jeg på rejse til Bangladesh, hvor jeg deltog på en IT-messe i hovedstaden Dhaka. Anledningen var som medlem af en delegation sammensat af Håndværkerrådet og ITC, som ønskede at undersøge mulighederne i og niveauet for Bangladesh’ IT-branche. Delegationen bestod af repræsentanter fra danske og hollandske virksomheder.

Arrangementet var fantastisk godt sammensat af ITC (thank you Martin Labbé). På messeområdet havde ITC arrangeret et lokale, hvor vi kunne sidde i ro og fred og mødes med en række virksomheder, som vi havde udvalgt på forhånd udfra et stort virksomhedsindeks. Efterfølgende var vi på besøg hos så mange af virksomhederne som muligt.

Nogle af de interessante og positive observationer, som vi gjorde var:

  • Bengalerne er meget stolte og bevidste om deres evner. De mødte os i øjenhøjde som ligemænd og ikke som “underdanige”.
  • De er utrolig godt forberedte til møderne, de kom gerne 2 eller 3 repræsentanter fra samme firma, og alle kunne bidrage til samtalen.
  • Meget motiverede, engagerede ambitiøse og visionære.
  • Højt uddannelsesniveau og gode tekniske evner.
  • Generelt god ledelse.
  • Mange af virksomhederne har ejere/ledere, der har boet en årrække i EU eller USA. Der har de taget en formel uddannelse og fået erhvervserfaring, inden de er rejst hjem for at starte egen virksomhed i Bangladesh.
  • Viser tydelige evner for at kunne tage halvfærdige idéer og selv have den nødvendige innovation til at kunne færdiggøre dem til komplette løsninger.

Bangladesh er interessant for danske virksomheder i øjeblikket. Det er nemlig muligt i øjeblikket at søge om Danida støtte, hvis man som dansk virksomhed er villig til at starte et joint-venture op sammen med en eksisterende lokal virksomhed. Flere har allerede gjort det med succes, men hvis det skal være et joint-venture, hvor den lokale partner bidrager konstruktivt, så er der brug for en ligeværdig partner med et højt niveau af selvstændighed, visioner og innovation.

Og det finder man i Bangladesh.

Har du prøvet den sunde sindssyge?

Sæt dig i din bil i frokostpausen med solbriller på, og peg med en hårtørrer på forbipasserende biler. Hold øje med, om de sænker farten.

Kald dig selv over samtaleanlægget uden at forvrænge stemmen.

Når nogen beder dig om at gøre noget, så spørg altid, om de ønsker pommes frites til.

Stil din skraldespand på skrivebordet, og mærk den “Indbakke”.

Hæld koffeinfri kaffe i kaffemaskinen i tre uger. Skift til espresso, når alle er kommet sig over koffeinafhængigheden.

Skriv “For seksuelle ydelser” på alle dine checks.

Spørg folk, hvilket køn de har. Grin hysterisk, når du hører svaret.

Sig “ud af huset”, når du køber mad i en drive-in-restaurant.

Råb: “Jeg vandt, jeg vandt”, når der kommer penge ud af pengeautomaten.

Råb: “Løb for livet, de er sluppet løs”, mens du løber mod parkeringspladsen, når du forlader Zoologisk Have.

Sig til dine børn over middagen: “Vi er desværre nødt til at afskedige en af jer på grund af økonomien.”

Fuldkornsbrød med surdej

Mit eget brød – stærkt inspireret af Bo Bech og kokken fra Sortebro Kro. Det tager tid at lave, men er også tiden værd.

Surdej

1.25 dl æblemost
0.75 dl mørk øl (f.eks. Rød Odense, Abbey Ale, Brown Ale e.l.)
3 dl vand
75 g rugmel
75 g fuldkornshvedemel
150 g hvedemel

Alle ingredienser blandes sammen og røres godt igennem med et piskeris. “Dejen” skal have en grød-lignende konsistens. Hæld dejen i en beholder med låg. Stil den på køkkenbordet, og lad den stå og gære i 3-5 dage – jo længere jo bedre. Undervejs vil dejen bundfælde, så 1 gang dagligt skal du røre i den.

Brødet

10 g gær
12 g salt
1 knivspids sukker
200 g surdej (den som du lige har lavet ovenfor)
3½ dl vand
50 g fuldkornshvedemel
600 g hvedemel

Put gær, salt og sukker i en stor skål, og rør rundt til gæren er smeltet (salt og gær flyder sammen). Hæld surdej, vand og fulkornshvedemel i og rør rundt imens. Til sidst tilsætter du hvedemel lidt af gangen, mens du rører grundigt. Når dejen bliver fast nok, skal den ud på bordet og æltes med hænderne i 10 minutter. Dejen skal være smidig, men skal samtidig helst slippe bordet let.

Form dejen som en bolle, sæt den ned i skålen og dæk til med et viskestykke. Dryp lidt vand på viskestykket, så dejen ikke tørrer ud på overfladen. Sæt den til at hæve i 2 timer.

Efter 2 timers hævning:
Tag en bageplade frem og kom bagepapir på. Tag forsigtigt dejen op og læg den på bagepladen. Form den som et brød ved at flade den lidt ud og så fold den over én gang.

Dæk dejen til med et vådt viskestykke eller Vita Wrap film. Sæt bagepladen i køleskabet og lad dejen hæve 24 timer.

Efter 24 timers hævning:
Tænd ovnen og lad den varme op til 250 grader. Tag bagepladen ud, fjern dækkenet fra dejen og sæt den i ovnen. Bag brødt ved 250 grader i ca. 25 minutter.

Smager suverænt med bare smør på.

Et par kommentarer:

  • Du kan erstatte 50-100 g af hvedemelet med durum, hvis du vil variere brødet
  • Da surdejens konsistens ikke altid er den samme, så kan mængden af hvedemel variere
  • Hvis du har en god røremaskine, så brug endelig den – lad stadig dejen “ælte” i mindst 10 minutter

Vedligeholdelse af surdejen

I opskriften bruger du ikke al surdejen, og det er helt bevidst. Du kan nu spæde blandingen op med mere udfra samme opskrift som beskrevet øverst. Hvis du gør det, så vil den nye blanding allerede være klar til brug 1-2 dage efter. Så dermed går det hurtigere, når først du har startet processen.

Surdejen kan opbevares i køleskabet, når den først har gæret op.

Normalisering af databaser

Dette er en artikel, som jeg har længe haft liggende på Eksperten.dk. Siden Eksperten fik nyt design har det været fuldstændig umuligt at se tabeleksemplerne i artiklen, hvilket gør den stort set ubrugelig. Jeg har derfor flyttet over på min egen blog, hvor jeg bedre kan kontrollere layoutet.

Artiklen henvender sig til dig, der arbejder med databaser. metoderne beskrevet heri er ikke rettet mod bestemte database mærker. faktisk kan de også tages i anvendelse andre steder hvor du bruger datastrukturer, f.eks. kommaseparerede filer, arrays i programmer, osv.

Når du designer databaser med mange tabeller, kan du nemt komme ud for, at flere tabeller “lapper over hinanden” hvad angår de data, som de skal lagre. Det giver følgende problemer:

– Hvis indholdet af et felt i en tabel skal ændres, så skal ændringen også foretages i alle andre tabeller, hvor indholdet forekommer. Hvis dette ikke gøres, så bliver databasen pludselig inkonsistent.
– Hvis en tabel indeholder for mange forskellige data, kan der opstå situationer, hvor man gerne ville gemme records hvor kun en lille delmængde af felterne er udfyldt.

Nok snak for nu. Jeg vil nu vise et eksempel på, hvor galt det kunne gå. Jeg præsenterer et eksempel, som jeg så anvender igennem alle metoderne i artiklen.

Et artikelsystem

Jeg forestiller mig, at jeg har lavet et simpelt artikelsystem. Det kan pt. følgende:

– En bruger kan oprette en artikel, hvor han indtaster en overskrift, en tekst, hans eget navn og e-mail adresse.
– Andre brugere kan nu læse denne artikel og skrive kommentarer til den. En kommentar består af en dato, brugerens navn + e-mail samt kommentarteksten.

Da jeg er nybegynder i datadesign, har jeg lavet det hele i én enkelt tabel:

artikel
+------------+--------------------------+----------------+-----------------+------------------+------------------+-----------------+------------------+---------------------------+
| artikel_id | overskrift               | tekst          | forfatter_navn  | forfatter_email  | kommentar_datoer | kommentar_navne | kommentar_emails | kommentar_tekster         |
+------------+--------------------------+----------------+-----------------+------------------+------------------+-----------------+------------------+---------------------------+
|          1 | Artikel om normalisering | Bla bla bla... | Carsten Gehling | carsten@sarum.dk | 2003-02-10       | Søren Hansen    | sh@email.dk      | Rigtig god artikel...     |
|            |                          |                |                 |                  | 2003-02-11       | Erik Clausen    | erik@clausen.dk  | Det var dog det arg..     |
+------------+--------------------------+----------------+-----------------+------------------+------------------+-----------------+------------------+---------------------------+
|          2 | Python for nybegyndere   | Nu skal i .... | Carsten Gehling | carsten@sarum.dk | 2003-03-05       | Tom Andersen    | tom.and@mail.dk  | Jeg forstår ikke h...     |
|            |                          |                |                 |                  | 2003-03-07       | Erik Clausen    | erik@clausen.dk  | Du har endnu engang..     |
+------------+--------------------------+----------------+-----------------+------------------+------------------+-----------------+------------------+---------------------------+
|          3 | SQL injektion            | Jeg vil kort.. | Squash Guy      | sg@eksperten.dk  | 2003-03-06       | Tom Andersen    | tom.and@mail.dk  | Tankevækkende!!!          |
|            |                          |                |                 |                  | 2003-03-07       | Pia Jørgensen   | pj@somewhere.com | Fin artikel men...        |
|            |                          |                |                 |                  | 2003-03-07       | Erik Clausen    | erik@clausen.dk  | Lige et spørgsmål mere... |
+------------+--------------------------+----------------+-----------------+------------------+------------------+-----------------+------------------+---------------------------+

Til dig der kender lidt mere til datadesign, og som sikkert allerede sidder og korser dig, kan jeg kun sige: Jeg har set konkrete eksempler á la ovenstående.

Metoderne her i artiklen arbejder udfra den tese, at data befinder sig i en bestemt normalform. Hver normalform fortæller noget om hvor velstrukturerede dine data er. Jo højere normalform jo bedre. Jeg vil beskrive de 4 første normalformer fra 0. op til og med 3. normalform og hvordan man kommer fra den ene til den næste. Normalformerne bygger på hinanden således at 3. normalform automatisk kræver at reglerne fra 1. og 2. normalform også er overholdt.

0. normalform (0NF)
Ovenstående eksempel befinder sig i 0. normalform (0NF). Dette er den løseste form, der ikke stiller nogle krav til opbygningen af dine data. Til gengæld kan du heller ikke gøre så meget ved data i denne form, uden at det kræver et stort arbejde.

Der er ingen regler for denne normalform, og derfor er der heller ikke meget mere at beskrive om den. Til gengæld vil det næste afsnit fortælle, hvilke problemer, der løses ved at ændre sine data, så de overholder reglerne for 1. normalform.

1. normalform (1NF)

Som tabellen “artikel” er opbygget lige nu, er det meget svært at udskille en enkelt kommentar fra en given artikel. Faktisk kan det ikke lade sig gøre med en SQL-sætning alene. Der skal programmeringsarbejde til. Først skal hele artikel-recorden indlæses. Derefter skal felterne “kommentar_datoer”, “kommentar_navne”, “kommentar_emails” og “kommentar_tekster” splittes op vha. programmering og gennemløbes.

Den måde som kommentarerne gemmes på i mit eksempel kaldes “repeating groups”. Det betyder, at du har en gruppe data, som gentages i den samme record. Problemet med repeating groups er, at du som tidligere nævnt ikke kan identificere én enkelt af disse datagrupper entydigt.

Reglen for første 1. normalform (1NF) går i al sin enkelthed ud på, at dine data ikke må have “repeating groups”. Dvs. alle data skal kunne identificeres entydigt udfra en nøgle (f.eks. primærnøglen).

Det var så reglen. Hvordan får vi så ændret vores data til at opfylde denne regel?

Metoden går ud på, at vi udskiller alle felterne i vores repeating groups i en separat tabel. Samtidig medtager vi primærnøglen fra tabellen “artikel” som en fremmednøgle. Dermed kan vores records i den nye tabel referere til de records i “artikel”, som de hører til. Det ser således ud:

artikel
+------------+--------------------------+----------------+-----------------+------------------+
| artikel_id | overskrift               | tekst          | forfatter_navn  | forfatter_email  |
+------------+--------------------------+----------------+-----------------+------------------+
|          1 | Artikel om normalisering | Bla bla bla... | Carsten Gehling | carsten@sarum.dk |
+------------+--------------------------+----------------+-----------------+------------------+
|          2 | Python for nybegyndere   | Nu skal i .... | Carsten Gehling | carsten@sarum.dk |
+------------+--------------------------+----------------+-----------------+------------------+
|          3 | SQL injektion            | Jeg vil kort.. | Squash Guy      | sg@eksperten.dk  |
+------------+--------------------------+----------------+-----------------+------------------+

kommentar
+------------+------------------+-----------------+------------------+---------------------------+
| artikel_id | dato             | navn            | email            | tekst                     |
+------------+------------------+-----------------+------------------+---------------------------+
|          1 | 2003-02-10       | Søren Hansen    | sh@email.dk      | Rigtig god artikel...     |
+------------+------------------+-----------------+------------------+---------------------------+
|          1 | 2003-02-11       | Erik Clausen    | erik@clausen.dk  | Det var dog det arg..     |
+------------+------------------+-----------------+------------------+---------------------------+
|          2 | 2003-03-05       | Tom Andersen    | tom.and@mail.dk  | Jeg forstår ikke h...     |
+------------+------------------+-----------------+------------------+---------------------------+
|          2 | 2003-03-07       | Erik Clausen    | erik@clausen.dk  | Du har endnu engang..     |
+------------+------------------+-----------------+------------------+---------------------------+
|          3 | 2003-03-06       | Tom Andersen    | tom.and@mail.dk  | Tankevækkende!!!          |
+------------+------------------+-----------------+------------------+---------------------------+
|          3 | 2003-03-07       | Pia Jørgensen   | pj@somewhere.com | Fin artikel men...        |
+------------+------------------+-----------------+------------------+---------------------------+
|          3 | 2003-03-07       | Erik Clausen    | erik@clausen.dk  | Lige et spørgsmål mere... |
+------------+------------------+-----------------+------------------+---------------------------+

Begge tabeller opfylder nu kravene for 1NF.

Når du designer tabeller i et relationel databasesystem som MySQL, SQL Server, Access el. så vil du normalt havne i 1NF med det samme. Værktøjerne i systemerne lægger automatisk op til det. Men det er alligevel vigtigt at beskrive, hvad minimumskravene er for 1NF, ellers kan du nemt falde i.

Bemærk, at tabellen “kommentar” ikke har en simpel primærnøgle. Dette er bevidst gjort, for at belyse et andet aspekt ved datadesign: En primærnøgle må gerne være sammensat af flere felter. I dette tilfælde består primærnøglen faktisk af felterne “artikel_id”, “dato”, “email” og “tekst”. Det virker måske grotesk, og det får vi også gjort noget i næste afsnit.

2. normalform (2NF)

2NF går ind og ser på sammensatte nøgler, dvs. nøgler der består af to eller flere felter i en tabel.

Det er som sagt helt i orden at have sammensatte nøgler. De fleste erfarne database designere vælger automatisk at undgå det, men de kan have deres nytte – et emne der ligger udenfor denne artikel.

Reglen for 2NF siger, at alle felter i en tabel skal være afhængig af hele nøglen. Det betyder, at et felt ikke må kunne findes med blot af felterne fra den sammensatte nøgle.

Vi ser nu på tabellerne fra før:

artikel
I denne tabel består primærnøglen alene af feltet “artikel_id”. Da der ikke er tale om en sammensat nøgle, så opfylder tabellen automatisk kravene for 2NF.

kommentar
Som tidligere beskrevet, så består primærnøglen for denne tabel af felterne “artikel_id”, “dato”, “email” og “tekst”. Så langt så godt. Men der er et problem. Faktisk kan feltet “navn” findes alene udfra feltet “email”. Dvs. “navn” er ikke fuldt afhængigt af primærnøglen – du behøver ikke at kende værdien af alle felterne i primærnøglen, for at finde ud af, at forfatteren hedder “Tom Andersen”. Dukal bare vide, at hans e-mail adresse er “tom.and@mail.dk”.

Måden at løse dette problem ligner lidt måden fra før:
1) Lav en ny tabel (vi kalder den “bruger”)
2) Indsæt de felter fra den gamle tabel, som kun er delvist afhængig af primærnøglen (dvs. “navn”)
3) Indsæt de felter fra primærnøglen i den gamle tabel, som felterne fra 2) er afhængige af – disse bliver den nye tabels primærnøgle (i vores tilfælde er dette “email”)

Det giver følgende resultat:

kommentar
+------------+------------------+------------------+---------------------------+
| artikel_id | dato             | email            | tekst                     |
+------------+------------------+------------------+---------------------------+
|          1 | 2003-02-10       | sh@email.dk      | Rigtig god artikel...     |
+------------+------------------+------------------+---------------------------+
|          1 | 2003-02-11       | erik@clausen.dk  | Det var dog det arg..     |
+------------+------------------+------------------+---------------------------+
|          2 | 2003-03-05       | tom.and@mail.dk  | Jeg forstår ikke h...     |
+------------+------------------+------------------+---------------------------+
|          2 | 2003-03-07       | erik@clausen.dk  | Du har endnu engang..     |
+------------+------------------+------------------+---------------------------+
|          3 | 2003-03-06       | tom.and@mail.dk  | Tankevækkende!!!          |
+------------+------------------+------------------+---------------------------+
|          3 | 2003-03-07       | pj@somewhere.com | Fin artikel men...        |
+------------+------------------+------------------+---------------------------+
|          3 | 2003-03-07       | erik@clausen.dk  | Lige et spørgsmål mere... |
+------------+------------------+------------------+---------------------------+

bruger
+------------------+-----------------+
| email            | navn            |
+------------------+-----------------+
| sh@email.dk      | Søren Hansen    |
+------------------+-----------------+
| erik@clausen.dk  | Erik Clausen    |
+------------------+-----------------+
| tom.and@mail.dk  | Tom Andersen    |
+------------------+-----------------+
| pj@somewhere.com | Pia Jørgensen   |
+------------------+-----------------+

I tabellen “kommentar” er feltet “email” nu fremmednøgle til tabellen “bruger”. I tabellen “bruger” er feltet “email” gjort til primærnøglen.

Skulle “Erik Clausen” nu pludselig beslutte sig for at ændre sit efternavn, er det blevet noget lette at administrere. Det skal kun gøre ét sted frem for tre steder tidligere.

3. normalform (3NF)

3NF kræver, at et felt kun er afhængig af primærnøglen. Selvom alle felterne i en tabel overholder 2NF eller at primærnøglen slet ikke er sammensat, så kan der være tilfælde, hvor indholdet af et felt kan bestemmes alene udfra et andet felt i tabellen, som ikke selv er en del af primærnøglen.

Vi ser problemet i tabellen “artikel”. “forfatter_email” er udelukkende afhængig af primærnøglen “artikel_id”, men “forfatter_navn” kan faktisk findes både udfra “artikel_id” og “forfatter_email”. Så tabellen overholder ikke reglen for 3NF. I lærebøgerne kaldes det at “forfatter_navn er transitiv afhængig af artikel_id”. Dvs. forfatter_navn er afhængig af forfatter_email, som så igen er afhængig af artikel_id.

Dette løser vi således:

1) Lav en ny tabel
2) Indsæt de felter fra den gamle tabel, som kun er transitiv afhængig af primærnøglen (dvs. “forfatter_navn”)
3) Indsæt de felter fra primærnøglen i den gamle tabel, som felterne fra 2) er afhængige af – disse bliver den nye tabels primærnøgle (i vores tilfælde er dette “email”)

Nu er det jo så fikst, at vi allerede har en tabel med ovenstående egenskaber – nemlig tabellen “bruger”. Så den tillader vi os at genbruge:

artikel
+------------+--------------------------+----------------+------------------+
| artikel_id | overskrift               | tekst          | email            |
+------------+--------------------------+----------------+------------------+
|          1 | Artikel om normalisering | Bla bla bla... | carsten@sarum.dk |
+------------+--------------------------+----------------+------------------+
|          2 | Python for nybegyndere   | Nu skal i .... | carsten@sarum.dk |
+------------+--------------------------+----------------+------------------+
|          3 | SQL injektion            | Jeg vil kort.. | sg@eksperten.dk  |
+------------+--------------------------+----------------+------------------+

bruger
+------------------+-----------------+
| email            | navn            |
+------------------+-----------------+
| carsten@sarum.dk | Carsten Gehling |
+------------------+-----------------+
| sg@eksperten.dk  | Squash Guy      |
+------------------+-----------------+
| + alle de øvrige brugere fra før.. |
+------------------+-----------------+

Nu overholder alle tabellerne både 1., 2. og 3. normalform. Dermed er du også kommet ud over de problemer, som jeg beskrev i starten:

– Hvis en bruger tidligere skulle skifte navn, så skulle det både ændres i alle records, hvor brugeren havde oprettet artikler og skrevet kommentarer. Nu skal navnet bare ændres én gang i tabellen bruger.
– Det var ikke muligt at oprette en bruger uden samtidig at oprette en artikel. Hvis du gjorde, så ville recorden i den gamle artikel tabel indeholde mangle tomme felter. Det er nu muligt brugeren skal bare oprettes i tabellen bruger.

Afslutning

Der kunne godt laves andre optimeringer på tabellerne. F.eks. er det en god idé at oprette et numerisk felt f.eks. kaldet “bruger_id” som primærnøgle i “bruger” og fremmednøgle i “artikel”. Ellers er det sværere at opdatere en brugers e-mail. Men det er ikke et krav for 1NF, 2NF eller 3NF.

Metoden bringer adskiller data i yderste konsekvens. Det betyder også, at visse dataudtræk (SELECT) kræver, at to eller flere tabeller join’es, en operation der tager længere tid end en simpel select. Derfor kan du somme tider komme ud for, at det godt kan betale sig at bryde med en af reglerne af hensyn til performance.

MEN: Lær først reglerne grundigt. Så er du også mere kompetent til at bryde dem de rigtige steder. 🙂

God fornøjelse.

Test test og atter test

Jeg er nu endelig kommet på den rette vej med TDD. Jeg må jo indrømme, at TDD for mig indtil nu har været “kode først, tests bagefter”, men jeg så forleden lige pludselig “lyset”. Det har også kun taget 2¾ år med Rails at nå dertil… 😉

Hvad gjorde så udslaget for mig? Jo det var faktisk, da jeg læste denne blog http://code.isdangero.us/posts/My-test-driven-Ruby-setup

Jeg kunne godt lide syntaksen i Shoulda. Men det var især Machinist og den lette måde at lave test-data på, som gav mig en “aha-oplevelse”. Fixtures er besværlige at lave, og det er nemt at knække eksisterende tests, når man tilføjer flere tests. Machinist ændrer på alt det, og det gik pludselig op for mig, at det netop var dét, der var bremsen for min omvenden.

Men for pokker hvor er der pludselig mange forskellige frameworks/ libraries til TDD/BDD. Det er jo nærmest en jungle. Det er sjovt, at hvor de fleste bare accepterer ActiveRecord og de øvrige konventioner i Rails, så bruger rigtig mange tilsyneladende alt muligt andet end Rails’ egent test-suite.

Hvilken kombi bruger i og hvorfor? Hvor nemt har i ved at teste først og kode bagefter? Jeg er gammel i gårde, og jeg må indrømme, at det er en af de steder, hvor jeg har svært ved at ændre gamle vaner.

– Carsten

Samtaler med et træ

“Informationssamfundet er et sted, hvor alle træer vender på hovedet.”

Samtaler med et træ

Samtaler med et træ

Sådan begynder dialogen i bogen “Samtaler med et træ”, skrevet af Carsten Graff. Bogen er bestemt ikke ny – jeg læste den, da den udkom i 1996. Men det er til dato den bog, der har haft den grundigste inflydelse på mit syn på IT. Det er interessant at se, at hvor vi med bla. Etisk Råd har alverdens restriktioner omkring bioteknologi, så tager vi nærmest ukritisk al ny informationsteknologi til os. “Samtaler med et træ” stiller relevante kritiske spørgsmålstegn ved denne fascination.

Jeg anbefaler alle at købe den og læse den – ikke mindst folk i mit eget fag. Den kan stadig købes for kr. 100,- ved at kontakte kade@stemningshotellet.dk.

Jeg har netop lige købt den igen, fordi mit oprindelige eksemplar er væk. Den ligger sikkert hos en eller anden stakkel, som jeg har prakket den på. Det sjove er, at mit køb netop nu falder sammen med, at bogen udkommer i en engelsk version på det amerikanske marked.

Jeg venter på, at den kommer med posten, og jeg glæder mig meget til at læse den igen. Det bliver som at besøge en god gammel ven, jeg ikke har set i mange år. Og jeg er spændt på, om den stadig holder – 13 år efter at den udkom.

Facebook er 80% spild af tid, Twitter et råbekor

For nogle måneder siden lukkede jeg endelig min Facebook konto. Indtil da havde jeg været aktiv i mere end et år og desværre brugt al for meget tid derinde på ingenting. Facebook spammede mig med forespørgsler fra mine venner og bekendte, der mere eller mindre bevidmasse-sendte invitationer til horoskoper, kend-din-type, og hundredevis af andre ligegyldige applikationer. Somme tider blev jeg lokket – jeg havde nok brug for nogle overspringshandlinger, og så var det jo nemt.

Én ting var jeg dog glad for ved Facebook: Statusopdateringen og de kommentarer, som vennerne skrev dertil. Men alt andet på facebook regner jeg for ligegyldigt, og derfor er det simpelthen ikke nok til, at jeg vil bruge det.

Jeg valgte så at prøve Twitter, for den fokuserer udelukkende netop på denne funktion. Efter 6 måneder med Twitter må jeg dog desværre konstatere, at det gør den ikke særlig godt. Facebooks statusopdatering bød op til dialog. Hvis en ven skrev noget sjovt, kunne man så kommentere netop dette, vennen kunne svare tilbage og andre kunne også deltage. Altsammen kan ses i ét billede.

På Twitter er det anderledes. Her får man fornemmelsen af, at alle bare sidder og taler i munden på hinanden, uden at interessere sig for, hvad de øvrige siger. Man kan svare direkte til hinanden, men det får aldrig fornemmelsen for dialog frem.

Så nu gider jeg heller ikke det mere 🙂 Er jeg en kritisk bruger? Ja. Men det synes jeg også, at man skal være. Jeg hører nok bare til kategorien over 30 ifølge Douglas Adams. Jeg har længe tænkt på, hvornår jeg ville støde på noget, der ville give mig den reaktion. Det er så tydeligvis Facebook og Twitter.

Anyway: Kunne jeg få Facebook’s statustjeneste, uden alle dens øvrige ting + Twitter’s lækre 3rd-party værktøjer – ja så ville jeg nok være en glad mand.