Observasjoner fra en forfatter

Før og etter jul har jeg brukt mye tid på å lage ny 3. utgave av "Webprogrammering i PHP" (http://phpbok.no). Det var en lang, men lærerik prosess sammen med Gyldendal. Det er slitsomt å komme i gang, for det er et aldri så lite fjell å bestige. Hva innebærer prosessen med å skrive bok, og vedlikeholde den i ettertid? Hvordan kommunisere korrekturfeil på en effektiv måte? Fins det tips og triks for å skrive bedre norsk?

Disclaimer: Dette blogginnlegget kan inneholde grammatiske feil. I en eventuell 2. utgave av dette blogginnlegget vil trolig korrekturleseren ha oppdaget de fleste, og språket være ytterligere perfeksjonert.

STEG 0. Snart tomt for bøker:

Gyldendal følger med i timen og varsler fra når det nærmer seg tomme lagerhyller. Det er da, så vidt jeg har skjønt det, tre valg:

• Trykk opp på nytt, men nytt opplag (jeg må endre teksten på kolofonsidene først i boka om trykkeri, ISBN-nr etc)
• Trykk opp på nytt, men som ny utgave (jeg må gjøre litt større endringer som gjør at sidetall forskyves og tekst byttes ut)
• Levetiden er over, salget er for dårlig og boka fjernes fra sortementet

For min del var det alternativ to som slo til. Ny utgave, masse jobb og bare å bygge seg mentalt opp. Det er lurt å få en endelig sluttdato, og det er lurt å starte i god tid før denne sluttdatoen (men lett er det ikke).

STEG 1. Installasjon av programvare:

Før du får gjort noe som helst med skriveprosessen, må skriveprogramvaren installeres og fungere som det skal. Adobe FrameMaker brukes av forfattere hos Gyldendal/TISIP. Det er et enormt stabilt program som støtter 100 % godt opp om skriveprosessen, men et problem for mange er at bruksterskelen er noe høyere enn Word. Manglende fonter (skrifttyper) kan også være et problem, men jeg har alt i en mappe: Programvare, fonter, kildefilene til boka og også hjelpeinstruksjoner jeg selv lagde tilbake i 2004 da boka ble skrevet første gang. Det var noen år siden sist jeg lærte meg FrameMaker. Jeg ble overrumplet av mine egne fingre som automagisk gjorde noen hurtigtast-kommando-kombinasjoner, og vips, var stilen "2 punkts dummy" satt inn over en ny figur - akkurat slik den skulle i henhold til den profesjonelle Gyldendal-malen. Boka består av 14 kapitler, og hvert kapittel er lagret som én fil. Alle bilder og figurer er for øvrig lenket inn i hver kapittelfil. Figurer med piler, bokser og liknende er laget i Microsoft Powerpoint, og som følge av lenkingen er det bare å dobbeltklikke på en figur, så spretter Powerpoint opp og jeg kan endre figuren som ønsket, lagre, og alt er oppdatert i boka. Heldigvis slapp jeg unna feil i selve FrameMaker-oppsettet.

STEG 2. Planlegge endringer:

Jeg har samlet kommentarer både fra tilbakemeldinger (skjema på websidene mine), fra lærere rundt om i landet som bruker boka i undervisning, og som jeg har pønsket ut selv. Jeg lagde meg en gjøremålsliste som et eget dokument. Denne ble to A4-sider lang. Jeg har aldri helt skjønt vitsen med funksjonen "gjennomstreking" i vanlige tekstbehandlere, men nå fikk den mening: strek gjennom ting etterhvert som de gjøres, for da ser jeg hva som er gjort. Det er også motivasjon i dette. Endringene mine var i grove trekk:

• Oppdatere installasjonsrutinene for hvordan PHP, MySQL og Apache installeres.
• Endre all HTML-kode til XHTML-form. Det skulle vært gjort fra starten av, men er i hvertfall på plass nå.
• Fjerne stoffet om register_globals.
• Ta med litt mer om MySQLi.
• Rette feil.

Todo-listen er vist i figuren under og gir et visst inntrykk av hva en slik ny utgave kan innebære av arbeidsoppgaver.

STEG 3. Ta inn over seg ikke-planlagte endringer:

Deretter viste det seg at det var behov for en ny korrekturrunde, da "et par kommaleifer" i de forutgående versjonene var oppdaget på tross av en grundig vask i 2004. Begrepet "et par" kan bety "2" (dette visste jeg) men også "1500" (det vet jeg nå). Med mellom 3-5 kommafeil per side i snitt, og 400 sider totalt i boka, er det ikke overdrevent å si at det var minst 1500 kommafeil som måtte rettes ...

STEG 4: Just do it:

1500 kommafeil og ymse skrivefeil... For en jobb! Den beste metodikken når du er kommet så langt, er "just do it". Sett i gang, og det går gradvis fremover.

STEG 5: Lær deg å lese korrekturspråket:

Jeg vil påstå at jeg behersker følgende språk: Norsk, nynorsk, engelsk, tysk, fransk og korrektur. Korrekturspråket er trolig ukjent for de fleste. Det har en spennende syntaks og er et språk som kan læres relativt lett. Jeg lærte det av meg selv, mens jeg leste, ved å tenke meg til hva som var riktig og hva som var galt. Tegnene er snedige, men de er faktisk ganske smarte. La oss gå gjennom anmerkningene i figuren under for å forklare hvordan profesjonelle korrekturlesere formidler sine funn til forfatterne:

I rekkefølge ser vi følgende kommunikasjon fra korrekturleseren uti margen til høyre:

• fjern kommaet
• komma etter "r"
• komma etter "8"
• slå sammen e og s og sett bindestrek mellom
• fjern kommaet
• komma etter "n"
• punktum etter "g"
• fjern komma etter "dagen"
• komma etter "h"

Legg merke til hvordan korrekturleseren på en kompakt, presis og unison måte klarer å formidle hva som er feil og hvordan det kan rettes opp. Det er altså tegn for å slå sammen bokstaver, koder for å legge til og for å slette. En uerfaren skribent kan tro at det er forskjell på andre og tredje kommafeil (ref listen over og i figuren), men det at vinkeltegnet foran "r," og "8," går ulik vei, har faktisk bare å gjøre med at korrekturleseren har behov for å skille de to fra hverandre. Det er her snakk om samme type feil, men likevel to instrukser. Det blir viktig å knytte instruksene til riktig feil i tilfelle det er forskjellig type feil i nær avstand. Videre har jeg funnet ut at det krøllete tegnet visstnok står for "delur", eller var det "delatur", som uansett betyr å slette (nesten som delete på datamaskinen).

STEG 6: Skjerp deg til neste gang:

Det er gunstig for egenmotivasjonen å betrakte korrekturleserens tilbakemeldinger som noe positivt, for eksempel "mulighet for læring". Jeg har unektelig lært en hel del av korrekturen og håper nå å aldri se en kommafeil og andre flaue formularer igjen i mine kommende produksjoner. I god delingsånd avsløres noen av mine tips og triks som kan være til nytte for alle som skriver bøker eller andre mer seriøse tekster:

• Kommaet skal med stor sannsynlighet være stikk motsatt av det du selv tror. (Hvis du bytter om, så er det antakeligvis stikk motsatt da også, så det er kanskje like greit å gi opp først som sist :-)
• Husk at det ikke skal være komma foran ordet "og". Bare av og til. Plasser derfor et komma foran "og" med jevne mellomrom, men ikke overdriv.
• Jeg bruker trolig orddeling med binde-strek altfor mye i mine skriblerier. Et ord som "sekund-delen" skal ikke deles, har jeg erfart, men for å forsvare meg selv tror jeg at jeg tenderer mot å dele ord som jeg selv legger inn pause i når jeg uttaler det muntlig. Mulig det er fordi jeg er nordlending at det blir pause når jeg sier "sekund-delen" muntlig? Altså at palataliseringseffekten slår ut i slutten av "sekund" og dermed ødelegger noe? For å gjøre det hele mer komplisert, skal ord som hash-funksjon vitterlig deles med bindestrek. Det er mulig at dette skyldes at de uttaler slike ord nokså "tregt" nedpå Østlandet ;-)
• Ordet "automagisk" passerte heldigvis språkvasken også i denne korrekturrunden! Jeg antar det er fordi Gyldendal har innlemmet ordet i sitt vokabular etter at det med viten og vilje ble snik-innført i min 1.utgave (eller skal det være "snikinnført"?)
• "Webprogrammering i PHP" er ei bok om programmering, mer nøyaktig om å lage dynamiske og interaktive, solide websider/systemer. Boka har mange eksempler på programkode som forklares og drøftes i teksten. Språkvaskeren (som for øvrig var meget dyktig) - gikk grundig til verks og rettet språkleifer i selve programkoden! Det er ikke bare imponerende, men viser også at webprogrammering er i ferd med å ta av og når ut til stadig nye målgrupper (nå også korrekturlesere). Fra spøk til alvor: Problemet er bare at disse leifene også reflekteres i skjermbildene mine. Hvis en kodesnutt har kode for å oppsummere valgt flyreise etter en flybestilling, og jeg i output-teksten har skriveleifer - så hjelper det lite å rette feilene i programkoden fordi da må jeg også ta nytt bilde av skjermen/websiden. Det må være samsvar mellom figurene og programkoden. Grammatiske feil i koden er altså ikke-trivielle å rette. Skjermbilder må nemlig lagres som TIFF og behandles i Photoshop slik at de får riktig fargerom - noe jeg husket lite av fra 2004. Resultat: Programkoden i boka er visse steder preget av programmeringslærer-norsk, mens teksten i boka bærer form av norsklærer-norsk.
• Det å "gjentegne" er ikke noe ord. Når jeg nå ser at det står alene, og ikke i kontekst, er jeg faktisk ganske enig. Hva skulle vel "gjentegne" bety? Hmmmm.
• Vær konsekvent. Når korrekturleseren (eller du) oppdager et ord som er feil, så søk gjerne opp alle forekomster av dette ordet og erstatt først som sist. Ikke fall for fristelsen å kjøre så effektivt som mulig ved å velge "erstatt alle". Det kan få uforutsette konsekvenser hvor du mister tekst eller får nye rare ord som resultat. Jeg prøvde denne snarveien uten å tenke på endelser som ville bli feil, og resultatet ble at jeg fikk 3 timers ekstra ryddejobb. Småkjedelig, men en fin erfaring.
• Jeg lukter forresten at hele denne punktlisten trolig vil måtte omskrives med tanke på orddeling, kommaets plassering og tungt språk hvis en korrekturleser får snus i den :-)

