FAGBOK: "Blink - The Power of Thinking Without Thinking" av Malcolm Gladwell

Vi gjør hele tiden valg basert på magefølelse eller intuisjon - enten vi vil eller ikke. Men dette er jo ikke regnet som særlig seriøst. Så vi analyserer og går i dybden. Men det viser seg ofte at det er godt samsvar mellom vår første, intuitive oppfatning og resultatet vi kommer til etter grundig analyse...

Et kjent eksempel er jobbintervjuer. Det er vanligvis svært god korrelasjon mellom intervjuerens oppfatning av kandidaten etter de første 20 sekundene av intervjuet og om kandidaten faktisk får et jobbtilbud.

Denne boken analyserer slike mekanismer. Hvordan virker de og hvor pålitelige er valgene vi foretar. Han går gjennom resultatene av en rekke psykologiske tester som er ganske oppsiktsvekkende.

Eksempel: En gruppe studenter ble vist videoklipp av en rekke lærere. Så skulle de vurdere hvor dyktige de mente de forskjellige lærerne var. Videoklippene var uten lyd og hvert klipp var bare to sekunder. De samme lærerne ble senere evaluert av studenter som hadde hatt dem som forelesere ett semester. Det var godt samsvar mellom vurdering fra gruppen som hadde sett video og gruppen som hadde hatt dem som forelesere.

Videre viser forfatteren hvordan man kan manipulere mennesker ved å benytte disse mekanismene. Det er enkelt å plante ord og begreper hos folk. Dette vil prege deres intuitive adferd.
Eksempel: To grupper får hver sin liste av setninger hvor ordene en stokket. Oppgaven deres er å raskest mulig forstå setningene. Men i virkeligheten får gruppe én setninger med mange "sinte ord". Gruppe to får setninger med mange "snille og tålmodige ord". Etterpå skulle begge gruppene stille seg i kø for å levere sine besvarelser. Køen var lang og det gikk veldig sent. Gruppen med de "sinte ordene" ble vesentlig raskere utålmodig og irritert enn gruppen som hadde fått "snille og tålmodige ord".

Dette er for øvrig teknikker som benyttes av underholdere som for eksempel Derren Brown.

Jeg synes dette var en veldig fascinerende bok. Og det er jo deilig å få bekreftet at min intuisjon har rett :-)

Kan kjøpes på play.com.

Amazon sier:
Blink is about the first two seconds of looking--the decisive glance that knows in an instant. Gladwell, the best-selling author of The Tipping Point, campaigns for snap judgments and mind reading with a gift for translating research into splendid storytelling. Building his case with scenes from a marriage, heart attack triage, speed dating, choking on the golf course, selling cars, and military maneuvers, he persuades readers to think small and focus on the meaning of "thin slices" of behavior. The key is to rely on our "adaptive unconscious"--a 24/7 mental valet--that provides us with instant and sophisticated information to warn of danger, read a stranger, or react to a new idea. Gladwell includes caveats about leaping to conclusions: marketers can manipulate our first impressions, high arousal moments make us "mind blind," focusing on the wrong cue leaves us vulnerable to "the Warren Harding Effect" (i.e., voting for a handsome but hapless president). In a provocative chapter that exposes the "dark side of blink," he illuminates the failure of rapid cognition in the tragic stakeout and murder of Amadou Diallo in the Bronx. He underlines studies about autism, facial reading and cardio uptick to urge training that enhances high-stakes decision-making. In this brilliant, cage-rattling book, one can only wish for a thicker slice of Gladwell's ideas about what Blink Camp might look like. --Barbara Mackoff

Terningkast 5

FAGBOK(?): "Cat Confidential" av Vicky Halls

Vicky Halls jobber som katterådgiver. Det vil si at hun kommer hjem til folk og hjelper dem med å forstå sin katt og helbrede problemadferd. Det er naturligvis ikke så lett hvis din katt skvetter urin i ansiktet ditt når du har andre folk på besøk....

Noen hovedpunkter i boken:

Man bør unngå antropomorfisme.
Med andre ord skal man ikke tro at katten tenker som et menneske - "cats are not small people in fur coats". Dette fører til frustrasjoner på begge sider siden signaler feiltolkes. Så selv om man selv er glad i at naboene stikker innom på besøk så er neppe katten glad for at andre katter kommer inn i hjemmet hans. Kattens hjem er hans slott og det er viktig for den å kunne føle seg trygg der.

Katter er ikke hunder.
De har ikke noe flokkinstinkt og trives best som eneste katt i huset. Det finnes unntak fra dette med for eksempel kattesøsken som trives sammen. Men det er meget vanskelig å føre en ny katt inn i huset hvor en annen katt bor.

Katter kan terrorisere hverandre på måter som er vanskelig for oss å oppdage.
Mange folk oppdager at den gjenlevende katten blomstrer opp når samboeren dør. En mye brukt terrormetode er at den ene katten vokter kattedoen slik at den andre ikke får tilgang. Dette blir ofte ikke oppdaget før den stakkars katten som ikke får gått på do får "uhell" rundt i huset. Det anbefales n+1 kattedoer i en husholdning med n katter.

Katter kan lett kjede seg.
Og da kan de begynne å gjøre ting som vi ikke liker. Eksempel er damen som stadig ble angrepet av sin katt og klort. Katterådgiveren fant ut at katten brukte dette som en fin måte å få oppmerksomhet og adspredelse.
Det ble satt igang to tiltak. Det første var at katten fikk leker og spennende steder som den kunne utforske. Det andre var at eieren iførte seg hjelm med visir, skinndress og støvler. Dermed fikk ikke katten den ønskede reaksjon når den gikk til angrep. Etterhvert mistet den interessen for denne leken.....

Det er i det hele tatt nesten ingen grenser for hva folk er villige til å gjøre for å løse sine katteproblemer. Boken er full av svært morsomme beskrivelser av slike tiltak.

Jeg likte denne boken svært godt. Vi har selv en katt som er svært høyt elsket. (Hun ligger ved siden av meg og maler mens jeg skriver dette). Boken har gitt meg mange tips om hva som bør gjøres for at hun skal få det enda bedre. Etter å ha lest den så dro vi straks av gårde til en spesialbutikk for katteutstyr og kjøpte inn ting som hun trenger - flere leker og spennende ting hun kan utforske. Og hun har fått flere myke liggeplasser rundt i huset for å kunne variere hvor hun ligger og hviler.
Antropomorfismen er ikke så lett å unngå. Men både katten og vi er enige om at det overhodet ikke er et problem :-)

Kan kjøpes på play.com.

Amazon sier:
How much do cat owners really know about their feline friends? Do our pampered pets truly want all that food and affection or is that insistent miaow trying to communicate something more complex? Many cats and their owners co-exist in an atmosphere of polite misunderstanding, with each party blissfully unaware of the wishes of the other. The cat 'says' one thing and the owner hears another, but somehow it works, Until, that is, something goes wrong. Renowned cat counsellor Vicky Halls has helped hundreds of owners and their problem cats. Why do they soil in the house, fight with next door's cat, behave aggressively towards people or pull out their own fur? CAT CONFIDENTIAL answers these questions and many more, and will enable all cat owners to reach a far better understanding with their feline companions. Fascinating, funny, heart-warming and occasionally tear-jerking, CAT CONFIDENTIAL explores the hidden workings of the unique bond that people have with their cats. In a book filled with case studies, amazing facts, amusing anecdotes and practical advice, Vicky Halls has finally revealed the innermost secrets of the feline psyche.

Terningkast 5

FAGBOK: "Pro Apache Log4j" av Samudra Gupta

Log4j er en de facto standard for logging i Java-programmer. Man kan legge inn masse logging når koden skrives. Så kan man styre hvor mye av loggingen som skal utføres når applikasjonen kjører. Dette gjøres via konfigurasjonsfiler og kan endres uten å endre applikasjonen. Så i test kan man ha masse logging, men når applikasjonen settes i drift vil man nok bare logge feil og uventede hendelser. Og dersom rare feil begynner å oppstå så kan man skru på logging i de relevante moduler.

