Most recent comments
2021 in Books -- a Miscellany
Are, 2 years, 11 months
Moldejazz 2018
Camilla, 5 years, 4 months
Romjulen 2018
Camilla, 5 years, 11 months
Liveblogg nyttårsaften 2017
Tor, 6 years, 11 months
Selvbygger
Camilla, 1 month, 4 weeks
Bekjempelse av skadedyr II
Camilla, 11 months
Kort hår
Tor, 3 years, 11 months
Ravelry
Camilla, 3 years, 6 months
Melody Gardot
Camilla, 5 years, 5 months
Den årlige påske-kommentaren
Tor, 5 years, 8 months
50 book challenge
Camilla, 11 months, 3 weeks
Controls
Register
Archive
+ 2004
+ 2005
+ 2006
+ 2007
+ 2008
+ 2009
+ 2010
+ 2011
+ 2012
+ 2013
+ 2014
+ 2015
+ 2016
+ 2017
+ 2018
+ 2019
+ 2020
+ 2021
+ 2022
+ 2023
+ 2024

Nøkkelord

Jeg har tenkt litt på dette med nøkkelord (bedre kjent som tags, men jeg føler meg i bruke-norske-ord-humør i dag) i det siste. Jeg tror nemlig vi kan gjøre denne nye og spennende funksjonaliteten enda mer ny, og, ikke minst, enda mer spennende. Slik det funker i dag har vi en side som viser alle nøkkelordene med skriftstørrelse som avhenger av hvor mange artikler som har med hvert nøkkelord. Størrelsen varierer lineært fra 50% av vanlig størrelse til 400%, det vil altså si at det mest brukte nøkkelordet vil ha 8 ganger større skrift enn det minst brukte, uansett om det er med i 2 eller 100 artikler.

Slik jeg ser det har dette systemet to ulemper. For det første, størrelsen på hvert nøkkelord er avhengig ikke bare av hvor mange artikler som nevner det aktuelle nøkkelordet, men også hvor mange artikler som nevner det mest brukte nøkkelordet. Det gjør at siden laster litt tregt, og av tekniske årsaker gjør det dessuten at det er et aldri så lite helvete å lage for eksempel alfabetisk sortering.

En alternativ måte å håndtere dette på er å si at størrelsen skal være bestemt av antallet artikler et gitt nøkkelord har, uavhengig av hvor mange det mest brukte nøkkeordet har. Det kan da enten gjøres ved at man sier at skriftstørrelsen skal være for eksempel 50% ganger antall artikler. Akkurat det er naturligvis en massivt dårlig idé, siden de største nøkkelordene da i prinsippet kan bli undelig store. Eventuelt si at størrelsen skal være proporsjonal med logaritmen til antall artikler, eller noe slikt, siden man da med passende valg av konstanter kan lage et system som funker estetisk, og som vil holde seg innen rimelighetens grenser i overskuelig fremtid.

Et tredje alternativ er å gruppere nøkkelordene etter antall artikler, og si at for eksempel nøkkelord med mellom en og fem artikler har størrelse 50%, fem til ti har 100%, ogsåvidere, og så til slutt nøkkelord med mer enn for eksempel 30 artikler er i størrelse 400%.

Et annet problem, som er knyttet til, men ikke nødvendigvis henger direkte sammen med, skriftstørrelsene, er at vi har 1738 nøkkelord som er brukt på 1 eller 2 artikler, og som dominerer nøkkelordskyen ganske hardt. Her så jeg for meg å lage en slags funksjon som gjør at man kan velge å bare vise de nøkkelordene som har for eksempel 3 eller flere artikler, men jeg er litt usikker på hvordan dette grenesnittet bør se ut.

Det som også er litt funky, som jeg har sett de har mange steder, er at man viser nøkkelordene til hver artikkel som en liten mini-sky. Det funker naturligvis best hvis hver artikkel har en del nøkkelord, kanskje 8-12 eller noe slikt, men jeg synes som sagt det ser ganske funky ut.