STEG 7: Lag ordliste over dine terminologiske uvaner underveis:

Dine feil er deg allerede tilgitt, men du har samtidig en gyllen mulighet til å unngå å falle tilbake til gamle synder. Vil du skrive godt i alle sammenhenger, bør du vende gamle vaner først som sist. Her er mine vanligste feil som jeg heretter skal prøve å få riktig i all skriftlig kommunikasjon:

Punktlisten tar formen: Det heter ikke ... men ...

• anderledes ... annerledes
• etterhvert ... etter hvert
• adskilt ... atskilt
• syv ... sju
• inni ... inne i

En korrekturleser har allerede fått snusen i dette blogginnlegget før det er publisert, og skriveprosessen avbrytes derfor av en il-melding fra Gyldendal med følgende opplysning: Syv/sju og inne i /inni representerer valgfrie former. Har man først valgt den ene formen, bør den gjennomføres konsekvent. Ok, da forstår jeg og er faktisk litt lettet. La oss fortsette listen:

• forklaring til ... forklaring på
• mulighet til ... mulighet for
• tilslutt ... til slutt (ok, den kjøper jeg)
• i det ... idet (noe skjer)
• forståelse for ... forståelse av
• ettersom ... etter som
• tungvindt ... tungvinn

Hepp, hepp, hepp... Ikke så fort nå! Ny oppklaring fra Gyldendal: Forståelse for / forståelse av er begge gangbare uttrykk, men de betyr forskjellige ting. Forståelse for uttrykker gjerne en slags empati, mens forståelse av gjerne brukes i betydningen ”oppfatte/skjønne” Det samme gjelder ettersom (= da/siden) og etter som (= etter hvert som). Tungvinn brukes når det står til et hankjønnsord; tungvint når det står til intetkjønn. Observasjon til deg som leser fra meg: La du merke til den elegante bruken av semikolon fra Gyldendal her?!! La oss fullføre listen:

• potensiale ... potensial
• tvert i mot ... tvert imot
• priviligert ... privilegert (den er vrien og jeg tipper at de fleste skriver dette ordet feil. Tenk på "et privilegium")

Siden jeg har skrevet bok om webprogrammering, tenker jeg umiddelbart at jeg ikke bør skrive en slik ordliste på papir og heller ikke i et digitalt dokument. Jeg bør rett og slett lage en database og et tilhørende web-grensesnitt hvor brukeren kan legge inn ord som staves feil i ett tekstfelt, og ordets riktige form i neste tekstfelt. Dette var en god idé! Søk etter ord er en viktig funksjonalitet å lage. Systemet kan utvides med flere brukere, og da bør innlogging på plass og validering av inngangsdata for å unngå hacking er et must. Fordelen med å tillate flere brukere i et slikt system, er at da kan en dele ord med andre, se på andres ordlister, stjernemerke favorittord, bli venner med andre som har samme ord på sin liste, og så videre. Hmmmm, dette skal jeg gjøre - det blir jo en slags Facebook for språkinteresserte, og det er meget lett å realisere når en kan PHP!
Nei, forresten, dette blir vel for nerdete! Nå tar jeg helt av og bør heller prioritere det som må gjøres av forsømte oppgaver fremover. Men kanskje du som leser boka vil lage et slikt system? I så fall vil jeg gjerne registrere meg som bruker!