Og det er mer: man kan logge til filer, sende loggmeldinger per mail, via telnet, via sockets og meldingskøer. Og loggmeldinger kan formatteres på mengder av måter. Og de kan filtreres hvis man vil styre dem enda mere detaljert.
Og hvis man stadig ikke er helt fornøyd så kan man skrive sine egne komponenter for logging.

Da jeg kom i et prosjekt som brukte Log4j så hadde jeg lyst til å forstå dette ordentlig. Og da kjøpte jeg altså denne boken.

Og boken er bra. Forfatteren kjenner tydeligvis Log4j i stor detalj og graver seg ned til de minste detaljer. Han skriver godt og med stor entusiasme. Selv om han kanskje sliter litt med å få nok stoff til en hel bok om emnet....

Etter å ha lest boken kjapt gjennom så føler jeg at jeg forstår Log4j rimelig godt. Og boken er en fin oppslagsbok som jeg kan gripe til den dagen jeg trenger det.

Kan kjøpes på amazon.

Amazon sier:
In development scenarios where things can't be run in a debugger, or when you run the risk of masking the problem, logs are the greatest source of information about running a program. Pro Apache Log4j, Second Edition provides best practices guidelines and comprehensive coverage of the most recent release.

Step by step, the book explains core concepts, from basic to advanced. Code samples are in Java and include guidelines for different application-specific needs. You'll also learn how to extend the API to write custom components and best practices for using the feature-rich log4j API. This book concludes with enterprise Java applications using log4j with JSP and J2EE.

Terningkast 5

FAGBOK: "Effective Java Programming Language Guide" av Joshua Bloch

Joshua Bloch har vært en sentral aktør i utviklingen av Java hos Sun. Han jobber nå hos Google. Han er også kjent for foredrag om Java Puzzlers hvor han presenterer små programsnutter som ihvertfall ikke jeg pleier å tolke riktig....

I denne boken tar han for seg 51 regler for god Javaprogrammering. For hver slik regel så begynner han med en detaljert analyse av et problem eller behov. Det er tydelig at han har jobbet med Java hos Sun, fordi analysene hans går svært dypt. Han kan trekke trådene helt tilbake til hva som har vært planen bak en mekanisme og hvordan den har blitt i praksis.
Etter denne analysen så presenterer han sin foretrukne løsning. Han gir detaljerte og gode forklaringer som jeg han funnet svært matnyttige.

Bokes kapitler og det jeg likte best:

Creating and Destroying Objects:
Jeg likte spesielt om hvordan man lager singletons, bruk av factorymetoder istedet for konstruktorer og hvordan finalizers egentlig virker

Methods Common to All Objects:
Veldig nyttig gjennomgang av hashCode, equals og toString.

Classes and Interfaces:
Jeg likte best diskusjonen om a bruke composition istedet for arv.

Substitutes for C Constructs:
Skulle ønske at jeg hadde lest dette da jeg begynte å kode Java. Burde være obligatorisk stoff for alle som er vant til C/C++.

Methods:
Mange nyttige tips, spesielt likte jeg "defensive copying" for å unngå farer når man jobber med muterbare objekter.

General programming:
Navnestandarder, optimalisering, variabelscope...

Exceptions:
Glimrende analyse av hvilke situasjoner som skal håndteres med exceptions. Og når man bruker checked vs unchecked exceptions.

Threads:
Masse nyttig stoff om synkronisering.

Serialization:
Spesielt nyttig om readResolve.


Men husk at dette er bare det som jeg likte best. Det er masse andre interessante punkter.


Den beste måten for meg å forbedre meg som Javaprogrammerer er å jobbe med folk som kan mere enn meg som som er flinke til å hjelpe og forklare (keb og affen). Den nest beste er å lese denne boken. Jeg har fått en serie med aha-opplevelser og jeg har sett gode løsninger på problemer som jeg har jobbet med.

Jeg har lest første utgave av boken. Second Edition kommer snart, så kanskje det er lurt å vente. Eller lese begge to. Jeg kommer ihvertfall til å kjøpe Second Edition når den dukker opp.

Kan kjøpes på play.com.

Amazon sier:
Working solutions to programming challenges faced by Java developers on a daily basis, revealing what to do to produce clear, robust and efficient code. Include rules in short essay form, and the author's 'war stories,' giving advice and insights into nuances of the language.



Terningkast 6

FAGBOK: "Seeing Voices" av Oliver Sacks

Oliver Sacks er nevrologiens rockestjerne. Han er mest kjent for sin bok The Man who Mistook his Wife for a Hat hvor han beskriver pasienter med merkelige nevrologiske lidelser. Han har også skrevet Awakenings som er filmatisert med Robin Williams i rollen som Sacks selv og Robert de Niro i den andre hovedrollen. Han mottar 15000 brev i året fra pasienter som ønsker at han skal hjelpe dem.
Bøkene hans beskriver de merkeligste lidelser, men han beskriver dem alltid på en respektfull måte. Han er høyt repektert både blant pasienter og blant andre nevrologer.

I "Seeing Voices" beskriver han døve og tegnspråk. Han tar to utgangspunkt: En historisk og sosiologisk beskrivelse av døves liv og kultur. Og en nevrologisk/lingvistisk analyse av tegnspråk.

Det er vanskelig å skrive et referat av denne boken. Istedet lister jeg opp noen hovedpunkter:

• Det er ikke noe tilfelle at "dumb" betyr både dum og stum på engelsk. Døve ble omtalt som "deaf and dumb" fordi de ikke kunne snakke og dermed ble oppfattet som dumme.
• Døve bruker "døve" som en betegnelse på at de ikke kan høre, men "Døve" som en betegnelse på deres kultur og (tegn)språk.
• Tegnspråk blir ofte oppfattet som et primitivt språk som ikke kan uttrykke annet enn enkle, konkrete tanker. Dette er ikke riktig. Tegnspråk er et komplett språk med en grammatikalsk oppbygning. Det er like uttrykksfullt som talespråk og er faktisk talespråk overlegent på noen områder.
• Et eksempel på at tegnspråk er et komplett språk er at ordspill er mulig. Det viser seg også at døve med Tourettes og schizofreni får samme forstyrrelser i sitt tegnspråk som tilsvarende hørende får i sitt talespråk.
  
• Tegnspråk er ikke det samme i alle land. Selv små land med få døve har egne, komplette tegnspråk. For eksempel Island som har 70 døve innbyggerer, har et eget og fullverdig tegnspråk.
• Selv om døve altså ikke uten videre kan reise til utlandet og kommunisere med tegnspråk der, så plukker de ganske raskt opp nok til å kunne kommunisere.
• Det finnes samfunn hvor tegnspråk og talespråk sameksisterer. For eksempel på Martha's Vineyeard som alltid har hatt en stor gruppe døve. Her lever døve og hørende sammen uten problemer. De døve bruker tegnspråk mens de hørende veksler mellom tegnspråk og engelsk tilsynelatende uten å tenke over det.
  
• Sacks er tilhenger av Chomskys teorier om av alle mennesker har en innebygget grammatikk. Det er denne grammatikken som ligger i tegnspråk og i vanlige talespråk.
• Skal man lære et språk virkelig godt så må man lære det som småbarn. Det er i alderen opp til tre år at vi hørende (i deler av Norge) lærer å høre forskjell på "bønner" og "bønder". I samme alder lærer de fleste forskjell på ord med "l" of "r". Men ikke japanske barn siden voksne japanere ikke kan forskjellen. Og dermed er det så å si umulig for dem å lære å høre forskjell senere. Hvis døve barn ikke har lært seg tegnspråk som småbarn så vil de aldri kunne mestre det helt.
• Noen foreldre nekter sitt døve barn å bruke tegnspråk. Disse barna vil kunne få store problemer med å i det hele tatt tilegne seg fullverdig språk.