Grunnen til at jeg skriver om dette er naturligvis at jeg gjerne vi vite om noen andre har tanker og meninger før jeg begynner å fikse på ting, så innspill og forslag tas imot med takk.

-Tor Nordam

Comments

Camilla,  03.10.10 21:03

Jeg har ingen formening om hva som er den beste måten å organisere alt dette på, rent bortsett fra at jeg gjerne vil ha det alfabetisk. Jeg liker måten Flickr hånderer dem på, men jeg vet ikke hvordan det fungerer. Jeg liker også veldig godt idéen med mini-skyer. Og det at ikke alle nøkkelord trenger å vises i hovedskyen. Men da bør vi ha en liten link som sier "vis alle nøkkelord" eller noe slikt.
Anders G.,  04.10.10 08:17

Hvis det er den trege lastinga som er hovedproblemet kan det jo alltids løses på en annen måte enn dagens. Regner med det er en ren group-by på nøkkelordet nå, og en count? Trikset her er jo da å ha en eller annen form for mellomlagring av dette - enten ved at skyen genereres f.eks. en gang i timen med en timer, eller at det skjer for den første sidelastingen som gjøres hver time.

Et tredje alternativ som nok er det beste, er at vi gjør denne mellomlagringen hver gang en ny artikkel lagres eller får endret en tag. Dagens logikk kan da lempe resultatet direkte ned i en mellom-lagringstabell, kanskje også med størrelsen på taggen ferdig, som du så bare rått tegner opp?

Første trinn du bør gjøre er forøvrig å lokalisere nøyaktig hva som tar tid: databasegrupperinga, lesing, opptegning i browser etc. Når jeg tester det nå syns jeg egentlig ikke det går spesielt tregt hos meg, jeg får (subjektivt) inntrykk av at det er nettleser-opptegninga som kanskje ser ut til å ta mest tid faktisk, og i så fall er nok mye løst ved å redusere antallet viste nøkkelord (som standard). Det gjør du forøvrig med en "having count(tag) > X"-klausul i spørringa, antakelig.

Jeg sier "ooh, vi kan spare halve kjøretiden på fft-rutinen ved å utnytte at resultatet alltid vil være anti-symmetrisk om null-frekvensen siden inputen alltid er reell", og han sier "det er sant, men irrelevant, siden den tar under et sekund mens programmet som helhet bruker en time", og så legger han gjerne til noe om viktigheten av å profilere programmet.

Og du har naturligvis rett.

Slik det gjøres i dag lagrer vi hvor mange artikler et nøkkelord er knyttet til. Når man legger til eller fjerner et nøkkelord blir dette tallet oppdatert i databasen for det aktuelle nøkkelordet. Så det som regnes ut når man laster siden er altså størrelsen av hvert nøkkelord i forhold til det største. Det er ikke primært at det tar så lang tid som irriterer meg, men heller at måten jeg gjør det på nå er å lage en dictionary som inneholder nøkkelordene og størrelsene, og det gjør at det er litt prakk å få til sortering.

Jeg merker at jo mer jeg tenker på det, jo mer heller jeg mot å bare si at størrelsen er noe slikt som 70*log(n+1). Det gir en skalering som føles riktigere, og det skal ganske mange artikler til før skriftstørrelsen blir plagsomt stor.
Tor,  11.11.10 23:19

Jeg har nå implementert det jeg sa i kommentaren over, som betyr at de relative størrelsene er litt forskjellige fra det de har vært, men jeg synes personlig nøkkelordskyen er mer interessant å se på nå.

Alfabetisk sortering er nå standard. Si gjerne fra om andre typer sortering man måtte ønske.

Merk også at jeg har laget en bug som gjør at nøkkelord som finnes på flere språk dukker opp flere ganger i nøkkelordskyen. Jeg skal fikse dette når jeg får tenkt meg litt om.
Camilla,  11.11.10 23:54

Jeg er litt overrasket over at "tullinger" faller inn under flere språk, kanskje. Men ellers liker jeg denne varianten mye bedre enn den forrige.