STEG 8: Puh, endelig ferdig ...

... eller bare nesten. Du er riktignok ferdig med bokskrivingen, men får skriveabstinenser og har et par timer senere skrevet et lengre blogginnlegg om prosessen.

STEG 9: Blogginnlegg publiseres:

Av gammel vane sendte du blogginnlegget til Gyldendal for korrekturlesing. Det kommer i retur med et par anmerkninger, og først nå kan du publisere det.

STEG 10: Etterarbeid:

Det meste begynner på 0 i programmering (indeksverdier i arrays/tabeller/matriser for eksempel). Den oppmerksomme leser ser at også denne listen starter på 0, så dette er faktisk det ellevte steget. Selv om en tilsynelatende er ferdig, vil forfatteren gå inn i en langtekkelig fase der neste utgave av boka planlegges mentalt, gradvis. Tanker modnes og en følger jevnlig med på utviklingen av fagfeltet på jakt etter nye ting som må oppdateres. Ambisjonen om å skrive noe bonusmateriell og lage noen filmklipp som legges ut på bokas ressursside (http://phpbok.no/) skal realiseres, men bare ikke akkurat nå. Kanskje i morgen.

Slik var altså min bokprosess. Jeg kan dessverre ikke garantere mot verken kommafeil eller orddelingsregelbrudd i dette innlegget, men håper det var litt nyttig å få vite hva som kreves av vedlikehold i forbindelse med en bokutgivelse. Vil du skrive bok, så er oppfordringen min: Gjør det! Du lærer enormt mye både faglig, av skriveprosessen og av kommunikasjonen med forlaget. Det tar tid, men du kan søke om stipend (jeg fikk ikke) eller kanskje få aksept av en oppegående arbeidsgiver om at det er nødvendig med sammenhengende tid til å skrive (det fikk jeg). Du vil aldri angre, så ikke nøl, og lykke til!

1234567890

"Akkurat nå" er et historisk sekund. Nå er nemlig klokka nøyaktig 1234567890!

I dataverden er det viktig å telle sekunder, men det ville blitt litt vel mange om en skulle begynt å telle ved Kristi fødsel. 2000 år med sekunder, blir et uhensiktsmessig stort tall. En bestemte seg derfor rett og slett for å lage en helt ny tidsregning til bruk i dataverdenen. Denne heter Unix time, Posix time, eller Unix epoch om du vil, og i dataverdenen snakker en ofte om et (Unix) tidsstempel.

Det er mulig du leser dette for sent til å overvære hendelsen, men med "akkurat nå" menes i det sekundet dette innlegget ble publisert. Dette er en sannhet med modifikasjoner, fordi innlegget ble publisert den 14.februar 2009 kl 00:31, uvisst nøyaktig på hvilket av de 60 sekundene i minutt 31. På dette tidspunktet sov jeg forresten, men jeg fikk til å publisere sånn omtrentlig på Unix-tidspunktet 1234567890 rett og slett takket være Unix time! [1]

Unix time fungerer på følgende måte:

• "Klokka" startet på tallet 0 den 1.januar 1970 (UTC-tid)
• Hvert sekund øker tallet med 1, så den 2.januar 1970 var Unix time blitt 60 sekunder x 60 minutter x 24 timer = 86.400. Unix time øker altså med 86.400 hvert døgn.
• Det tas ikke hensyn til såkalte Leap Seconds [2]. Leap seconds er juksesekunder som legges til våre vanlige klokker (dvs atomklokkene) for å justere tiden slik at den er helt i synk med jordrotasjonen. Unix time har altså ikke slike juksesekunder, og sakker dermed etterut sammenliknet med vår tid...

Akkurat nå (når dette innlegget ble publisert) er altså klokka 1234567890, eller 1.234.567.890 for å tydeliggjøre hvor stort dette tallet er. Altså litt over 1 millliarder. Eller 14.februar 2009 kl 00:31:30 sagt på forståelig norsk!

Hvis Unix time øker hvert sekund, når passerte da Unix time 1.000.000.000? Det skjedde den 9.september 2001 og ble feiret av datafolk verden over, blant annet en kollega. Hendelsen medførte også problemer. Noen datasystemer taklet nemlig ikke at tiden passerte 999.999.999. Vi støter nok på et nytt problem i januar 2038, for da er grensen nådd for hvor stor Unix-tallet kan bli for de systemer som har avsatt "bare" 32 bits til klokkeinformasjonen. Et 32-bits tall representert binært, kan bare bli en viss størrelse stort, og denne størrelsen er antall sekunder som forekommer på ca 136 år. Fra 1970 til 2038 er det 136 år? Nei, det er det ikke, men hvis du går like langt bakover i tid (noe mange datasystemer gjør) så blir det totalt 136 år. Fra 1970 til 2038 er det nemlig 136/2 = 68 år, og fra 1970 til 1901 er det også ca 68 år. Spennet går nøyaktig fra 13.desember 1901 til 19.januar 2038, og er på ca 136 år. Hva som typisk vil skje når den binære representasjonen av 2038 nås, er vist i figuren under (hentet fra Wikipedia)

Det er lett å regne med sekunder. I programmeringsspråk fins det en rekke funksjoner for å omgjøre fra et Unix tidsstempel til det tilsvarende tidspunktet i vanlig datoformat, og omvendt. Selv liker jeg best PHP som språk, og da kan du for eksempel finne ut hvilken dato det er nøyaktig 8 uker fra nå av. I PHP brukes da funksjonene time() og date(), slik:

  $datoenOm8Uker = time() + (7 * 8 * 24 * 60 * 60);
  echo 'Nå er det den:       '. date('d-m-Y') ."\n";
  echo 'Om 8 uker er det den: '. date('d-m-Y', $datoenOm8Uker) ."\n";

Poenget er at funksjonen time() returnerer tidsstempelet som er akkurat nå (hos tjeneren der PHP-programmet utføres). Dette er altså et tall som er antall sekunder siden 1.januar 1970. For å få datoen 8 uker fram i tid, er det bare å plusse på det antall sekunder som 8 uker er, med andre ord 60 sekunder i 60 minutter i 24 timer i 7 dager i 8 uker. Enkelt og greit! Variabelen $datoenOm8Uker har nå et tall som er over 1 milliard stort og som representerer 8 uker fram i tid. Dette tallet (som nå er i sekunder) kan gjøres om til en menneskelig lesbar dato på ønsket form ved å sende det inn som andre argument til funksjonen date(). Dette er gjort i siste setning.

Et tankeeksperiment: Per og Kari har kanskje 39 års bryllupsdag den 11.mai 2009. Dette er interessant nok, men det er mer interessant for den hengivende Per å fortelle sin Kari når de har 1234567890 sekunders-bryllupstid! Siden de giftet seg den 11.mai 1970, så betyr det at de på 14+31=45 dager etter sin opprinnelige bryllupsdag, kan feire 1234567890 sekunder sammen! 1234567890 Unix time tok utgangspunkt i 1.januar (1970) og det er 45 dager mellom 1.januar og 14.februar (uavhengig av årstall). Derfor må bryllupstiden "1234567890" til Per og Kari være 45 dager etter deres egentlige bryllupsdag, altså 45 dager etter 11.mai 2009. Dette betyr videre at dersom du er født en gang etter 14.februar 1970, så kan du bare regne ut og begynne nedtellingen til når du blir 1234567890 sekunder gammel!

Vil du lage deg en PHP-snutt som viser når Per og Kari skal feire begivenheten? Den blir for eksempel slik:

  $datoSomSekunder = mktime(0,0,0,5,11,2009);
  //har nå fått 11.mai 2009 som antall sekunder etter 1.1.1970
  $dagerFramITid = 60 * 60 * 24 * 45;
  $begivenhetenIUnixTid = $datoSomSekunder + $dagerFramITid;
  echo "45 dager etter den 11.mai 2009 er det den: ";
  echo date("d.m.Y", $begivenhetenIUnixTid);

Altså har Per og Kari vært gift i 1234567890 sekunder den 25.juni 2009 gitt at de giftet seg den 11.mai 1970. Her brukes mktime() for å regne om fra en dato til den tilsvarende Unix-tiden. Det fins sikkert enda mer elegante måter å regne om dette på med færre kodelinjer.

Oppdatering noen timer senere: Nedtellingen skjedde for øvrig en rekke steder i verden, også på Twitter (bildet leses nedenfra og opp)

Unix time er ikke nerdete, men gøy, eller hva?

[1]: Datasystemer, for eksempel bloggen min hos Google, kan nemlig publisere ting automatisk frem i tid. Dette er basert på når den tilsvarende Unix-tiden for publisering (publiseringstidspunktet jeg har satt) "blir tatt igjen" av den virkelige Unix-tiden som tikker og går. Snedig. Det er muligens bare en teller som øker og øker for hvert sekund og to tall som hele tiden sammenliknes, men det er trolig implementert på en litt mer effektiv måte i operativsystemet på tjeneren hos Google. Unix time er i bunn og grunn en teller, og de fleste datasystemer gjør bruk av slike tellere på en eller annen måte.

[2]: Siste gang et leap second ble lagt til, var på nyttårsaften 2008. Unix time legger altså ikke plutselig til et ekstra sekund, og det er rett og slett fordi at om en la til et ekstra sekund når resten av verden gjør det, så vil det nærliggende sekundet "forsvinne". Dette betyr i praksis at noen tall ikke eksisterer, og det passer dårlig i dataverdenen å hoppe over noe ved telling eller å si at et tall ikke eksiterer. Det kan for eksempel medføre at en if-test aldri blir utført, noe som er uholdbart fra et programmeringsteknisk synspunkt.