Det er ikke så ofte jeg leser bøker som jeg føler virkelig sprenger grenser. Denne boken gjorde dette for meg. Jeg har dessverre gått rundt med masse ubevisste fordommer mot døve. Boken har også fått meg til å tenke på nytt rundt problemene vi ser idag ved at døve foreldre er skeptiske til at deres døve barn skal få cochlear-implantater.

Kan kjøpes på play.com.

Amazon sier:
Neurologist Sacks ( The Man Who Mistook His Wife for a Hat ) has interviewed disoriented children who lost the sense of hearing before they acquired language skills. Prelingual deafness, he speculates, may be a hidden scourge that stunts the intellectual and emotional development of untold thousands. At the opposite pole of such impoverishment are the philosophy classes and sign-language theatrical events he attended at Gallaudet University, a liberal-arts college for the deaf in Washington, D.C. In an extraordinarily moving and thought-provoking report, he scrutinizes the history of treatment of the deaf, investigates the expressive capabilities of sign language and gauges the linguistic and social pressures faced by deaf people. The closing section documents a 1988 student revolt at Gallaudet that led to the appointment of the school's first deaf president. Illustrations.
Copyright 1989 Reed Business Information, Inc.

Terningkast 6

FAGBOK:"Out of their Minds. The Lives and Discoveries of 15 Great Computer Scientists" av Dennis Shasha og Cathy Lazere

Denne boken beskriver en rekke av de virkelig tunge teoretikerne innen databehandling Folk som har lagt grunnlaget for databransjen slik vi kjenner den idag.

Og det kan jo være morsomt for noen å se at det faktisk har vært gjort noe i bransjen også før Java dukket opp.....

Boken er delt i fire hoveddeler.

Linguist - de som lagde programmeringsspråk
Høydepunkter:

• John Backus er mest kjent for å ha laget Fortran, det første høynivå programmeringsspråket. Han er også kjent for Bachus-Naur Form (BNF) som er en notasjon for å beskrive kontekstfrie gramatikker.
• John McCarthy var opptatt av kunstig intelligens. Siden Fortran ikke hadde mulighet til å benytte rekursjon så lagde han Lisp!

Algorithmists - de som utforsket algoritmer
Høydepunkter:

• Edsger W. Dijkstra jobbet blant annet med algoritmer for å traversere nettverk. Han var også den som "oppfant" semaforer. De to operasjonene på semaforer P og V kommer fra nederlandsk passeren og vrijgeven.
  
• Donald E. Knuth har gjort mer enn de fleste. Hans verk "The Art of Computer Programming" er et standardverk som alle i databransjen kjenner. I tillegg har han en utrolig sans for detaljer - da han ikke syntes tilgjengelig typografiske systemer var bra nok for det han holdt på å skrive, så laget han sitt eget system.
  

Architects - de som konstruerte datamaskiner
Høydepunkt:

• Frederick P. Brooks, Jr. var hovedarkitekt for IBM sin 360-serie av maskiner. Dette var første gang flere modeller fra en leverandør faktisk kunne kjøre samme programmer uten endring. Hans essay-samling "The Mythical Man-Month" er klassisk. Når man leser den så blir man imponert over hvordan han beskrev utviklingsmetodikker som stadig idag er moderne.

Sculptors of machine intelligence - de som prøvde å lage tenkende maskiner
Høydepunkter:

• Edward A. Feigenbaum jobbet med ekspertsystemer. Han er blant annet kjent for Dendral som ut fra data fra massespektrografi kan finne de mest sannsynlige molekylene.
  
• Douglas B. Lenat er kjent for AI-programmet AM som prøver å finne matematiske hypoteser. Det har for eksempel foreslått at "alle liketall større enn 3 er sum av to primtall". Lenat jobber for tiden med Cyc. I mange år har et stort antall personer jobbet med å legge inn generell kunnskap i systemet. Etterhvert er det meningen at det skal kunne svare på spørsmål....

Kan kjøpes på play.com.

Amazon sier:
Over the past fifty years, most of computer science's important inventions have come from innovators who aren't exactly household names. Out of Their Minds describes the lives and discoveries of fifteen unsung computer scientists whose programs have done everything from help engineers manage factories to help cartoonists animate their characters. This well-paced book spans the varied disciplines of computer science and challenges the reader to think about still-unsolved questions: how can we build a computer that works like the human brain, how can we boost the speed of computation, and where all that intelligence and power will take the industry over the next fifty years.

Terningkast 4

FAGBOK: "Innocent Code - a security wake-up call for web programmers" av Sverre H. Huseby

Det finnes andre farer for web-applikasjoner enn de man kan beskytte seg mot med brannvegger og kryptering. Farer som oppstår fordi web-klient og server ikke er skrevet med en gjennomtenkt strategi for sikkerhet. Programmerene må vite om hvilke angrep som kan komme og hvordan applikasjonen må kodes for å kunne motstå disse angrepene.
Rule 1: "Do not underestimate the power of the dark side".

Boken starter med en gjennomgang av HTTP- og HTTPS-protokollene. Her beskrives også cookies og sesjoner.

Neste del av boken beskriver håndtering av input fra klienten til serveren. De viktigste budskapene er

• Serveren kan aldri stole på data som kommer fra klienten. Den kreative bruker kan skrive inn tekst som kan får katastrofale følger på serveren hvis den ikke kontrolleres nøye før den sendes videre til f.eks. databasen. Både SQL-injection og Shell Command injection beskrives, både teoretisk og med morsomme eksempler. Og det beskrives hvordan serverkoden skal skrives for å beskytte seg mot slike angrep.
• Serveren kan ikke stole på valideringer som foretas på klienten. Det er en enkel sak for en bruker å endre klientkoden slik at den f.eks. tillater verdier som den originale koden ville sperret.
• Serveren kan ikke stole på at verdier som den sender til klienten kommer uforandret tilbake. Det finnes f.eks. salgsapplikasjoner som lagrer varesum i et skjult felt i klienten. Det er en smal sak for en bruker å endre klientkoden slik at slike verdier kan endres før de går tilbake til serveren.
• Serveren må sende minst mulig tilstandsinformasjon og feilmeldinger til klienten. Slik informasjon kan være viktig informasjon for en angriper.

Neste del av boken beskriver hvordan en bruker av en web-applikasjon kan angripes. Dette kan f.eks. skje ved at en bruker stjeler en annen brukers sesjon slik at han kan ta over en pågående dialog. Metodene som beskrives er Cross-Site Scripting og Web-trojanere. Det er ikke enkelt å skrive en applikasjon slik at den hindrer slike angrep, men det beskrives mulige løsninger.

Siste del av boken beskriver "hemmeligheter". Det gis en oversikt over sertifikater og kryptering. Og hvordan man skal beskytte sine passord. Og hvordan en applikasjon skal beskytte brukerens passord. Det er jo ikke så mye vits å legge masse arbeid i å lage gode passord hvis en applikasjon er slepphendt med å passe på dem.

Dette er en veldig god bok! Den er godt skrevet og den er virkelig en vekker for både programmerere og brukere av web-applikasjoner. Jeg har også hatt gleden av å høre foredrag om disse emnene av Sverre Huseby.

Kan kjøpes på play.com.

Play.com sier:
This book is much more than a wake-up call. It is also an eye-opener. Even for those who are already awake to the problems of Web server security, it is a serious guide for what to do and what not to do, with many well-chosen examples. The set of fundamental rules is highly relevant. Peter G. Neumann, Author of Computer-Related Risks,and moderator of the Internet Risks Forum (risks.org).
This concise and practical book will show where code vulnerabilities lie and how best to fix them. Its value is in showing where code may be exploited to gain access to - or break - systems, but without delving into specific architectures, programming or scripting languages or applications. It provides illustrations with real code. Innocent Code is an entertaining read showing how to change your mindset from website construction to website destruction so as to avoid writing dangerous code. Abundant examples from susceptible sites will bring the material alive and help you to guard against:; SQL Injection, shell command injection and other attacks based on mishandling meta-characters; bad input; cross-site scripting; attackers who trick users into performing actions.


