oriktig repetition av information i resultatet av sökning i databas. – Fans orsakas av ogenomtänkt konfiguration av databasen eller ogenomtänkt utformning av sökningen (frågan). – Begreppet fan (engelskt uttal) definierades först 1996 av Thomas M Connolly (länk) och Carolyn Begg (länk) i boken Database systems. Fan är en av två connection traps: den andra kallas för chasm. Felet definierades i förhållande till databaser av typen entity‑relationship, men det uppträder även i andra sammanhang. – Något förenklat exempel: ett företag har anställda och avdelningar. I en databas finns en tabell med företagets alla anställda och en annan tabell med företagets alla avdelningar. Om företaget gör en olyckligt formulerad sökning (med en join) efter anställda kan resultatet bli att varje anställd räknas som anställd i var och en av avdelningarna. Sökningen ”vet” inte att varje anställd tillhör bara en avdelning, eller vilken avdelning det i så fall skulle vara. I stället ”tror” sökningen att den som är anställd på företaget tillhör alla företagets avdelningar. Antalet anställda multipliceras därför i resultatet av sökningen; varje namn förekommer flera gånger. I mer komplicerade fall kan felet vara svårt att upptäcka: man ser bara att resultatet av sökningen inte kan stämma. – Man talar om en cartesisk produkt (cartesian product). Det innebär att i stället för att varje anställd knyts till en, och bara en, avdelning (som i en tabell med två spalter), vilket är det riktiga, så knyts varje anställd till var och en av avdelningarna (som i en flerspaltig tabell med de anställda på x‑axeln och avdelningarna på y‑axeln, eller omvänt, och ett kryss i varje ruta). – Uttrycket fan kommer av fan out, som kan översättas med sprida ut [i solfjäderform]. – För att undvika fans bör man lägga upp databasen (eller sökningen) på ett bättre sätt:
- – olämpligt: anställd–(av)–företag–(som har)–avdelningar;
- – hellre: företag–(har)–avdelningar–(som har)–anställda.
– Exakt hur man bör göra beror på syftet med databasen. (Observera att en del förklaringar på nätet av chasms i själva verket beskriver fans.)
[databaser] [fel] [ändrad 4 juli 2022]
Gregg Zachary – amerikansk journalist och författare. – Zachary har bland annat skrivit boken Showstopper (länk) om Windows NT† och boken Endless frontier (länk) om Vannevar Bush†. Han undervisar på Arizona state university. – Läs mer på hans webbsidor: länk.
[g pascal zachary] [personer] [ändrad 1 juni 2019]
- – ”Given enough eyeballs, all bugs are shallow”, vilket betyder att om tillräckligt många granskar programkoden kommer varje bugg att vara lätt att rätta till (åtminstone för någon av granskarna). – Yttrandet tillskrivs Linus Torvalds och citeras i Eric Raymonds bok Katedralen och basaren;
- – ”Allt som en människa gör motiveras med överlevnad, socialt liv eller nöje.” – I sitt förord till boken The hacker ethic and the spirit of the information age från 2001 (länk) formulerade Linus Torvalds den tesen, och han ansåg att det var stadier i en utveckling: resultatet blir bäst när man gör saker bara för att det är roligt.
[fel] [lagar] [systemutveckling] [ändrad 29 mars 2023]
(bazaar mode) – programutveckling över internet med många deltagare och full öppenhet under arbetets gång. Anses prägla utvecklingen av Linux. – Benämningen bazaar i denna betydelse kommer från Eric Raymonds bok The cathedral and the bazaar från 1999, svensk översättning Katedralen och basaren, 2001 (länk). – Eric Raymond ställde basaren mot katedralen som två kontrasterande sätt att arbeta. Även katedralen är en modell för utveckling med öppen källkod, men i cathedral mode sker utvecklingen av nya versioner i små, slutna grupper: öppenheten kommer först när en ny version av programmet har släppts. Basaren präglas däremot av öppenhet, nyfikenhet och utbyte av kunskap. – The cathedral and the bazaar i engelsk originaltext kan laddas ner här; svensk översättning finns här (borttagen).
[linux] [programmering] [öppen källkod] [ändrad 12 februari 2022]
slank systemutveckling – systemutveckling utan onödigt arbete, onödig kod och onödig byråkrati. Det är en utveckling av agil systemutveckling, och har inspirerats av lean production, ett industriellt produktionssätt som har utvecklats på Toyota. Principerna för slank systemutveckling har beskrivits av Mary Poppendieck och Tom Poppendieck i boken Lean software development, 2003. – Se begreppet lean. – Se också poppendieck.com.
[systemutveckling] [ändrad 7 april 2023]
domändriven design, förkortat DDD – principen att programutveckling ska vara nära knuten till det verksamhetsområde (domän, betydelse 2) som programmet ska användas i. Programmet ska på olika sätt återspegla den domän som det ska användas i, och experter inom området (domänen) ska känna igen sig. – Uttrycket domain-driven design myntades 2004 av Eric Evans i en bok med samma namn. – Se domainlanguage.com.
[programmering] [systemutveckling] [ändrad 14 september 2018]
en personlig informationshanterare (e‑postprogram, adressbok, kalender med mera), skriven i öppen källkod. I praktiken nerlagd sedan 2009. – Programmet utvecklades med början 2002 inom Open source applications foundation (av allt att döma också nerlagd), grundad av Mitch Kapor. Bland utvecklarna fanns Andy Hertzfeld. Version 1.0 blev klar 2008 efter många års arbete, och kunde då laddas ner från chandlerproject.org. – Chandler blev inte särskilt spritt, och arbetet har i praktiken legat nere sedan 2009, då de anställda sades upp. – Chandler fungerade i Windows, Linux och på Mac. En uppföljare, Chandler2, påbörjades 2009, även den nerlagd eller vilande. – Programmet var uppkallat efter författaren Raymond Chandler (1888—1959, se Wikipedia). – Utvecklingen av Chandler beskrevs i boken Dreaming in code från 2008, skriven av Scott Rosenberg, se dreamingincode.com (nere i oktober 2020 – arkiverad).
[nerlagt] [personliga data] [ändrad 1 oktober 2020]
”Nio kvinnor kan inte få ett barn på en månad.” – Även: ”Om man sätter in mer personal i ett försenat mjukvaruprojekt tar det ännu längre tid.” – På engelska: Brook’s law. – Lagen har namn efter Fred Brooks, författare till boken The Mythical Man‑Month (länk), som kom ut 1975. Han skrev där att arbetet som uträttas i ett projekt står i direkt proportion till antalet medarbetare, men projektets komplexitet ökar med kvadraten på antalet medarbetare. Alltså tar det längre tid ju fler som är med. – Fred Brooks (1931 – se länk) var anställd på IBM fram till 1965, och ledde där arbetet på operativsystemet till stordatorn System 360. 1965 blev han professor i datorvetenskap på universitetet i Chapel Hill, North Carolina (länk). – Brooks fick 1999 Turingpriset – se denna länk). – Läs också om Forresters lag.
[lagar] [projektarbete] [ändrad 13 januari 2020]