Terningkast 5

ROMAN:"Virgile's Vineyard: A Year in the Languedoc Wine Country" av Patrick Moon

Forfatteren arver et hus etter sin onkel. Et nydelig gammelt hus med både vinmarker og frukttrær som ligger i Languedoc i Syd-Frankrike.

Han bestemmer seg til å bo ett år der for å se hvordan han trives i området.

Han er heldig og blir kjent med tre personer som hjelper ham å forstå denne delen av Frankrike.

Mano er en nabo som har hjulpet onkelen med småting i huset og på eiendommen. På grunn av dette mener han at han har rett til å forsyne seg fritt av frukt og alt annet han finner...

Mano elsker vin, men har en sint kone som mener at han drikker for mye. Derfor kjører forfatteren og Mano rundt på vingårder i området for å prøvesmake (mye). På denne måten lærer han om vingårder i området, forskjellige druetyper og viner.

Krystina er en rik engelsk dame som bor på det lokale slottet. Hun er glødende opptatt av Languedocs historie. De to reiser rundt og ser på områdets severdigheter mens hun forteller om områdets historie. I tillegg prøver hun å få forfatteren i seng....

Den siste og viktigste av de tre hjelperne er Virgil. Han en ung og meget entusiastisk vinspesialist som ønsker å lage sine egne viner. Han har lite penger, så han må leie vinmarker og utstyr. Det blir derfor mye forskjellige druetyper og mye gammelt og rart utstyr. Han tråkker til og med noen av druene med føttene! Og dukker helt ned i gjæringstankene for å røre om i mosten.

Til Manos store forbauselse er Virgils mål er å lave lite vin. Hans mål er at hver vinstokk skal produsere tre glass vin. På denne måten skal vinen bli intens konsentrert og utnytte smaken i druene maksimalt. For å oppnå dette så jobber han masse med beskjæring og foredling av vinstokkene. Forfatteren jobber sammen med Vergil gjennom hele året. På den måten får han lære hele prosessen i vinproduksjon. Fra beskjæring og stell av vinstokkene, via selve innhøstingen og til pressing, gjæring og tapping.

Dette er en utrolig fin bok for alle som liker vin og Frankrike. Jeg synes jeg har lært masse om druetyper og vinproduksjon. Og mange detaljer om livet i Languedoc som er den fineste delen av Syd-Frankrike.

Kan kjøpes på play.com.

Amazon sier:
Inheriting a badly neglected house in the south of France, Patrick Moon sets out to discover how the Languedoc has managed to transform itself into one of the world’s most exciting wine regions. Virgile, a young winemaker passionately devoted to perfection, offers to initiate Patrick into the mysteries of each season’s work. At the other extreme is Manu, Patrick’s dipsomaniac neighbor, a diehard traditionalist producing a private wine–lake of unspeakable rouge. With Manu as his self–appointed guide, Patrick embarks on a series of lively encounters with growers as varied as the wines themselves. In between these bucolic expeditions, the author struggles to deal with his dilapidated inheritance—an unfamiliar and unpredictable world where the brambles are as tall as the olive trees, the water supply has dried up, and a ferocious animal lies in wait under the roof tiles.



Terningkast 5

FAGBOK: "Refactoring Databases: Evolutionary Database Design" av Scott W Ambler og Pramod J Sadalage

Smidige metoder baserer seg på stadige refactoringer. "Refactor Mercilessly" er en av XP sine viktigste utsagn. Problemet er at det ikke er lett å refactore databaser. Databasene er vanligvis store og tunge å endre. Det er også et problem at det ofte er forskjellige avdelinger i en organisasjon som har ansvar for programkode og for databaser. Det kan også eksistere programmer som bruker databasen og som det faktisk ikke er mulig å endre.

Denne boken prøver å avhjelpe disse vanskene. Den beskriver teknikker for å endre en database i små, kontrollerte steg. Akkurat som den klassiske boken "Refactoring - Improving the Design of Existing Code" av Martin Fowler så inneholder den en lang liste av navngitte refactoringer. En slik refactoring skal gjøre en veldefinert endring uten at systemets oppførsel skal endres. Alle enhetstester skal altså kjøres uten feil før og etter endringen. Det er dessverre et praktisk problem at det ikke finnes gode rammeverk for å lage og kjøre enhetstester for databaser.

Boken beskriver hver refactoring detaljert slik at det skal være enkelt å både analysere og å utføre tilsvarende endringer.

En refactoring vil ha følgende steg:

• Kjøre tester.
• Endre databaseskjema.
  
• Endre kode på programmene som bruker databasen.
  
• Migrere eller endre data som påvirkes av skjemaendringen. Dette er ikke nødvendig for alle typer refactoring.
• Lage mekanismer som gjør at databasen også kan støtte programmer som ikke er endret. Dette kan for eksempel være triggere som gjør at gammel og ny versjon av et felt i databasen blir synkront oppdatert. Det er ikke mulig å lage slike mekanismer for alle typer refactoringer.
• Kjøre tester.

Det er et viktig poeng at man ikke skal gjøre mere enn ett slik steg om gangen. Først når man er helt ferdig med en endring og alle tester går riktig kan man gå videre med et nytt steg.

Refactoringene som beskrives kan deles i grupper. De viktigste er:

Strukturelle refactoringer.
Dette omfatter metoder for å endre struktur på database. For eksempel fjerning, sammenslåing og splitting av kolonner.


Refactoringer for å forbedre datakvalitet.
Her finner vi for eksempel metoder for å innføre kodeverk, organisere primærnøkler og for å flytte data.

Refactoringer for å innføre referanseintegritet.
Eldre databaser er ofte laget uten å benytte tilgjengelige mekanismer for referanseintegritet. I denne gruppen finner vi metoder for å innføre slik referanseintegritet.


Jeg var egentlig litt skeptisk til denne boken. Ofte synes jeg at XP og smidige metoder kan være litt vel lettvinte og kjappe når det gjelder endringsvilje. Men heldigvis var min skepsis unødvendig. Det er ikke noe lettvint med denne boken. Den er meget grundig både i beskrivelse av analyse av endringer og gjennomføring av dem. Denne boken bør være en del av verktøykassen for alle som jobber med databaseorienterte systemer.

Amazon sier:
This is an excellent book that, in my opinion, serves two purposes. First, it is a compendium of well thought-out ways to evolve a database design. Each refactoring includes descriptions of why you might make this change, tradeoffs to consider before making it, how to update the schema, how to migrate the data, and how applications that access the data will need to change. Some of the refactorings are simple ones that even the most change-resistant DBAs will have used in the past ("Add index"). Most others (such as "Merge tables" or "Replace LOB with Table") are ones many conventional thinking DBAs avoid, even to the detriment of the applications their databases support.


This brings me to the second purpose of this book. Many DBAs view their jobs as protectors of the data. While that is admirable, they sometimes forget that they are part of a software development team whose job is to provide value to the organization through the development of new (and enhancement of existing) applications. One of the best DBAs I ever worked with viewed himself as a "Data Valet." He said his job was to make sure the data was presented to applications when and where they wanted and to protect the doors from getting dinged while under his care. Through its first five chapters and then the refactorings that follow, this book will help DBAs expand their view of their role in the organization from one of simply protecting data to one of enhancing the value of data to the organization.


This book is one that you'll keep on your reference shelf for many years to come. Highly recommended.


Kan kjøpes på play.com.


Terningkast 5

FAGBOK:"The Inmates are Running the Asylum - Why High-Tech Products Drive Us Crazy and How to Restore the Sanity" av Alan Cooper

Forfatteren starter med en serie av angrep på dagligdagse dingser. Hvorfor er det så vanskelig å bruke fotoapparatet, hifi-forsterkeren og minibanken? Svaret er at alle disse og mange andre, egentlig er en kombinasjon av en nyttegjenstand og en datamaskin. Og da blir vi ofre for det vanlige problemet med at datasystemer har dårlige brukergrensesnitt.

Han innfører at nyttig begrep som sier noe om hvor vanskelig det er å bruke en gjenstand: kognitiv friksjon. Det angir hvor stor avstand det er mellom en handling og konsekvensen av handlingen. For eksempel så er det temmelig åpenbart hva som skjer når du slår på en spiker med en hammer. Altså har denne handlingen lav kognitiv friksjon. Et datasystem har derimot høy kognitiv friksjon - det kan ofte være meget vanskelig å se sammenhengen mellom en handling i brukergrensesnittet og dens konsekvens.

Han beskriver datasystem som dansende bjørner - du er imponert over at bjørnen i det hele tatt danser. Ikke over at den danser så veldig godt....

Cooper har en del forklaringer på den triste tilstanden:

• Datasystemer utvikles ikke av spesialister på design av interaksjon ("interaction design"). Firmaet som lager systemet tror som regel at de vet hva som trengs selv.
• Systemene designes ikke før de konstrueres.
  
• Programmerere har alt for stor makt. De er en mennesketype som elsker detaljer og bruksanvisninger og har liten forståelse for hvordan vanlige mennesker fungerer. Og det er så morsomt å legge inn nye features!
• Det er ikke mulig å lage et system som tilfredsstiller alle brukere. Systemene ender ofte opp med å gi litt til alle slik at alle blir middels fornøyd.
  

Men det finnes heldigvis lys i den andre enden av tunnelen : Forfatteren har nemlig Sin Egen Metode! Mye av boken går med til å forklare hvor bra denne metoden er og hvilke utrolige suksesser forfatterens firma har hatt.

Metoden kalles målorientert design. Den går ut på å definere en del arketypiske brukere. De beskrives i stor detalj og blir de som definerer systemets forskjellige mål. Så må man velge hvilke av disse brukerne som er viktigs å tilfredsstille og hvordan systemet skal lages for at de skal få sine mål oppfylt.

Dessverre blir denne boken for lang og rotete. Metoden som beskrives er tilsynelatende god, men jeg ble etterhvert ganske lei av å høre om hvor fantastisk den er. I det hele tatt var boken preget at mye selvtilfredshet. Den virket også litt gammelmodig i formen.

Jeg har hørt boken beskrevet som en ny variant av The Design of Everyday Things. Det er den absolutt ikke!

Kan kjøpes på play.com.

Amazon sier:
The recurring metaphor in The Inmates are Running the Asylum is that of the dancing bear--the circus bear that shuffles clumsily for the amusement of the audience. Such bears, says author Alan Cooper, don't dance well, as everyone at the circus can see. What amazes the crowd is that the bear dances at all. Cooper argues that technology (videocassette recorders, car alarms, most software applications for personal computers) consists largely of dancing bears--pieces that work, but not at all well. He goes on to say that this is more often than not the fault of poorly designed user interfaces, and he makes a good argument that way too many devices (perhaps as a result of the designers' subconscious wish to bully the people who tormented them as children) ask too much of their users. Too many systems (like the famous unprogrammable VCR) make their users feel stupid when they can't get the job done.

Cooper, who designed Visual Basic (the programming environment Microsoft promotes for the purpose of creating good user interfaces), indulges in too much name-dropping and self-congratulation (Cooper attributes the quote, "How did you do that?" to Microsoft chairman Bill Gates, upon looking at one of Cooper's creations)--but this appears to be de rigueur in books about the software industry. But those asides are minor. More valuable is the discourse about software design and implementation ("[O]bject orientation divides the 1000-brick tower into 10 100-brick towers."). Read this book for an idea of what's wrong with UI design. --David Wall

Terningkast 3

FAGBOK:"Extreme Programming Refactored: The Case Against XP" av Matt Stephens og Doug Rosenberg

XP er utrolig populært for tiden. Alle kule Javaprogrammerere har omfavnet det. Og det er jo ikke så rart - de kjedelige oppgavene som design og dokumentasjon erstattes av det vi liker best: koding. Og metoden skal sikre at kunden får systemet han ønsker og med høy kvalitet.

XP sine kjerneverdier er

• Kommunikasjon
• Enkelhet
• Feedback
• Mot

Hvis jeg skal våge meg på en kort beskrivelse av de viktigste punktene i XP er det:

• Ikke design i forkant. Designet kommer ut av koden.
• Utviklingen skal være testdrevet: testen skal skrives før selve koden.
• Det skal være en kunde tilstede som kan ta avgjørelser.
• Koden skal skrives om hele tiden (refactor mercilessly).
• Ikke lag mer enn det som du vet trengs.
  
• Teamet skal sitte sammen.
• Programmering skal gjøres i par. Og parene skal byttes om hele tiden.
• Koden skal eies kollektivt.
  
• Koden skal releases ofte. Det eneste som skal gjøres i en release er aktiviteter som gir kunden verdi.

I tillegg har XP en ekstremt høy kulhetsfaktor. Når man leser om XP, spesielt på nettet så får man nesten inntrykk av at det er Zen-mestere som snakker.

Også kommer det altså en bok som river alt dette flotte ned. De går systematisk gjennom XP og det som skrives om det og trekker frem problemer. Og de forslår endringer og tilpasninger som kan bøte på noen av problemene.

Noen av hovedpunktene deres er:

• Man trenger endel design før man begynner å kode. Man trenger ihvertfall en domenemodell.
• Man trenger også å lage noen rammeverk. Man kan ikke refactore ting som for eksempel skalering og flerbrukerhåndtering inn i kode. Det tar ihvertfall mye lenger tid enn dersom man har laget et rammeverk på forhånd.
• Noen ganger må man lage mere enn akkurat det som trengs nå. Dermed må man bruke tid på ting som ikke gir direkte verdi for kunden i neste release.
  
• All koding egner seg ikke til parprogrammering. Folk er forskjellige og alle passer ikke til å jobbe så tett med alle. Noen jobber faktisk best alene.
• Databaser er ikke lette å refactore.
• Man trenger en mere formalisert måte å håndtere krav enn storycards. Det er ikke lett å ta det alvorlig når det blir sagt at dersom et kort blir borte uten at kunden merker det så var ikke det kravet så viktig likevel.
  
• Når kunden faktisk har tatt en versjon av systemet i bruk så mister man mye frihet til endringer. Og man bruker mye tid på å ta kundens data videre til neste release og til å hjelpe kunden med å komme rundt feil.
• Mange av XP sine fordeler forsvinner når prosjektet blir stort. Det er ikke lett å la et team på 100 personer sitte sammen. Og kollektivt eierskap til en virkelig stor kodebase er urealistisk. Og vil du da at alle skal ha mot til å refactore alt?
  
• C3-prosjektet som ofte trekkes frem som er et av de store prosjektene hvor XP ble utviklet, ble faktisk stoppet fordi de ikke nådde målene. Slemt å si men sant.

Boken er ganske godt skrevet, men den har mye som irriterer. Frem for alt at de hele tiden skal være morsomme. Spesielt alle sangtekstene som boken er full av virker unødvendige og plagsomme. Samme med de ironiske små historiene. (Unntaket her er historien om The XP Society's Annual Picnic. Særdeles morsom!)
Man kan vel også si at sitater fra bøker og wikier som er løsrevet fra sammenhengen er en litt usportslig måte å argumentere.....

Men uansett svakheter så er dette en bok som alle bør lese! Det er riktig og viktig å sette spørsmål ved populære sannheter.

Synes du denne bokanmeldelsen kunne vært lengre og bedre? Da kan jeg anbefale denne på Slashdot.

Og jeg fant nettopp The XP Society's Annual Picnic på nettet!

Kan kjøpes på play.com.

Amazon sier:
Extreme Programming Refactored: The Case Against XP is meant to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a distinction between true "agility" in a software process and "fragility" inherent in techniques such as oral documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The goals and the good advice draw people in; the bad advice can potentially cause projects to fail. The XPers' theory is that when applied together, this mixture of rules will somehow magically be safe. XP therefore represents a high-risk process, wrapped in a "feel-good" methodology. The marketing, hype, and earnest self-assurance of its authors will convince many project leaders to try out XP on their next project. In Extreme Programming Refactored: The Case Against XP into a more viable process, Rosenberg and Stephens are not attempting to define a new methodology, as there are plenty of those in the World already. Instead, they will be examining XP in the context of existing methodologies and processes such as RUP, ICONIX, Spiral, RAD, DSDM, etc - and showing how XP goals can be achieved using these existing processes (with a slight emphasis on RUP and ICONIX), using software wisdom that has been tried and proven to work again and again.

Terningkast 5

FAGBOK:"The Photoshop CS Book for Digital Photographers" av Scott Kellby

Det finnes mengder av bøker om Adobe Photoshop. Bøker som går i detalj gjennom hver kommando, hver opsjon og hver bitte lille detalj. Livet mitt er for kort til å lese slike bøker.

Denne boken er heldigvis anderledes. Istedet for å fortelle alle detaljer om alt så forteller den hvordan forskjellige konkrete oppgaver kan løses. For eksempel hvordan du skal lysne deler av et bilde. Eller hvordan du kan klippe ut en person fra et bilde. Og hvem har ikke ønsket seg å lære om "De-Emphasizing Nostrils"? Oppskriftene er lette å følge og naturligvis lærer man masse om Photoshop ved å gå gjennom dem. Nå vet jeg for eksempel hva som skjuler seg bak det mystiske begrepet historiebørste....

Jeg hadde flaks med denne boken. Jeg fikk den nemlig av en kompis som har oppgradert sin Photoshop til CS2. Og da måtte han naturligvis kjøpe neste utgave av boken. Og jeg arvet altså boken hans med masse gule markeringer av hva som han synes er de viktigste teknikkene. Så det var lett for meg å begynne å lese.....


Kan kjøpes på play.com

Htmlcenter.com sier:
The first two chapters of the book deal with file browser essentials. I learned a lot from this section about how to use the file browser. Probably the coolest thing I learned was how to create digital contact sheets for my digital photo cds. These sheets allow you to print a contact sheet showing what is on the cd. No more will you have to load 10 CD's to find the picture of Aunt Ida.


The next three chapters deal with basic photo elements, namely cropping, resizing, image problems and color correction. Scott demonstrates how to take small photos and make poster-sized prints out of them. Ok, here is my favorite trick from the book, fixing underexposed pictures. Scott shows a before picture where you can barely tell what is in the picture. After applying his techniques, you can clearly tell what is in the picture and no one is the wiser. The "Color Me Badd" section first explains why the default color space is no longer the proper one to select and why changing this before making any color edits is critical.


Chapters 6, 7, and 8 handle techniques for masking photos, retouching portraits, and sculpting. I personally like the tip on how to extract people from their background. This tip allowed me to "change" the background of an image I was in. How many of you have taken pictures with the family only to look at them and realize you have dark circles under your eyes? Scott explains how to remove the dark circles and any other hangover attributes. Here is one tip for all the women (ok and men), removing love handles. Take out excess bulge digitally. I tested this out, but sadly the digital removal does not automatically lead to real-life removal.

Terningkast 4

FAGBOK:"Waltzing with Bears - Managing Risk on Software Projects" av Tom DeMarco & Timothy Lister

Mange IT-prosjekter er forsinket. Når leveransedagen kommer så er dessverre ofte prosjektet ikke helt ferdig til å leveres.

Forfatterne av denne boken hevder at grunnen til dette er at man lager estimater som bare vil holde dersom alt går uten problemer. Ingen slutter eller blir syke; kravspesifikasjonen er krystallklar; det dukker ikke et eneste teknisk problem... Selv om sjansen for at ett bestemt slikt problem skal dukke opp kanskje ikke er så veldig stor, så er sjansen for at minst ett av dem skal dukke opp ganske stor. Og ett problem er nok til at prosjektet ikke når sin optimistiske deadline. Og skylden for at prosjektet blir forsinket legges på de som har jobbet for å nå det optimistiske målet.

Risikohåndtering kan deles opp i aktiviteter:

• Identifisering av risiki som kan dukke opp i prosjektet.
  
• Sannsynlighet og konsekvens av hver risiko. Hvor sannsynlig er det at den dukker opp og hvilke konsekvenser vil den i så fall ha?
• Planlegging av tiltak. Hva skal man gjøre dersom en gitt risiko faktisk skjer?
• Tiltak i forkant som kan redusere problemene dersom en gitt risiko skjer. Man kan for eksempel starte prosjektet med litt større bemanning enn nødvendig for at risikoen for at noen slutter ikke skal ha så store konsekvenser.
• Overvåkning av risiki. Man må naturligvis overvåke prosessen for å kunne oppdage en risiko som materialiserer seg.

Boken viser hvordan man kan benytte identifiserte risiki med sannsynlighet og beregnet konsekvens til å beregne en kurve for ferdigstilling av prosjektet. Den angir sannsynlighet for at prosjektet avsluttes på en gitt dato. Første dato på kurven er det de kaller "nano-percent date"(N) - det vil si den dato man har estimert dersom ingen "uforutsette" problemer dukker opp. Ved å se på kurven kan man så angi en sannsynlighet for at prosjektet ferdigstilles i et intervall som starter med N.

Man kan laste ned et regneark (RISKOLOGY) som beregner slike kurver ved hjelp av Monte Carlo-metoden. Regnearket inneholder data for fem risiki som de mener gjelder alle IT-prosjekter. Det er ganske lett å endre disse så de passer til et firmas erfaringstall. Det er også mulig å legge inn egne risiki som blir med i beregningen. Det er morsomt å eksperimentere med dette og se på kurvene for prosjekter som man har jobbet i...

Dette er en bok som alle i IT-bransjen bør lese! Det gir verktøy for å kunne gi mye mere troverdige og riktige estimater for ferdigstilling av prosjekter.
Et annet viktig poeng er at riktig utført risikohåndtering flytter ansvaret for et vellykket prosjekt vekk fra bare prosjektleder og prosjektdeltagere. Ved å kvantifisere risiki i et prosjekt så må ledelse og kunde være med på å ta stilling til hvor stort tidsintervall man kan akseptere for dato for ferdigstillelse av prosjektet. Dersom de krever at prosjektet er ferdig på N så må de også ta ansvaret for at sannsynligheten for å lykkes er liten.

Boken er godt skrevet og ganske lettlest. Forfatterne har en lett ironisk tone når de snakker om vanlige holdninger i IT-bransjen. For eksempel: ".... You're not required to feel particularly happy about this. It's just the way things are. Pretending otherwise won't help."

Kan kjøpes på play.com.

Terningkast 5.

FAGBOK:"Pragmatic Unit Testing In Java with JUnit" av Andrew Hunt og David Thomas

Enhetstesting er et viktig verktøy for (Java)programmereren. Denne boken er en grei gjennomgang av enhetstesting og hvorfor det er en god ting.
Den viser hvordan man legger opp tester, hvilke basistester som finnes og hva som bør testes. Den viser hvordan tester bør organiseres og grupperes.

Boken gir en grundig gjennomgang av testrammeverket JUnit som jo er de facto standard for enhetstesting.

Et problem ved enhetstesting er jo å få avgrenset den delen av systemet som skal testes. Til det brukes mocking. Boken beskriver hvordan man kan lage en god mock og hvordan den kan tas inn i systemet som testes. Nøkkelordet er her naturligvis programmering mot interfacer.

Easy-Mock beskrives og boken viser hvordan det kan brukes til å "spille inn" ønskede responser som siden kan "avspilles" i en test.

Denne boken er en del av The Pracmatic Starter Kit. Det skal gi kunnskapene og teknikkene som skal til for å bli en Pragmatic Programmer. Jeg likte den godt. Den ga en god oppsummering og organisering av teknikker som man ofte bruker uten å ha gått skikkelig i dybden. Jeg har nok selv hatt en tendens til å dele enhetstester i to grupper:
1) Så triviell at det er sløsing av tid å skrive den.
2) Så kompleks at det er umulig å lage den.
Jeg håper at boken har gjort meg litt klokere.

Kan kjøpes på amazon.

Amazon sier:
Learn how to improve your Java coding skills using unit testing. Despite it's name, unit testing is really a coding technique, not a testing technique. Unit testing is done by programmers, for programmers. It's primarily for our benefit: we get improved confidence in our code, better ability to make deadlines, less time spent in the debugger, and less time beating on the code to make it work correctly. This book shows how to write tests, but more importantly, it goes where other books fear to tread and gives you concrete advice and examples of what to test--the common things that go wrong in all of our programs. Discover the tricky hiding places where bugs breed, and how to catch them using the freely available JUnit framework. It's easy to learn how to think of all the things in your code that are likely to break. We'll show you how with helpful mnemonics, summarized in a handy tip sheet (also available from our www.pragmaticprogrammer.com website) to help you remember all this stuff. With this book you will:

• Write better code, and take less time to write it
• Discover the tricky places where bugs breed
• Learn how to think of all the things that could go wrong
• Test individual pieces of code without having to include the whole project
• Test effectively with the whole team

We'll also cover how to use Mock Objects for testing, how to write high quality test code, and how to use unit testing to improve your design skills. We'll show you frequent "gotchas"--along with the fixes--to save you time when problems come up. We'll show you how with helpful mnemonics, summarized in a handy tip sheet (also available from our www.pragmaticprogrammer.com website). But the best part is that you don't need a sweeping mandate to change your whole team or your whole company. You don't need to adopt Extreme Programming or Test-Driven Development, or change your development process in order to reap the proven benefits of unit testing. You can start unit testing, the pragmatic way, right away.

Terningkast 4

FAGBOK: "Ajax in Action" av Dave Crane, Eric Pascarello med Darren James

Javascript har lenge vært lite stuerent i bransjen. Det har lett ført til kaotisk og uoversiktelig kode på klientsiden. Og innført avhengigheter til bestemte browsere og bestemte versjoner av dem.

Men så har Google begynt å lage ekstremt spennende og reaktive web-applikasjoner som er basert på Javascript. Og en teknologi som brukes av Google er jo per definisjon kul!

Så nå snakker alle om Ajax/Javascript. Mens vanlige web-applikasjoner typisk bytter ut hele siden når brukeren skal ha en respons, så erstatter en Ajax-applikasjon bare deler av en side. Dermed kan man bygge svært dynamiske applikasjoner uten masse blaffring og venting på at webserveren serverer en helt ny side.

Ajax er en kombinasjon av teknologier som allerede er kjent: Javascript, Cascading Style Sheets og asynkrone serverkall. Sentralt er også Document Object Model som beskriver den logiske strukturen på en webside. Den siste viktige komponenten er bibioteker og rammeverk som skjuler forskjeller mellom forskjellige browsere.

Denne boken er en del av In Action-serien til forlaget Manning. Som andre bøker i serien så er dette en svært god bok. Forfatterne skriver godt og klart og beskriver teknologiene på en forståelig måte. De legger mye arbeid i å forklare hvordan refactoring kan lage god kode av selv kaotisk Javascript.

Kan kjøpes på play.com


Terningkast 4

FAGBOK:"Essential CVS" av Jennifer Vesperman

CVS er anderledes enn andre systemer for kildekodekontroll (som jeg kjenner). Istedet for å låse filer som man skal endre, så lar CVS alle endre som de vil. Når man er ferdig med en serie med endringer så håndterer CVS eventuelle problemer. Dersom flere har endret samme fil så prøver CVS å slå endringene sammen. Dersom de ikke er i konflikt med hverandre så går det stort sett bra. Hvis konflikter oppstår så legger CVS forholdene til rette for at man kan skal kunne løse dem manuelt..

CVS er åpen kildekode. Det bruker RCS for å versjonere de enkelte filene. Det håndterer egentlig bare tekstfiler. Bilnærfiler må håndteres spesielt og har begrenset støtte.

CVS oppbevarer de RCS-versjonerte filene i et repository. Den enkelte bruker henter ut filene til sitt eget område i det som kalles en sandbox. Der kan de redigeres fritt inntil man sjekker dem inn igjen og lager nye versjoner i repository.

Da jeg begynte i et prosjekt som brukte CVS så syntes jeg det var vanskelig å få god oversikt over den overordnede filosofien i CVS. Så da var det bare å kjøpe en bok. Boken er en klassisk O'Reilly -bok med små tegnede dyr på omslaget. (Jeg tror det er sånne små Snipp- og Snapp-ekorn.) Den er godt skrevet og går dypt i detaljer. For eksempel advares det mot noen kommandoer på grunn av kommentarer i kildekoden som kan type på at det planlegges endringer.

Kan kjøpes fra play.com.

Amazon sier:
CVS, the Concurrent Versions System, is the popular source-code management tool that frees developers from the chaos that too often ensues when multiple users work on the same file. An open source technology that is available on most computer platforms, including Windows® and Mac OS® X, CVS is widely used to manage program code, web site content, and to track changes made to system configuration files. Multiple users can check out files from a directory tree, make changes, and then commit those changes back into the directory. If two developers modify the same file, CVS enables both sets of changes to be merged together into one final file. Although CVS is a lifesaver in many development scenarios, it suffers from poor documentation. But with Essential CVS, developers can have it all: the order that CVS brings and the comprehensive documentation developers need. Essential CVS is a complete and easy-to-follow reference that helps programmers and system administrators apply order to the task of managing large quantities of documents. The book covers basic concepts and usage of CVS, and features a comprehensive reference for CVS commands--including a handy Command Reference Card for quick, on-the-job checks. The book also includes advanced information on all aspects of CVS that involve automation, logging, branching and merging, and "watches." Readers will find in-depth coverage of the following:

• Installing CVS and building your first repository
• Basic use of CVS, including importing projects, checking out projects, committing changes, and updating projects
• Tagging, branching and merging
• Working with multiple users
• Clients, operating systems, and IDEs
• Repository management and managing remote repositories
• Project administration, including bug tracking systems, enforcing log messages, history and annotation, and more.
• Troubleshooting

Version control is essential to maintaining order in any project, large or small. Any CVS user, from beginners to team leaders and system administrators, will find this practical guide to CVS indispensable in getting the most from this valuable tool.

Terningkast 5

FAGBOK: Ti på topp

Jeg startet denne bloggen for å ha et sted å skrive om bøker jeg har lest. Spesielt fagbøker. Problemet er jo at ganske raskt forsvinner eldre bokanmeldelser ned i arkivene. Og der er de ikke så lette å finne.

Så derfor kommer nå min "Ti på topp"-liste. De ti beste fagbøkene jeg har blogget om.

Listen er sortert på opprinnelig terningkast.

1. "Domain-Driven Design - Tackling Complexity in the Heart of Software" av Eric Evans.
   
2. "The Design of Everyday Things" av Donald A. Norman
   
3. "On Intelligence" av Jeff Hawkins
   
4. "Programming Ruby" av Dave Thomas
5. "The Best Software Writing 1" samlet av Joel Spolsky
6. "The Mythical Man-Month" av Frederick P. Brooks,jr.
7. "The Psychology of Judgement and Decision Making" av Scott Plous
8. "Fit for Developing Software - Framework for Integrated Tests" av Rick Mugridge og Ward Cunningham
9. "Agile Software Development with Scrum" av Ken Schwaber og Mike Beedle
10. "JAVA 1.5 Tiger. A Developer's Notebook" av Brett McLaughlin og David Flanagan
    
    

FAGBOK: "Domain-Driven Design - Tackling Complexity in the Heart of Software" av Eric Evans

Jeg hørte Eric Evans sitt foredrag om domain-driven design på Javazone i fjor.
To ting var åpenbare:

• Eric Evans er en tørr og ganske kjedelig foredragsholder
• Hans tema er fantastisk! Endelig en som forstår viktigheten av modellering i en verden av alle mulige smidige(agile) metoder. For en mann som er vokst opp med datamodellering så var dette nok til nesten å få tårer i øynene!

Jeg kjøpte boken samme dag og oppdaget raskt at Eric Evans er en mye mere engasjerende forfatter enn foredragsholder.
Boken er lang og detaljert og beskriver en rekke strategier for modellering i prosjekter. Alt for mye til å beskrive i en kort omtale som dette.

Skal jeg trekke frem et kjernepunkt så må det være "The Ubiquitous Language". Altså at man i modelleringen finner et sett av kjernebegreper fra forretningsområdet som skal brukes i alle deler av prosjektet. Dette gjør at modellene blir gode verktøy i kommunikasjonen med brukere som kjenner forretningsområdet. I boken beskriver han flere diskusjoner med brukere hvor de forfiner the ubiquitous language og avslører misforståelser mellom analyse og det virkelige forretningsområdet.

Kan kjøpes på amazon.

Amazon sier:
The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process.

Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.

Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis--refactoring not just the code but the model underlying the code--in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.Specific topics covered include:

• Getting all team members to speak the same language
• Connecting model and implementation more deeply
• Sharpening key distinctions in a model
• Managing the lifecycle of a domain object
• Writing domain code that is safe to combine in elaborate ways
• Making complex code obvious and predictable
• Formulating a domain vision statement
• Distilling the core of a complex domain
• Digging out implicit concepts needed in the model
• Applying analysis patterns
• Relating design patterns to the model
• Maintaining model integrity in a large system
• Dealing with coexisting models on the same project
• Organizing systems with large-scale structures
• Recognizing and responding to modeling breakthroughs

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

Terningkast 6

FAGBOK: "Fit for Developing Software - Framework for Integrated Tests" av Rick Mugridge og Ward Cunningham

Fit er et rammeverk for å kjøre tester mot tabeller som inneholder testdata og forventede resultater. Data velikeholdes i HTML- eller Excel-tabeller. Rammeverket bygger sammen tabellene og de deler av systemet som skal testes. Resultatet av en Fit-kjøring presenteres i tilsvarende tabeller med avvik fra forventede resultater markert.
Det er enkelt for en bruker/tester å legge til og endre testdata.

Boken er greit skrevet og beskriver rammeverket på en lettforståelig måte. Den beskriver Fit for både programmerer og ikke-programmerer. Lest av en programmerer så blir den en smule lang....

Kan kjøpes på amazon.

Amazon sier:
Fitness, agility, and balance apply as much to software development as they do to athletic activities. We can admire the movements of a highly skilled dancer, skier, or athlete. Gracefulness comes from wasting no energy on unnecessary tension or balance recovery, so that effort can be focused exactly where it is needed, exactly when it is needed. The expert is continuously making small adjustments to stay aligned and in balance. Agile responses to unexpected changes distinguish the expert from the nonexpert, as their rebalancing adjustments are fluid and subtle and go unnoticed by nonexperts. Injury, pain, distractions, and poor concentration can wreck balance, reducing the expert's ability to respond well in a focused way. Much more effort is required to perform even at a substandard level. A high degree of fitness and practice is needed in order to build the required concentration, balance, agility, and focused power. This, inevitably, is a process of refinement over time, with attention given to more subtle aspects of risk assessment and response as expertise increases. The achievements of athletes have continued to improve over time, sometimes through changes that break assumptions about the activity or how best to train. Big changes are often met with skepticism but will slowly become accepted as the norm as they prove their worth. When we look at the efforts of most software developers, we see a lot of energy being wasted. In the rush to get software completed, there is often little time to reflect on how to improve the way we do things, how to get that special fitness, balance, and agility that allow us to be graceful in our intellectual efforts in order to achieve inspired results with less effort. We get unbalanced when we have to fix old bugs, losing flow. We often have to speculate about what's needed, and feedback is too slow. Our software becomes less than elegant and is difficult to change, with tensions and stresses building up in us and in our software. This book is intended to help improve your fitness and agility in two areas of software development where we can make huge improvements to current practice. First, improving communication between the people who need the software and the people who develop it, as well as show you how to express the business rules that are at the heart of a software solution. Second, how to use automated testing to provide immediate and effective feedback so we can maintain balance and agility and avoid "injury." The book also questions some common assumptions about the way in which software is developed. But we don't expect that you'll make a big leap of faith: We start with current practice and show how you make small yet effective improvements. Just like the dancer and the athlete, you will have to do more than simply read about how to do this. It is also necessary to practice.

Terningkast 4

FAGBOK: "Agile Software Development with Scrum" av Ken Schwaber og Mike Beedle

En grei innføring i Scrum som altså er en smidig utviklingsmodell for software. Forfatterne virker nesten religiøst overbevist om at Scrum kan løse alle problemer i databransjen. De beskriver metoden ned til minste detalj. Etterhvert synes jeg at det blir litt mye gjentagelser og unødvendig utmaling av detaljer. Så jeg må innrømme at jeg hoppet over siste del av boken. Føler likevel at jeg har fått et godt bilde av metoden.

Kan kjøpes på amazon.

Amazon sier:
This book was written for several audiences. Our first audience is application development managers that need to deliver software to production in short development cycles while mitigating the inherent risks of software development. Our second audience is the software development community at large. To them, this book sends a profound message: Scrum represents a new, more accurate way of doing software development that Is based on the assumption that software is a new product every time that it is written or composed. Once this assumption is understood and accepted, it is easy to arrive at the conclusion that software requires a great deal of research and creativity, and the therefore it is better served by a new set of practices that generate a self-organizing structure while simultaneously reducing risk and uncertainty. Finally, we have also written this book for a general audience that includes everyone involved in a project where there is constant change and unpredictable events. For this audience Scrum provides a general-purpose project management system that delivers, while it thrives on change and adapts to unpredictable events. Software as "new product" as presented in this book, is radically different from software as "manufactured product", the standard model made for software development throughout the last 20 years. Manufacture-like software methods assume that predictability comes from defined and repeatable processes, organizations, and development roles; while Scrum assumes the process, the organization, and the development roles are emergent but statistically predictable, and that they arise from applying simple practices, patterns and rules. Scrum is in fact much more predictable and effective than manufacturing-like processes, because when the Scrum practices, patterns and rules are applied diligently, the outcome is always; 1) higher productivity, 2) higher adaptability, 3) less risk and uncertainty, and 4) greater human comfort. The case studies we provide in this book will show that Scrum doesn't provide marginal productivity gains like process improvements that yield 5-25% efficiencies. When we say Scrum provides higher productivity, we often mean several orders of magnitude higher i.e. several 100 percents higher. When we say higher adaptability, we mean coping with radical change. In some case studies, we present cases where software projects morphed from simple applications in a single domain to complex applications across multiple domains: Scrum still managed while providing greater human comfort to everyone involved. Finally, we show through case studies that Scrum reduces risk and uncertainty by making everything visible early and often to all the people involved and by allowing adjustments to be made as early as possible. Throughout this book we provide 3 basic things: 1) an understanding of why this new thinking of software as new product development is necessary, 2) a thorough description of the Scrum practices that match this new way of thinking with plenty of examples, and 3) a large amount of end-to-end case studies that show how a wide range of people and projects have been successful using Scrum for the last 6 years. This last point is our most compelling argument: The success of Scrum is overwhelming. Scrum has produced by now billions of dollars in operating software in domains as varied as finance, trading, banking, telecommunications, benefits management, healthcare, insurance, e-commerce, manufacturing and even scientific environments. It is our hope that you, the reader of this book, will also enjoy the benefits of Scrum, whether as a development staff member wishing to work in a more predictable, more comforting, and higher producing environment, or as a manager desiring to finally bring certainty to software development in your organization. -- Mike Beedle, Chicago Ken Schwaber, Boston


Terningkast 4