podcast_upplysning_2008.04.01_x264

[00:00:00] Speaker A: Timmarna två nästan. Välkommen. Tack så mycket. Jag hörde på radio på vägen hit att det var World Freeze Day idag. Mellan klockan sex och fem över sex ikväll så var det manifestationer. Folk i hela världen skulle stanna upp i världen. Men det var egentligen

[00:00:25] Speaker A: kanske de praktiserade det här.

[00:00:28] Speaker B: Nej.

[00:00:28] Speaker A: Vi ska se om det kommer någon Youtube-klipp.

[00:00:43] Speaker B: Ja.

[00:00:44] Speaker A: Hur många är det som har hört talas om Twingly innan? Allihop? Startade för två år sedan. Företaget Primelabs som var tänkt att bli en laboratorieverksamhet för diverse webbtjänster. Sen råkade

[00:01:10] Speaker A: det bli så att den första webbtjänsten blev Twingly som blev alldeles för framgångsrik för att det skulle rymmas några andra produkter i detsamma företag. Så vi har den här veckan bytt namn från Primelabs AB till Twingly. För att två varumärken i slutändan blir för grovt att underhålla. Och vi kommer istället

[00:01:36] Speaker A: att ha ett avtal med våra finansiärer som innebär att varumärket Primelabs stannar hos oss som är grundare. De är inte ägare till det här. Primelabs kanske kommer tillbaka en annan dag. Med ett nytt uppdrag. Men i alla fall. Jag tänkte först börja med att presentera mig själv lite grann. Jag är V94. Har gått

[00:02:01] Speaker A: ungefär fem år i de här lokalerna. Har fortfarande inte riktigt fått in Exeos-rapporten. Men det kanske kommer något år nu. Och jag tänkte höra efter hur många här som har liknande DR och CR. Och ni andra, vad är det? Ja,

[00:02:28] Speaker A: I såklart. Jag kommer veta det, men jag har tre på I. Och istället för att ta examen så började jag jobba på ett företag som heter Framfab. Här i Linköping, där det fanns. 1999. 2000 flyttade jag till Japan och jobbade där som webbutvecklare i ett år. När jag kom tillbaka så var framförallt borta. Och

[00:02:53] Speaker A: resten av webbvärlden också, kan man tycka. Jag fortsatte jobba som webbutvecklare i ett par år innan vi bröt ut utvecklingsavdelningen i det företaget jag jobbade i och startade ett konsultbolag. Som heter Polyester. Polyester hade vi fram tills för två år sedan i maj 2006 när vi sadlade om från att

[00:03:18] Speaker A: vara ett renodlat konsultbolag till att bli ett renodlat produktbolag. Den här övergången var inte så skarp som man kan tro för att konsultkunderna låg kvar ett bra tag och finansierade verksamheten i början. Vilket var väldigt bra. Så det är ungefär det som är bakgrunden. Vi var fyra personer när vi startade för två år sedan. Nu är vi nio personer. Vi

[00:03:45] Speaker A: tog in riskkapital från ett företag i Stockholm som heter Cervisen förra sommaren på 10 miljoner kronor. Det finns fortfarande en del kvar av de pengarna. Så vi lever på dem ungefär året ut. Vi började med att utveckla ett

[00:04:10] Speaker A: system för att indexera bloggar. När vi startade i maj 2006 hade vi ett projekt som vi hade jobbat med parallellt med konsultarbetet som gick ut på att bygga en blocket sajt utan några geografiska begränsningar. Vår tes var att vi såg att

[00:04:35] Speaker A: det var väldigt många svenska webbtjänster som lyckades genom att kopiera en amerikansk global tjänst och sedan lansera en lokal version. Som till exempel Tradera gjorde med Ebay. Men det fanns också svenska webbtjänster som var unika. Som till exempel Blocket och

[00:05:00] Speaker A: Lunar Storm och så vidare. Som hade poppat upp och var ganska mycket före sin tid i Sverige. Blocket har ju fått internationella motsvarigheter också i Craigslist. Lunar Storm var tidigt ute som socialt nätverk och har fått väldigt stora motsvarigheter globalt. Men då fanns ingen tendens till att någon av de svenska webbtjänsterna

[00:05:25] Speaker A: skulle multiplicera sig ut i världen. Och det såg vi som väldigt mycket slöseri med bra idéer och bra kunskap och teknik som finns här i Sverige. Så vi hade utvecklat en Blockit-site nästan klar. Och när

[00:05:54] Speaker A: då under våren 2006 så började det pratas mer och mer om bloggar, inte bara i Sverige utan även utomlands. Bloggfenomenet exploderade i USA 2004. Såg de ungefär samma utveckling som vi såg under 2007 här i Sverige. När bloggar började dyka upp i massmedia och så vidare. Och det hade väldigt mycket att göra med Det var kopplat till valet 2004.

[00:06:21] Speaker A: På samma sätt som med valet 2006 här i Sverige så fanns det väldigt mycket bloggare som skapade nyheter som sen dök upp i massmedia. Vilket på något sätt i flera länder har varit ett nyckelevent som har gjort att massmedia har upptäckt att bloggvärlden faktiskt är ett levande och viktigt verktyg

[00:06:46] Speaker A: och en viktig del av media. Vi såg väldigt mycket tendenser och strömningar från USA och såg så stora möjligheter att vi tog ett jättesvårt beslut och helt enkelt la hela det stora projektet att bygga en blockhjulssajt som kunde stämplas ut i många länder. Lade på hyllan och

[00:07:11] Speaker A: började istället utveckla en ny lösning för att indexera bloggar över hela världen. Och då slängde vi inte hela den gamla kodbasen utan vi fick med oss väldigt mycket där av språkidentifiering och språkhantering och hela tanken att man ska bygga en webbtjänst så att det inte finns några geografiska begränsningar. Vi har hela tiden under

[00:07:36] Speaker A: de senaste två åren gjort ganska svåra val. Vi har begränsat oss i tekniken för att vi inte har velat gå in på spår som innebär att man tar på sig en begränsning i geografisk information till senare. Det vi nu har är en teknik som fungerar med alla språk och alla geografier och vi hämtar bloggar från hela världen och sätter dem i samma databas. Hade

[00:08:02] Speaker A: vi inte gjort det ända från början så hade vi stött på väldigt stora problem nu när vi tar det steget. Jag ska visa en kort presentation som är gjord för att jag ska springa igenom den på fem minuter. Och den ska jag hålla nere i Amsterdam på torsdag, nej fredag förresten. På en konferens där som heter The Next Web. Så den ni får nu förhandsinformation.

[00:08:29] Speaker A: Så ni får jättegärna hålla på den åtminstone till på torsdag morgon när vi själva har gått ut med den här informationen. Det vi gör nu är att vi lanserar en internationell bloggsökmotor som tar steget att utnyttja potentialen som vi har haft i vår indexering. Indexering

[00:08:54] Speaker A: plattformen från början. Vi har ändrat sedan sedan sommaren 06 indexerar bloggar från hela världen, men vi har inte gjort dem sökbara därför att det är på det hela taget en mycket, mycket större steg. Jag är mycket mer teknik och mycket större infrastruktur att göra en stor datum sökbar. I realtid

[00:09:20] Speaker A: än att bara samla på sig dessutom datamängder. Det är två helt olika problem som har sina utmaningar. Men insamlingen kräver mycket mindre i hårdvara och mjukvara och kunskap. Nu, två år senare, så har vi äntligen en söklösning klar som klarar av att göra Det här datat

[00:09:46] Speaker A: är sökbart och vi har nu en databas som innehåller ett års kvalitativ bloggdata. Det rör sig om 110 miljoner blogginlägg ungefär på en halv terabyte tillsammans. De är ihoplänkade på 170 miljoner sätt. Vi traskar igenom den här presentationen.

[00:10:20] Speaker A: Och BetaLars Today syftar alltså inte på idag utan på torsdag. Vår blogg sätts upp. Den som vi lanserar nu är i grunden en väldigt enkel minimalistisk sökbox.

[00:10:46] Speaker A: En sökruta av ett sökresultat och egentligen inte så väldigt mycket mer. Det vi kommer göra härefter är att utveckla applikationer ovanpå den här sökplattformen och det ska ju ta lite grann mot slutet av andra timmen att gissa vilken typ av applikationer som man skulle kunna använda data till. Vi

[00:11:13] Speaker A: har tidigare jobbat väldigt mycket med, på vägen hit för att finansiera utvecklingen, jobbat mycket med analys av bloggvärlden och jobbar med några olika företag för för mediebevakning som även bevakar bloggar genom att använda vårt data. Det

[00:11:38] Speaker A: här är en visualisering av 2000 stora svenska bloggar. Plus av gula bloggar, politikbloggar, medan lila handlar om populärkultur. De här två stora jättarna som man sett. Hovra där i bakgrunden är blondinbella och tjuvlyssna.se Medan

[00:12:04] Speaker A: den jättenördiga politikklustret är politikerbloggen.se Och den här kartan skulle ni kunna mejla ut för den är ganska rolig Jag har gjort en, förutom att det är en DNG som är själva bilden, så har jag gjort en helt gammal

[00:12:29] Speaker A: old school på Premen Image Map som jag har en klipp kvar också. Och Twingly utgör med den teknikplattformen som jag har tagit fram Nästa generation av bloggsök. Det finns ett antal bloggsökmotorer, framförallt

[00:12:54] Speaker A: från USA, som man kan tycka fungerar alldeles utmärkt. Det är Teknologi80, Sphere.com, Google, det finns en som heter IceRocket.com. Sen finns det lokala också. I Sverige har vi Knuff och Blogs.se som ska bli Bloggy.se. Det finns nästan i varje land i Europa eller hela världen lokala

[00:13:19] Speaker A: bloggsökmotorer. De globala internationella kommer från USA. Sen lanserar vi Twingly den här veckan. Bara snabbt vad som gör den i våra ögon till nästa generation. Dels att det erbjuder ett spännande sök. Jag kommer berätta lite hur vi åstadkommer det. Vi

[00:13:48] Speaker A: använder en princip som de befintliga sökontorerna inte kan använda sig av utan att göra ett stort antal användare förbannade. Så det är en fördel för oss som är nybörjare och kan vara små och naiva. Sen använder vi funktioner för socialt sök vilket innebär att användare kan hjälpa varandra att hitta bra

[00:14:13] Speaker A: bloggdata. Det vill säga att man kan rösta på bra innehåll och se till att det flyttas upp i sökrankningen. Det är någonting som inbjuder väldigt mycket till abuse. Därför att då kan man ju rösta på sina egna bloggar och man kan sätta upp en farm av fejkanvändare som och röstar på sin egen våg. Men det

[00:14:38] Speaker A: kommer vi motverka genom att använda precis samma algoritm som innan, för att rensa bort den kommer ju rensa bort användare som inte uppför sig. Och vi har ett kraftfullt sökspråk som vi ska titta lite grann på sen, som innehåller, dels innehåller det en del verb som inte finns

[00:15:03] Speaker A: i befintliga sökmotorer. Dels så innehåller det möjligheten att kombinera sökbilder på ett helt annat sätt. I vår sökmotor, precis som till exempel i Googles bloggsök, så kan man söka på, man kan skriva link:dn.se vilket innebär att man får upp alla blogginlägg som länkar till Dagens Nyheter. Man kan också skriva site:twingly.com

[00:15:33] Speaker A: vilket innebär att man får alla blogginlägg som ligger på den sajten. Däremot kan man inte kombinera den här filten i Google eller någon av de befintliga sökontoren vilket man kan i Twingly. Alla blogginlägg som länkar från en sajt till en annan. Och

[00:15:59] Speaker A: på samma sätt kan man kombinera alla filter på vilket sätt man vill. Man kan kombinera och få fram alla blogginlägg som är på svenska och en viss sajt som länkar till en annan. Det som vi framförallt

[00:16:24] Speaker A: i Sverige mest känner för är att vi har en produkt som innebär att tidningar kan länka tillbaka till bloggar som skriver om deras artiklar och länkar till de artiklarna. Det var någonting som vi började utveckla från början för att skapa kassaflöde och varumärkesigenkänning. Så det är egentligen en ganska enkel produkt som har utvecklats och nu innehåller

[00:16:51] Speaker A: kraftfull funktion för spammoderering. Dessutom har vi behövt lösa problemet att vid varje sidomladdning på nu 45 stora sajter över hela Europa som hämtar sin information från oss. Det gick in med att vi hanterar den kombinerade trafiken från Det är genom svenskan och IDG och politiken i Danmark och dagbordet i Norge.

[00:17:17] Speaker A: 3500 sajter också. Det har vi löst genom att helt enkelt inte hantera den själva. Det kan jag också berätta om hur vi gör. Senaste kunden i raden heter The Telegraph i Amsterdam. Som lanserade i måndags. Det har varit en väldigt hektisk vecka förutom att förbereda Lanseringen och konferensen nu i Amsterdam

[00:17:42] Speaker A: så är det tre kunder som har lanserat Twingly. Det är Publico, största tidningen i Portugal. Det är La Vanguardia som är inte den största men den mest progressiva dagstidningen i Spanien. Och sen så är det The Telegraph i Amsterdam. Jag vet

[00:18:07] Speaker A: inte om ni är insatt i vad Twingly gör här, men ni ser längst till höger här hur bloggar som har länkat till just den här artikeln får en länk tillbaka. För bloggarna innebär det att när man länkar till tidningen så får man väldigt mycket läsare som man annars inte skulle ha fått. För tidningen innebär det att man får väldigt mycket mer uppmärksamhet från bloggar för det man skriver. Och

[00:18:33] Speaker A: för bloggaren blir det naturligt om man redan skriver om ett ämne att man då väljer att länka till den tidningen där man vet att man får läsa det tillbaka. Sen finns det också saker att vara försiktig med för tidningen innebär att man kan få in väldigt mycket spam och missbruk. Nivån på det här har varit mycket lägre än alla trodde från början. Både tidningar och tidningar. Och

[00:18:59] Speaker A: bloggarna själva som trodde att andra bloggare var hemska och otäcka skulle skriva om köns. De var sönderkänsliga totalt. Men för bloggaren så innebär det att man måste vara. Man kan lätt börja skriva inlägg som man kanske annars skulle inte ha gjort. Man måste hålla lite vakt på sin egen integritet

[00:19:24] Speaker A: så att man inte dras med för lätt dit. Hjärtan på besökare utan fortsätter skriva kvalitativt så att man kan få dit. Hur funkar det för tidningarna? Blir det satt vissa av de bloggare som de inte vill ha? Ja. Godkänns allt automatiskt? Ja, allt godkänns automatiskt. Och det beror på, det är inte enbart tidningens välvilja utan det beror framförallt

[00:19:50] Speaker A: på ett mål mot Aftonbladet där de hade Det var en kommentar med brottsligt innehåll som de släppte igenom modereringen trots att de förhandsmoderade. Det gjorde att de blev ansvariga för det innehållet. Nu gör alla tidningar så istället att man först släpper ut innehållet och sen så modererar

[00:20:15] Speaker A: man i efterhand. Vilket innebär att de inte har det publicistiska ansvaret om de sedan agerar på det. Men vissa bloggar har väl saklistat från början? Ja, de har den möjligheten att göra det. Och sen finns den här möjligheten till användaranmälningar också. Att användarna kan anmäla innehåll som de tycker är olämpligt. Och då kan tidningens moderatorer få hjälp med att upptäcka det. Så

[00:20:40] Speaker A: de inte behöver alltid titta igenom allt innehåll som kommer in till tidningen. Men tidningar, i alla fall i Sverige och Skandinavien är väldigt, väldigt liberala med innehåll. De har ambitionen att släppa in allt innehåll som inte är direkt brottsligt att länka till för dem själva. Vi har varit förvånade över själva hur

[00:21:06] Speaker A: öppna de är för att släppa in den här typen av innehåll på sina egna sajter. Det har varit lite provocerande ibland för redaktionen att få få bloggare som ger samma utrymme som tidningens eget innehåll. Även om det bara är länkar ut. Är

[00:21:34] Speaker A: det någon mer fråga kring just den tidningstjänsten? Hur den fungerar? Vi har ju haft väldigt stort intresse i Sverige. Och vi ser nu samma intresse börja vakna ute i Europa.

[00:21:54] Speaker B: Vi började ut... Men det ligger ett automatiskt spannfilter emellan här ändå? Nej, det gör det inte.

[00:22:01] Speaker A: Jo, det finns vissa rudimentära spannfilter. Och vårt avtal med tidningarna innebär att Det säger att vi ska se till att inget mekaniskt spam kommer in. Sen är det deras uppgift att avgöra om det är något olämpligt innehåll som kommer in. Så vi ser till att hålla spammen borta. Det

[00:22:29] Speaker A: här är då tidningen vi jobbar med. Som jag sa så är vi uppe i 45 sajter nu i sju länder. Och det växer hela tiden och nu börjar vi se nya typer av sajter bli intresserade. Senast idag så har Centerpartiet börjat länka tillbaka till bloggar från sin partisida. Vilket innebär

[00:22:56] Speaker A: att de öppnar upp för den diskussionen och lyfter in den på sin sajt. Och vi brukar prata om att tvillinglig demokratisera media. Om då Centerpartiet börjar använda dem. Det var demokratisera demokratin där. Vad man ska säga då.

[00:23:20] Speaker B: Jag tänkte på det. Familjekostnaden för sidorna som används. Det är något alternativ för små sidor att använda dem utan mycket behov.

[00:23:29] Speaker A: Eller begär ni mycket pengar för det? Just nu har vi en ganska hög minsta nivå. Vi tar 3,9 i månaden för det. Det är upp till om man har 100 000 unika besökare i veckan. Däremot så med den nya sökmotorn så kommer det ges. Nu kommer vi ha ett API som ger precis samma möjligheter att länka tillbaka till bloggar. Vilken sajt som helst. Och

[00:23:55] Speaker A: där har vi inte bestämt än riktigt vad prismodellen kommer att vara, men då kommer det att vara en lägre prismodell. Sen är det, i tjänsten till tidningen så ingår det mycket mer än vad man bara ser på sajten. Dels är det att man får tillgång till spammodelleringen och teknisk support kring hela, ja, kring hela, både från installation och sen användandet

[00:24:21] Speaker A: under hela produktens livslängd. Och sen så får man också väldigt mycket hjälp vid lanseringen för att tidningarna är inte så väldigt vana att göra PR-arbete själva. Vissa tidningar jobbar väldigt mycket med PR, andra gör det inte alls. Så då, eftersom vi har erfarenhet av väldigt många lanseringar så hjälper vi tidningarna med det, vilket är ganska uppskattat. Det fyller verkligen ett behov hos dem. För att produkterna

[00:24:47] Speaker A: är ju sådana att det spelar ingen roll om man säger att man ger bloggarna uppmärksamhet eller rum för diskussion på sajten om ingen vet om att den här sajten också gör det. Så att man måste verkligen få ut budskapet. Så det kan vi hjälpa till med. Det gör vi som en rutinmässig del av det paketet.

[00:25:09] Speaker B: Hur agerar ni med Om folk skriver inlägg och länkar till väldigt många tidningar, har ni någon hantering av det? Ser ni det som positivt? Hur ser ni på det?

[00:25:20] Speaker A: Det är inte positivt. Till viss grad är det väldigt positivt att man länkar ihop många tidningar. För den mekanismen finns inte. Tidningarna själva länkar ju inte till varandra. Vi har sett på webbchefer som säger att de jättegärna skulle vilja länka till konkurrenten bara. Bara redaktionen tillåter. Men de har ju så lång historia att leva upp till. Så det är ju ingen som... Den kulturen

[00:25:45] Speaker A: finns inte där. Så där kan bloggarna faktiskt fylla en funktion. Att man kan... När man klickar på en kommentar på DN så kan man få länkar till precis samma ämnesområde på SVD, Aftonbladet och Expressen och så vidare. Men däremot, för att återgå till din fråga så... När det blir för mycket, att man gör det för att bara få trafik från så många artiklar från så många tidningar som möjligt. Då

[00:26:11] Speaker A: sänker kvaliteten på tjänsten väldigt mycket. Särskilt om man då inte skriver någon kvalitativ kommentar till det här utan bara mest lägger upp länkarna. Så att där har vi bett bloggare vänligen att att minska volymen. Och då har de gjort det. Det har varit ett större problem än det är nu, men det finns fortfarande

[00:26:36] Speaker A: bloggare som gör det. Det är en svår gränsdragning där, eftersom det inte är någonting som går att sätta en fast gräns. Vi har pratat om det också, men sätter man en fast gräns på fem eller sju länkar per inlägg, eller tre, så innebär det att alla kommer att lägga sig på den gränsen. Det är inte heller bra. Vi försöker så mycket som möjligt att inte påverka bloggarens beteende. Utom det

[00:27:02] Speaker A: här att det uppmuntrar dem att ta det här extra, göra sig besväret att lägga länken till tidningen och så vidare.

[00:27:12] Speaker B: Har ni funderat på någonting på tal till nästa nivå där man inte behöver länka?

[00:27:18] Speaker A: Ja, det finns... Det finns en konkurrent till oss som heter Sphere.com i USA som fungerar på det sättet. De har en relevansmekanism som gör att tidningen automatiskt får in innehåll från bloggvärlden som är relaterad i en länklista. Det är en variant som man skulle kunna använda, men från tidningarna finns inte den efterfrågan

[00:27:45] Speaker A: riktigt. Därför att de vill ju verkligen motivera bloggarna att lägga den här länken också så de får lite trafik och sökmotorrankningar. Och de får relevant innehåll ändå. Så det finns idag egentligen ingen efterfrågan på att göra det. Men det skulle vi definitivt kunna göra. Och vi kommer utveckla den

[00:28:12] Speaker A: metoden för som gratis tjänst för bloggare och kanske börja där. Så får vi se om det är någon som också vill använda det. Så det är en definitiv möjlighet. Här är en uppmaning till hur man kan engagera sig i vår lansering. Det här är framförallt budskap till bloggare ute i Europa som ännu inte känner till att

[00:28:37] Speaker A: vi har den. Tvinges stryk, men ju fler bloggar som pingar oss desto bättre, desto högre kvalitet får vi på vår data. Och för bloggaren så innebär pinga oss direkt innebär att man garanterat kommer in i vårt index och blir uppklockad av tidningarna och vår sökmotor istället för att man ska vara beroende av att vår sökspindel kanske hittar blogginlägget. Pingar många bloggar

[00:29:02] Speaker A: så är man inne i sökindexet. På ungefär mellan tre och fem minuter. Man kommer kunna signa upp för en beta-test av den här sajten. Vi lanserar den i stäng beta för att vi vill ha en ganska nära relation till allt som surfar in på sajten så att vi kan få feedback och

[00:29:28] Speaker A: även kommunicera ut när vi lanserar nya features. Och vi vill ge er feedback. Om man bloggar om vad vi gör så kommer vi hitta det. Och vi kommer från och med den här lanseringen att lägga upp stora delar av vår teknikplan för omröstning på

[00:29:53] Speaker A: sajten. Vilket innebär att man kommer kunna ge input på vad man vill se och även föreslå egna features själva. Som sedan andra kan rösta på direkt när man har skrivit dem. Så där kommer vi vara så transparenta det går. Sen är det vissa features som är konkurrensutsatta som vi inte kommer annonsera

[00:30:18] Speaker A: i förväg för omröstning. Det är sådana som är så så omfattar med att vi ser att vi utvecklar dem när vi själva gör en bedömning och vill inte tala om i förväg att det kommer. Så det kommer vara en blandning av features som har röstats fram av communityn och sådana som vi själva har bedömt är viktiga.

[00:30:51] Speaker A: Så fort man får access till betan så får man också access till teknikplanen och kan delta i det arbetet efter eget intresse. Så det var den presentationen. Jag tänkte gå in lite på nu vad det egentliga temat för föreläsningen, hur vi har hur vår tekniska plattform har

[00:31:16] Speaker A: utvecklats fram tills den är nu. Nu har vi bara tio minuter kvar på första timmen. Men det vi hinner med då är den första versionen av plattformen där vi gjorde allting fel. Där vi byggde en plattform som inte var skadad. Så det kan vara informativt. Ta lite bakgrund.

[00:31:45] Speaker A: Då gör vi det mer analoga sättet. Och om det är någon som vill höra av sig till mig så kan jag få adressen Martin. Här, så undrar vi. Så, det var tydligt.

[00:32:14] Speaker A: Jo, skillnaden mellan skalbarhet och prestanda tror jag att alla är familjära med. Eller kanske inte, men i grund och botten så handlar det om att man kan optimera kod för att köra väldigt snabbt. Prestanda bara till en övre gräns till hur stor kapacitet

[00:32:39] Speaker A: eller hur stor prestanda man kan skapa genom att optimera. Skalbarhet innebär att man bygger system som inte har en övre gräns. Om man bara tillför sig pengar och utrymme att ställa servrarna så kommer man aldrig slå i taket. Och det är en väldigt stor utmaning att hitta den där lösningen som

[00:33:04] Speaker A: ger absolut sparmångfald. Man får väldigt lätt flaskhalsar någonstans. Och det är inte så att man bygger en skapbar lösning från början och sen så är man klar och kan gå hem. Utan det dyker hela tiden upp nya utmaningar. Det som fanns, sättet att spara i början, som

[00:33:30] Speaker A: används fortfarande förut med väldigt mycket idag, som vi använder från början är att när man bygger en databas och börjar stoppa in data i den och när man Man har den i en server och när datat börjar bli väldigt... Börjar

[00:33:57] Speaker A: belasta systemet för mycket så man får prestandaproblem. Så köper man en ny server och så flyttar man över hela databasen i den. Flyttar dataströmmen in i den databasen istället och så är man nöjd och lycklig ett tag. Därför att allting funkar bra igen. Och det gör att det finns det sättet att skala Det kallas för att skala dem vertikalt. Att

[00:34:22] Speaker A: man köper större och större datorer. Det är det tankesättet som gör att det finns servrar som klarar av hundratals gigabyte internminne. Eller att man kan koppla samma server till hundratals hårddiskar. Därför att det traditionella

[00:34:47] Speaker A: sättet att skapa mjukvara är att bygga det för att köras på en enda plattform, en enda hårdvara. Och när man slår i taket för det samhällsmässigt så måste man utöka kapaciteten i hårdvaran. Och det där, för en startup så är det inte så roligt för att det blir väldigt dyrt så fort man kommer upp i att man ska köpa en server med 32 meg minne eller 64 meg

[00:35:12] Speaker A: minne så svider det verkligen i plånboken när man ska betala för det där. Och som jag sa så går det att komma ganska långt så länge det bara rör sig om datainhämtning. Vi har fortfarande systemet i drift som vi utvecklade från dag ett för två år sedan. Det klarar av väldigt bra att hämta in data. Däremot

[00:35:39] Speaker A: så klarar det inte av att göra någonting med datat utöver att filtrera ut bara den sista lilla delen av datat som man nyss har skrivit. Ska man göra operationer på hela datamängden så måste man bygga sker som hämtar ut data i småsnuttar och kanske ta tre, fyra timmar över att köra en sker. Det man gör istället är att man försöker bygga hårdvaran

[00:36:05] Speaker A: så att den skalar istället horisontellt. Det vill säga, när man behöver mer kapacitet så köper man en dator till. Och det kan vara sådana här små tunna pizzakartonger som kostar 6000 spänn på det. Och

[00:36:33] Speaker A: den principen använder vi nu och det är mycket, mycket angenämare att jobba med när man har ett system som klarar av det. Och det gör att man kan börja med väldigt låga hårdvaruinvesteringar men ändå ha ett system som man vet tryggt och säkert att när prestandakraven kommer I det fallet att man når framgång i tjänsten så har man möjlighet

[00:36:59] Speaker A: att lägga till nya burkar vid sidan av de gamla som då tar över en del av lasten. Och där det hänger på är att man inte så korkar att man inte tjänar mer pengar men man får större prestandakrav samtidigt. Det är en helt annan utmaning. Men utmaningen

[00:37:27] Speaker A: ligger i att bygga system så att man kan lägga till en server till. Man kan lägga till tio servrar till när behovet uppstår. Det finns mjukvara idag som klarar av det. Det finns också mjukvara som inte klarar av det. Och vi hittade att välja mellan de två och att bygga klisteret mellan med olika mjukvarukomponenterna så att det

[00:37:52] Speaker A: klistret inte blir en flaskhals. Och sen så är det väldigt stor utmaning att konfigurera hela systemet för att det ska löpa smärtfritt. Och jag ska rita upp hur vårt hur vårt system ser ut idag. Vi

[00:38:25] Speaker A: har data som kommer in i ena änden och sedan går ut i andra. Och där det går in så har vi idag inga prestandaproblem, vilket innebär att det än så länge är en enkel databas. Som inte har några skapbarhetskrav på sig. Det vi får in är sådana här pingar som vi ber bloggarna göra. De kommer in i en databas

[00:38:50] Speaker A: som ligger och körs i MySQL. Det är en tabell där vi gör dubbelcheckar och i stort sett lägger upp en kö på pingar som ska bearbetas. Ett antal sök klienter som genom ett webbgränssnitt hämtar

[00:39:23] Speaker A: det här datat och genom en fetlina ut till till internet. Hämtar in, där vi får in en finger helt enkelt, en adress så att en logg uppdateras. Så att de här klienterna går ut och hämtar data på internet. Och här har vi, så att vi får det första skalbarhetsproblemet,

[00:39:50] Speaker A: att den här klienten, även när vi optimerade den så hade den inte bestannat nog på en server. Att hämta in data för alla tingar som kommer in. Vilket innebär att vi ganska snabbt delar upp den på flera servrar. Tack vare att vi hade byggt den med en serviceorienterad arkitektur så att

[00:40:15] Speaker A: vi gick och pluggade på och pluggade in nya klienter i samma lager så var det en ganska enkel sak att göra. Och det är det enklaste skalbarhetsproblem som vi har löst. Och sen så lägger de här klienterna återigen genom webbservice resultatet

[00:40:40] Speaker A: i en ny kö som inte ligger i en databas på något sätt, utan ligger på disk. Som binärfiler på disk. Och det är lite... Jag vet inte om du har sysslat med det här, disk? Nej. Om vi ritar den som en databas istället. Ska

[00:41:06] Speaker A: vi göra så här? En disk har ju ringar på sig, eller hur? Har den inte det? Och sen därifrån så hämtade vi in den i en stor databas som fick allt innehåll, en server med tillräckligt

[00:41:32] Speaker A: mycket disk i en extern kabinett. Klara av att hantera all data. Det vi i stort sett har i strukturen här är att vi har dokument som hör till webbsajter. Det vill säga vi har en ett till

[00:41:57] Speaker A: många relation och sen har vi en länk tabell som helt enkelt utgör en många till många relation mellan dokument. Så det är på pappret en väldigt enkel struktur. Och problemet uppstår

[00:42:22] Speaker A: när man har börjat få upp mot 100 miljoner rader i varje Vi har över 170 miljoner länkar och vi har 20 miljoner bloggar och webbsajter som ni lagar. För att det blir för mycket data

[00:42:49] Speaker A: för att man ska kunna söka igenom det. Och det är för mycket data för att man ska kunna ändra på datastrukturen. Så några misstag man gjorde i början av utvecklingen, de får man leva med under resten av databasens livstid. För att datat är för stort för att man ska kunna lägga på nya index utan att ta ner den. Eftersom vi har driftskrav på databasen så går det inte att ta ner den och lägga på ett index som tar 24 timmar

[00:43:14] Speaker A: att skapa. För då har vi 45 tidningshäftor om du blir irriterad. För stor för att man ska kunna uppfylla nya behov. Den fungerar för det behovet den konstruerades för. Men det blir väldigt mycket uppförd packning när man ska göra någonting som

[00:43:39] Speaker A: den inte konstruerades för att göra. Så jag tror att vi tar en kvart rast nu och sen så ska vi berätta efter pausen hur generation två av inhämtningen ser ut nu. Så kan vi ta ett rast och sträcka på benen.

[00:44:06] Speaker A: Hur man konfigurerar diskarna på en sån här server. Och för att en databas... Det här är faktiskt inte en MySQL utan en MSSQL. Och för att den ska vara konfigurerad optimalt så måste man ha inte tre utan fyra stycken hållbara partitioner. Dels så är det

[00:44:32] Speaker A: ett operativsystem som ska ha sina egna diskar att köra på. Dels så är det en databas där alla temporärtal överlagras. Sen är det en indexpartition där alla index lagras. Och sen kan man ha en eller fler partitioner som lagrar det här med datat. Och om man har en halv terabyte

[00:45:00] Speaker A: data här så har man kanske 100 megabyte index och 100 megabyte ämndata. Det är ju inte så totalt lika en terabyte data som man ska eller utrymme som man behöver här. Även om man vill ha en halv terabyte data så vill man ha en terabyte utrymme som man har något växer i. Men för att skapa den här terabyte utrymme. Det

[00:45:27] Speaker A: är inte bara att åka och köpa två externa hårddiskar på Siva som är på en halv terabyte var. Utan man behöver sätta upp ett raidset med kanske 10 diskar som då inte är de här lyxigt billiga SATA-diskarna som finns på Sibor utan vår bas där Operate from Hell vill naturligtvis ha jättedyra SAS-diskar som

[00:45:52] Speaker A: är 15K och bara finns i jättesmå storlekar. Nu börjar de bli överkomliga även i större storlekar. Men det innebär att för att få den här en terabyte med lagringsutrymme så måste man ha kanske ett tjugotal diskar som sitter ihop konfigurerade på olika sätt. Och den här totala

[00:46:17] Speaker A: lösningen kostar någonstans mellan 50 och 70 000 att köpa in. Beroende på hur mycket minnen man ska ha i mina processorer. Och att köpa en server för 50 000, det är jättedyrt. Man upplever det som väldigt mycket pengar när man är en startup som lever på svältgränsen. Och istället,

[00:46:44] Speaker A: nu ska jag få plats med den här. Istället för att ha den här databasen som man skalar vertikalt, det vill säga att man köper en större burk när den rörs, så har

[00:47:09] Speaker A: vi byggt nu en horisontell datalagring, en horisontellt skalbar datalagring. Det innebär att vi har en databas Som är uppdelad på flera servrar. Och som jag sa, vi har 100 miljoner dokument. Och när

[00:47:35] Speaker A: vi får in ett dokument så haschar vi den. Haschar vi ur den för det blogginlägget. Och då får vi ett 64 bits id som vi använder som dokumentets primärnyckel. Det gör vi med en SK1 hash som i vanliga fall är 256 bitar. Den tronkerar

[00:48:00] Speaker A: vi ner till 64 bitar. Vi körde det på i storleksordningen 10-20 miljoner dokument och såg att vi fick inga kollisioner i haschen. När det var urlar vi haschade, även om vi körde ganska stora volymnycklar. Vilket gjorde oss tryggare att vi kunde tronkera ner den haschen till 64 bitar och använda den som en primärnyckel. Det kan fortfarande inträffa

[00:48:25] Speaker A: att det kommer in två olika blogginlägg som får samma primärnyckel. Vilket gör att en bloggare i Malaysia som blir väldigt förvånad när han får visa sig att ett norskt blogginlägg är kopplat till hans blogg. Men vi tror att det inte kommer inträffa. En 64 bits rymd är oerhört stor och en url är en ganska specifik utformad sträng som

[00:48:51] Speaker A: har så stora restriktioner på sig. Det gör en krock i hashrymden väldigt, väldigt osannolik. Hoppas i alla fall. Sen blir det inte några större efterverkningar om en krock skulle inträffa. Men den här haschen, eller dokumentet i det, den moddar vi. Så

[00:49:17] Speaker A: apparaten moddas. Med antalet tabeller som vi vill lagra datat i. I det här fallet just nu är det 128 tabeller som är numrerade från 0 till 127. Så då får vi fram en siffra på vilken tabell den

[00:49:42] Speaker A: här ska lagras i. Och då har vi just nu har vi som jag ritat här fyra stycken databasserver som kör varsin MySQL-databas. Och i varje Varje databas så har vi alltså fjärdedelen av 128 tabeller. Vilket

[00:50:08] Speaker A: innebär att vi har över hela det här datasättet har vi 128 tabeller att stoppa in data i. Och 128 delat på 4, 32, Så vi har 32 tabeller i varje dator. Och de lagrar samma typ av data och tabellen ser

[00:50:33] Speaker A: likadan ut. Och när vi stoppar in 100 miljoner dokument i 128 tabeller så innebär det att det hamnar i storleksordningen en miljon dokument. Dokument i varje tabell. Så nu har vi gått från en lösning där vi har en tabell med 100 miljoner dokument till 128 tabeller där vi har en miljon dokument. Och en tabell med en miljon dokument är

[00:50:59] Speaker A: mycket, mycket mer hanterbar. Det kan en ganska hårdvaru traversera igenom väldigt snabbt. Och eftersom vi då har Det här är väldigt små burkar. Det här är i och för sig KCPU. De har bara 8 megabyte minne. Det

[00:51:26] Speaker A: är KCPU på 2 GHz. Men det här är, förutom minnet på 8 megabyte, det här är den nästan den billigaste hållbara konfigurationen som man kan köpa en rackserver i på Dell. Ursäkta, måste du inte mena 8 gigabyte? Ja, jag menar förstås 8 gigabyte. Tack.

[00:51:56] Speaker A: Och det gör att när vi När de här får prestandaproblem så kan vi fylla på med fyra servrar till. Samma konfiguration eller en annan konfiguration om det finns en ny hårdvara som skulle lämpas bättre för problemet. Sen

[00:52:23] Speaker A: kan vi stänga ner inhämtningen av data tillfälligt, kapa den, vilket innebär att Kön där borta i inhämtningen kommer börja växa. Så datat hämtas fortfarande in. Men läggs på hög i den här binära kön. Så hela den här processen körs fortfarande.

[00:52:48] Speaker A: Det kommer in finger som gör att vi hämtar blogginlägg. Men blogginläggen stannar här. Och under den här omkonfigureringen så har vi stängt av datainhämtningen. Sen kopierar vi över hälften av de här tabellerna, då 16 stycken från varje server, in här. Så vi får då 8 servrar

[00:53:14] Speaker A: med 16 tabeller. Sen skriver vi om config-filen för var varje tabell ligger lagrad i vilken server och vilken databasinstans på den servern. Sen när vi sätter igång inventeringen så börjar

[00:53:40] Speaker A: den här tabellen fyllas på med det data som har legat uppbuffrat under tiden. Det gör att vi kan ha de här servrarna under den här kopieringen så kan de fortfarande ligga läsbara i drift. Det sker bara inga skrivningar till dem. Vilket innebär att när den här omkonfigureringen sker så kan fortfarande sök-API:et som accessar

[00:54:05] Speaker A: datat ligga och köra utan avbrott. Och inhämtningen kan fortfarande ske utan avbrott. Men vi kan fortfarande spara ut dubbla kapaciteten i den vitala delen av systemet utan vare sig avbrott i inhämtning eller skrivning. På det

[00:54:32] Speaker A: här sättet så har vi nu en hantering av data som gör att vi har kommit runt skalbarhetsproblemen i den mest vitala delen av systemet med datalagringen. Är det några frågor kring det?

[00:54:54] Speaker B: Men resultatet blir ändå att ni har 128 tabeller totalt sett fast spridda på dubbelt så många.

[00:55:02] Speaker A: Precis. Och det gör att man ska läsa ett enda dokument så måste man då. Då har vi primärnyckel och vet man att man ska hämta dokumentet med det här. Den här urlen och metadata kring det. Då då hörs man urlen modder med hundra tjugoåtta och slår upp i konflikten. Väljer bort vilken databas server, vilken databas instans som som kör den

[00:55:28] Speaker A: eller som innehåller den dokumentet från början. Och ska man hämta en lista på. På dokumentet. Man har tusen dokument att hämta ut. Då moddar vi alla de här iderna. Vi tar fram iderna och från vilken databasinstans som varje dokument ska hämtas ut. Så splittas den här upp på åtta olika listor

[00:55:54] Speaker A: som då körs mot varje instans och så får man ut och sen får man världsredan när man får ut det. Så det blir mycket mer komplicerat att ställa queries mot datat. Men det är priset för att ha en datamodell som gör att man kan skala ut till. Att köpa de här nya servrarna kostar kanske 32 000

[00:56:19] Speaker A: kronor. Så för väldigt billiga pengar kan vi skala. Skala upp lösningen. Sen finns det en gräns här. Vi får ju se om vi får ångra oss dyrt och heligt här, men nu har vi satt en gräns här på 128 som data på vår server. Och det är helt enkelt ett bett. Jag som nu

[00:56:45] Speaker A: inte längre jobbar så nära tekniken som de som utvecklaren på heltid i Twingling tyckte att det här skulle vara väldigt mycket bättre om det var 1024 databastabeller från början. Problemet är att det blir ju när man sätter sig och utvecklar det så när man har 1000 tabeller i MySQL-adminsystemet

[00:57:13] Speaker A: så blir man ju pissdoft i slutet. Så då gjorde vi ett beslut om att skala ner det till 128 tabeller. Vi har hört bett om att vi kanske kommer klara oss med 128 tabeller tills det är dags att skapa nästa generation av system.

[00:57:33] Speaker B: Var ligger gränsen på, eller gräns finns det inte den meningen, men var börjar det bli problem med stora tabeller? För nu har ni ju då dubblerat, om ni uttalar er så, då har ni ju dubblerat mängden. I varje tabell. Om ni hade ungefär en miljon rader i en sån här tabell så får ni där får ni då två miljoner rader i en sån?

[00:57:54] Speaker A: Nej, tabellerna är fortfarande lika stora. Vi, vad vi gör är att vi tar, det är hela tiden 128 tabeller. In i nuläget när vi har fyra servrar så har vi totalt 128 tabeller. När vi tar nästa steg och köper fyra servrar till så kommer vi fortfarande ha 128 tabeller. Och

[00:58:20] Speaker A: storleken på tabellerna bestäms inte av antalet servrar utan det är fortfarande lika många tabeller och lika mycket data i varje tabell. Däremot så gör ju datainhämtningen att det hela tiden flyts på med data. Så det här kanske vi gör Därför att vi slår igenom gränsen som du pratar om. Men där ligger gränsen. MSSQL som är en kompetent databas,

[00:58:46] Speaker A: men det är inte så att den är oändligt mycket mer kompetent än MySQL. Den klarar av tabeller på 200 miljoner dokument eller en miljard rader i en tabell. Och det gör MySQL också om man får. Begreppet. Däremot så blir tabellerna väldigt ohanterbara. Så vi tror

[00:59:13] Speaker A: ju att vi vill behålla tabellerna under kanske 10 miljoner rader. Man ser ju på det som ligger i när det är en miljon rader i varje tabell. Det är ett års bloggdata. Så varje år kommer vi lägga på, om vi behåller ungefär samma grad av inhämtning, så

[00:59:39] Speaker A: kommer vi lägga på ungefär en miljon rader i varje tabell per år. Sen kommer vi hitta på massor med saker som gör att den här inhämtningshastigheten ökar kraftigt. Då kanske vi stöter i problemet. Att det hade varit bättre med fler på väder utan att det är antalet servrar som är frågan. Så det återstår att se vart

[01:00:04] Speaker A: flaskan ser ut.

[01:00:07] Speaker B: Är det enda intäktsmodellen idag att sälja det här också med tidningar?

[01:00:15] Speaker A: Vi har två intäktsmodeller till. Dels så ställer vi dataflödet till ett par olika mediabevakningsföretag. Det finns ett företag som heter Sition som är världens största mediabevakningsföretag som finns här. De har huvudkontor i Sverige. De köper data för oss och då är det också med prenumerationsmodell. Sen finns det ett företag som heter

[01:00:40] Speaker A: Itellio och ett som heter Retriever. Det är några olika företag som de har som som affärsmodell att de bevakar varumärken och sökord åt andra företag. De har gjort det traditionellt i media med tidningsurklipp och sådär. Sischen har fortfarande 300 personer som sitter och klipper ur tidningsurklipp ur papperstidningar och lägger i kuvert. Men förutom

[01:01:06] Speaker A: det så har vi också åt några olika PR-byråer så gör vi Enstaka konsultuppdrag där vi tar fram analyser av vad bloggare har skrivit om till exempel.

[01:01:16] Speaker B: För det ni indexerar för det är blogginlägg?

[01:01:18] Speaker A: Ja. Det är inte tidningsartiklar? Ehm... Alls? Eller? Nej, det är inte tidningsartiklar. Alls. Det vi... För det vore ju en tänkbar... Ja, det vore en tänkbar utövning. Ehm... Jag ska säga att vi... Vi faktiskt indexerar våra kunders tidningsartiklar. Hämtar vi in titlarna för att vi ska kunna göra snygga

[01:01:43] Speaker A: topplistor av tidningsartiklar. Så vi har en liten databas vid sidan av här framme som lagrar.

[01:01:50] Speaker B: Men det är väldigt liten volym jämfört med de bloggar du indexerar där. Som de hämtar upp i månaden. Eller bara på pingar eller pollar ni bloggar också för att se om det kommer något nytt på den bloggen? Alltså med både en feed eller motsvarande? Eller måste en bloggare pinga för varje nytt inlägg de skriver?

[01:02:14] Speaker A: Det är en kombination av väldigt många olika inlämningssätt. Dels så får vi en pinga. Dels så är det väldigt många blogghotell som pingar oss automatiskt utan att bloggarna gör någonting. Som blogg.se och Expressens blogghotell, Aftonbladet och några andra ute i Europa. Framförallt i norra Europa. Sen har vi

[01:02:40] Speaker A: också dels en crawler som jobbar med att upptäcka nya bloggar och dels så gör vi också något vi kallar internt för Roundhouse Ping. Vilket innebär att vi cirkulerar igenom en uppsättning av bloggar som vi tycker är viktiga och hämtar in RSS-filer från dem. Så det görs kontinuerligt.

[01:03:01] Speaker B: För då blir det ju då en... Alltså om bloggarna vänder sig av med att behöva trycka på någonting här så blir det en fråga om hur bra är ni på att springa runt och hitta saker?

[01:03:12] Speaker A: Ja, exakt. Ja visst. Och det är ju det som... Om man vill bygga en konkurrent till Twingly. Det bästa tipset jag har att ge då är att ta alla... Vill man snabbt bygga upp en stor databas av bloggar så om man bygger den här inhämtningen här så robust att man kan stoppa in vilket

[01:03:38] Speaker A: feed som helst eller vilken webbsida som helst i inhämtningen utan att det kommer ut skräp. Det vill säga den har filter för att känna igen att det här är en blogg som vi ska hämta innehållet för. Det här är inte en blogg, det här kanske är Google-sökeresultat med RSS-filen eller det kanske är en ny sajt som inte har blogginlägg. Om man har den egenskapen här, då kan man ta, när man

[01:04:03] Speaker A: får in ett blogginlägg som man har identifierat som ett blogginlägg, då kan man ta alla utlänkar från det här blogginlägget och föra tillbaka som ping till början. Så då kommer man få ett index av bloggar som bara exploderar och snabbt får väldigt hög täckning. Så gör det om ni vill bygga konkurrenter på det där. Är det några

[01:04:29] Speaker A: mer frågor kring det här?

[01:04:37] Speaker B: Om man utan den här länkautomatiken skulle ha hittat blogginlägg som verkar relatera till den här nyheten.

[01:04:47] Speaker A: Ja.

[01:04:48] Speaker B: Då skulle man ju gärna kanske indexera tidningsartiklar lika gärna som bloggar för att kunna matcha.

[01:04:52] Speaker A: Det vore jätteintressant. Att göra en matchpunkt på index. Och det vore väldigt intressant att, för att det finns också algoritmer för att ta ut citat, de används för att det tycker jag är pariat. Skolor och universitet använder för att göra plagiat i uppsatser. Om man kunde göra det i bloggvärlden så skulle man snabbt upptäcka när bloggare plagierar varandra.

[01:05:18] Speaker A: Eller ännu mer intressant om det förekommer journalister som plagierar bloggar utan att ge en källreferens. Eller kanske snällare, inte plagierar utan citerar. Eller om det finns bloggare som regelrätt citerar massmedier utan att ge källreferenser. Så det vore väldigt intressant,

[01:05:43] Speaker A: särskilt om man får upp en sådan algoritm för att hitta relevanta eller relaterade blogginlägg, att då också hämta in massmedia. Och det vi har nu är alltså ett system för att hämta in bloggar. Lagra dem på ett sätt som gör att man kan effektivt både läsa och skriva utan sparbältproblem.

[01:06:09] Speaker A: Man kan utöka det här utan att det blir avbrott i driften. Och sen vill man göra någonting med datadags. Då kommer det tredje steget i den här kedjan. Det går ut på att man vill sätta upp en

[01:06:34] Speaker A: sökmotor som accessar det här vattnet. Det man vill göra är att bygga upp ett inverterat index av all data som finns här. Och snabbt vad det går ut på. Om man har blogginlägg så att vi får in tre blogginlägg med ID 1, 2 och 3. Det här är väldigt hypotetiskt. Med

[01:07:00] Speaker A: orden. Första inlägget är någon som har skrivit "Far är rar". Andra har skrivit "Jag är rar". Och det är någon som har skrivit Rör är bra. Och då syftar jag på kompromissprogrammet Rör. Då kommer de

[01:07:26] Speaker A: här tre dokumenten, alltså lagras i databasen i de instanserna där vi har konfigurerat varje dokument att ligga. Och då kommer vi hamna här. Moddar man 123 med 128 får man också 123. Det är inte så illa. De kommer lägga i tabell 123 i den första sökaren.

[01:07:55] Speaker A: Men för att bygga upp en snabb sökning av det här. Om man skriver in ett sökord, det naiva sättet att söka efter data. Är ju att gå igenom alla tabellerna och i varje tabell när man hittar ett dokument plocka ut hela inlägget och sen så gå igenom inlägget ord för ord och kolla

[01:08:20] Speaker A: motsvarande sökordet. Och det är ju inget man gör. Istället så bygger man upp det inverterade indexet där man tar varje ord och ger det en rad i en ny datastruktur. När man indexerar det första dokumentet här så får man in orden far, är, rar.

[01:08:46] Speaker A: Så lagrar man här vilka dokument i den de förekommer i. Ett, ett och ett. Sen dokument två får man in ordet jag som är nytt. De andra existerar redan. Så skriver man in det inverterade indexet. Jag förekommer vara i ord två. Och sen så får man till ordet bra i

[01:09:12] Speaker A: index tre. Tre, tre och tre. Och det gör att om man sen söker bordet rar så får man en datastruktur där man kan väldigt snabbt då med... I en hashtabell, slå upp ordet "klar" till exempel och få ut vilka dokument innehåller det ordet. Och då genom att

[01:09:37] Speaker A: skapa en sån här lista av vilka instanser man ska få ut dokument i väldigt snabbt få ut just de dokumenten som är relevanta till sökordet. Sen är det här egentligen i själva verket mycket mer komplicerat än bara att man vill filtrera på sökord. Man vill dessutom göra en sortering. Man

[01:10:03] Speaker A: vill lagra var i dokumentet det förekommer, om det är i titeln eller om det är i bodyn eller om det är i länkadressen. Man vill dessutom ha en massa metadata som ska tas med i beräkningen av den här sökningen. Som att det här dokumentet kanske har tre inlänkar medan de andra har noll. Och en relevansalgoritm skulle kunna göra bedömningen att eftersom det

[01:10:29] Speaker A: har fått tre inlänkar så är det mer intressant än de andra. Men det här är i alla fall grunden för hur alla sökmotorer från viss desto och search som jag har på laptopen här till Google med deras 80 000 servrar eller vad de har nu, 200 000, någon som vet. Hur

[01:10:55] Speaker A: det är uppbyggt. Och det här indexet är ju också någonting som väldigt snabbt kommer att stöta på skadbarhetsproblem. Och att den här Det som har genomfört genomgången i den här lösningen är ju att det enda som, ja det enda ska jag säga, kanske inte stämmer, men det som framförallt är mjukvara

[01:11:20] Speaker A: som vi har utvecklat själva, det är ju dels så är det den här boxen, den här klienten som har försökt att ta någonting och hämta in data på ett kvalitativt sätt. Och sen är det alla pilar och boxar och det här klistret som krävs för att systemet ska sitta ihop. Men om man undantar för det så är det ju

[01:11:45] Speaker A: databaser och applikationsserver och operativsystem som är de stora komponenterna. Och här på söksidan så har vi också använt en färg mjukvaror istället för att utveckla den egen. Och det finns en väldigt kompetent mjukvara som heter Sphinx. Som är en sökmotor

[01:12:12] Speaker A: som har en skalbarhetslösning inbyggd. Och den har vi baserat våra sökningsnivåer på. Och jag vet inte om någon av er har hört talas om Om den här, du har gjort det här. Viktigt sammanhang. Blogg så använder den till exempel som du nämnde. Just det, ja. Och

[01:12:38] Speaker A: den traditionella, den stora open source sökmotorn som finns i Lucine som alla säkert känner till. Den finns ju i massor med, det finns en dot Lucine och så vidare. Vi valde Sphinx för att den har en skalbarhetslösning. Inbyggd. Man när man sätter upp ett sånt här index lagar man den igen. Man lagar den i binär format på disk. Den

[01:13:04] Speaker A: som inte ska byta disk där och har man många sådana index så kan man så kan man. Sätta in dem i en hierarki. Så man kan ha en... Nu ska vi se här. På varje sånt här index så finns

[01:13:29] Speaker A: det en sök... Search... Search... D. En sökemon. Som söker just det här indexet. Och man kan stoppa in de här i en hierarki. Som gör att man kan ställa en

[01:13:54] Speaker A: sökning mot en sökdom som har det hierarkiska indexet konfigurerat. Den distribuerar ut sökningarna och gör att de hanteras parallellt på de här hårdvaruinstanserna och man begär att få kanske de tio mest relevanta

[01:14:19] Speaker A: eller de hundra mest relevanta dokumenten som söksvar. Och det innebär att var och en av de här databaserna plockar ut så många, tio eller hundra, hur många man begär och lämnar som svar till den här centrala sökmånen. Så den får i det här fallet tre stycken på tio dokument eller hundra dokument och sen möts här ihop dem så att

[01:14:44] Speaker A: den får ut de totalt mest relevanta dokumenten. Och på det här sättet så får vi också i den här änden då en skalbarhet som då finns inbyggd i den här mjukvaran. Som också måste till är och som har varit en av de stora utmaningarna för oss. Den

[01:15:10] Speaker A: här processen att skapa det här indexet är ganska ganska den kräver ganska mycket kapacitet eller resurser. Så vi har separata burkar som kör Swings indexdemoner. Schemalagt så att man hela tiden flyttar in data i indexet.

[01:15:36] Speaker A: Men problemet är att det blir väldigt mycket data än här att hantera. Och de där indexen har vi väldigt höga realtidskrav för. Om ni kommer ihåg i Googles barndom, då fanns det något som kallades Google Dance. En gång i kvartalet byggde de om hela sitt index och la till nya dokument. Den

[01:16:01] Speaker A: samma operation måste vi göra på förvisso en mindre mindre datamängd, men var tredje minut och det är mycket, mycket större utmaning och det har vi löst genom att att vi i varje. I varje sånt här index, eller vad ska jag säga, på varje

[01:16:26] Speaker A: sökmånad så har vi ett antal index. Vi har delat upp datat i månader därför att bloggvärlden är väldigt tidsbunden. Man skriver när blogginlägg är väldigt aktuella och intressanta. Är nya och sen så förpassas de in i någon sorts arkiv där

[01:16:51] Speaker A: de ska finnas sökbara men där man fortfarande inte har lika högt intresse. Och framförallt så händer det inte så mycket med gammalt data som det gör med det som är dagsfärskt. Och det gör att vi delar in det här sökdata i index som är baserade

[01:17:19] Speaker A: på tid. Vi har i stort sett en matris av index. Så vi har två dimensioner. Om

[01:17:46] Speaker A: det här är en uppsättning index för månad 1, januari 2007, så är det här en uppsättning index för februari 07 och så vidare. Så att vi har för varje

[01:18:12] Speaker A: månadsindex så har vi samma struktur av charts som det kallas. Det vill säga vi har delat upp varje månadsindex eller åtminstone gett oss själva möjligheten att dela upp varje månadsindex i en liten bit. Sen är det faktiskt så att vi Jag tror i dagsläget att vi inte använder den här möjligheten, utan vi har bara dimension 1 i den här riktningen för

[01:18:37] Speaker A: tillfället. Januariindexet existerar bara på en enda instans. Gammal data indexerar vi om kanske en gång i veckan. Det som har kommit in senast i dygnet indexerar vi om var tredje minut. Så att man får, vi har skiftat för att utnyttja vår

[01:19:03] Speaker A: hårdvara till där den ger mest nytta. Så indexerar vi om nytt data mycket oftare än vi indexerar om gammalt. Men det är alltså då att ni hämtar in lägen igen eller? Nej. För det händer ju så att säga att det inläggs och uppdateras eller någonting som också det jag har sett på Ja, för att uppdateringen ska komma in i vår databas så kräver den

[01:19:28] Speaker A: några pingar igen. Eller att vi upptäcker det kanske långt senare när vi har den här roundhouse-pingen. Om man ingår i det systemet. Så det finns alltså en uppsättning månadsindex. Det blir fler och fler ju fler månader som går. I dagsläget är det gånger 12. Och

[01:19:54] Speaker A: sen så finns det ett dagsindex som är senaste dagens data. Och sen har vi en konfigurationsstruktur som gör att vi kan dela ut var och en av de här Bitarna av indexet kan vi fördela ut på befintlig hårdvara så att vi utnyttjar den maximalt. I

[01:20:27] Speaker A: dagsläget har vi vår hårdvarulösning ser ut på ungefär, vi har väl ett trettiotal servrar nu. I början köpte vi ganska stora maskiner. Med plats för mycket disk och mycket minne. Nu köper vi så små maskiner vi kan. Men det är fortfarande core processor burkar därför att det är den

[01:20:52] Speaker A: kapaciteten har de minsta datorerna som man kan köpa på marknaden idag. Då gör vi det. Såklart. Vi har en stark... Än så länge så ryms hela Twingly i ett enda rackskåp. Det börjar bli dags att köpa ett till. Är det några frågor på? Jag

[01:21:18] Speaker A: tänkte visa lite hur sökmotorn ser ut och fungerar. Är det några frågor på det här innan vi går vidare till det? Här

[01:22:09] Speaker A: ser vi resultatet. Vi visar tio resultat på första sidan. Men det är precis som en vanlig sökmotor. Vad sa du? Ja. Och

[01:23:02] Speaker A: sen kan man filtrera på språk till exempel. Vilka tidsperioder man vill söka på. Och sen hur man vill sortera. Så

[01:23:34] Speaker A: till formatet så ser det ut och beter sig Precis som alla andra sökmotorer. Och det som gör det lite unikt är några av de här tre sakerna. Dels så har vi erbjudit spamfritt sök. Som innebär att vi har

[01:24:01] Speaker A: gjort en initial filtrering. Vi började med ett seed på ungefär 6000 bloggar från hela världen som vi stoppar in i en whitelist som vi manuellt gick igenom och såg att det här är bra bloggar som inte är inom någon spam. Och sen har vi en algoritm för att expandera den här whitelisten genom att följa länkstrukturen.

[01:24:27] Speaker A: Så teorin är att en Bra blogg länkar inte till en spamblogg så ofta. Och det teoremet har visat sig hålla tillräckligt bra för att vi ska kunna bygga upp ett spandrigt inlägg. Och det som händer när vi stöter på ett blogginlägg

[01:24:53] Speaker A: som trots allt länkar till en spamblogg Det gör ju att vi får in spambloggar i det spamfria indexet. Och när vi sen algoritmiskt fortsätter att expandera den här whitelisten är ju att det finns spambloggar i indexet som i högsta grad länkar till andra spambloggar. Så

[01:25:20] Speaker A: att man får en accelerande situation av kaos i det spänkliga indexet av tusentals spännbloggar som kommer in därhands man följer mer och mer utlänkar från de befintliga bloggarna. Och det där hade ju varit någonting som hade gjort vår lösning omöjlig att använda om

[01:25:45] Speaker A: det inte vore så att vi kan spara informationen för i hur har den här godkännandekedjan sett ut. Så det vi gör är att vi ska rita på vad som har hänt så att det är producerat. Om man har ett träd av bloggarna

[01:26:12] Speaker A: är det inte ett träd. Kluster, eller korta länkarkluster. Men det vi bygger upp när vi börjar med en liten mängd av godkända bloggar och sen så följer deras länkar. Då bygger vi upp ett träd och för varje godkänt blogginlägg, eller snarare varje godkänd blogg, så sparar vi vilken blogg har godkänt den här bloggen. Så

[01:26:38] Speaker A: att när vi sen får in, vi har byggt upp det här gigantiska trädet. När vi får in en rapport eller vi själva ser att här finns det en blogg som inte hör dit, som är en spamblogg. Så tittar man lite närmare så ser man att i själva verket så är hela det här klustret mestadels spambloggar. För att man har fått den

[01:27:03] Speaker A: här exploderade situationen av nya bloggar. Det vi kan göra då är att vi tittar uppåt i kedjan. Är det här en spamblogg? Ja, det är det. Är det här en spamblogg? Ja, det är det. Är det här en spamblogg? Nej. Den här var en riktig blogg. Så tittar man på det här blogginlägget och så ser man att det är någon som har velat illustrera ett koncept. Pratat om att oj vad mycket spam det finns. Titta på den här spambloggen. Vilken

[01:27:29] Speaker A: rolig eller dålig eller vad den är. Eller någon som helt enkelt tyckt att nu ska jag skriva något kul om Britney Spears. Söker man på Britney Spears så får man upp en blogg som man tycker verkar innehålla någonting bra. Självverket så är det kopierat innehåll från en annan blogg och så har man oavsiktligt länkat till en spam-blogg. Det vi gör då är att vi klipper av den här länken.

[01:27:58] Speaker A: Har vi ett stort kluster av bloggar som kan vara spam-bloggar men också inte kan det? Och så går vi igenom alla de här bloggarna och ser, är de länkade från någon annan blogg som är approvad? Och vad innehåller de för någonting? Och kör en ganska hård filtrering. Man kan till och med tänka sig att man bara tar bort alla de där det är approvade inlägg. Och

[01:28:23] Speaker A: det gör att man är Med en enda knapptryckning. Här är det en spamblogg som har kommit in och sen har den här whitelist-algoritmen fått köra några generationer. Det innebär att det är 10 000 spambloggar som ligger här i ett stort kluster. Så kan vi klippa av dem med en enda knapptryckning. Och plötsligt har vi en algoritm som är ett verktyg som gör att vi kan vinna kampen mot

[01:28:48] Speaker A: spam. För att den är så oerhört skalbart. Vi kan med så enkla medel ta bort otroligt stora mängder bloggar. Och det gör att vi kan ha det här spantiga söket. Priset för det här är ju att den här expanderande whitelisten expanderar inte hur snabbt som helst. Och det finns... Den expanderar

[01:29:13] Speaker A: ju ut till kanten av centrum av bloggosfären. Utanför centrum finns det miljontals bloggar som aldrig har fått några länkar från de stora bloggarna som finns i centrum. Vi bygger upp det spännfria indexet på bekostnad av deras inklusivitet. Det vill säga, vi

[01:29:40] Speaker A: vill ha ett index som vi kan garantera är spännfritt. Och det sker på bekostnad av att alla bloggar som vi ännu inte har klassificerat inte finns med. Så som användare kan man ha valet att man kan söka i hela indexet eller i bara den delen som vi har markerat som spamfri. Så

[01:30:07] Speaker A: beroende på behov så kan man välja själv. Och drömmen är ju att Det spanska indexet ska bli så inklusivt att vi kan ta bort den här vanliga sökknappen. Till att börja med kanske vi kan göra den spanska sökknappen default. Det har vi inte ens nu för att det är för många bloggare som skulle bli ledsna då. Men det är väldigt...

[01:30:36] Speaker A: Trevligt att kunna söka på Viagra och bara hitta seriösa diskussioner om det sökordet. Eller.. Jag vet inte vad. Och

[01:31:04] Speaker A: det finns ju spam i det här indexet, men det är på mycket, mycket mindre nivåer än om man söker i hela bloggsfären som innehåller oerhörda mängder med spam. Så det är en av sakerna vi jobbar väldigt mycket med. Den andra saken är att vi ger ger

[01:31:31] Speaker A: användare möjlighet att rekommendera bra innehåll till varandra. Så att om man tycker att den här blogginlägget som finns här är kvalitativt så kan man rösta på den. Då får den en högre ranking och kommer att komma högre i sökresultatet när nästa person söker. Nu var det förstås väldigt... inte så illustrativt att klicka på den översta. Se om man

[01:31:59] Speaker A: trycker på den här. Tar den sig upp då? Nej. Jag tycker om alla inlägg som skrivna Twingly så jag kan gå igenom den här. Men det här inbjuder verkligen till missbruk. Man kan ju mycket väl tänka sig att man vill skapa tusentals användare

[01:32:24] Speaker A: och sätta upp något maxerat system som gör att alla ihop, när ett stort rapportutlägg så klickar alla på det, eller säger alla att de tycker om det så hamnar det längst upp i sökresultatet under hundra år framåt. Men det kommer vi lösa på två sätt. Dels så kommer det globala sökresultatet bara påverkas av de

[01:32:50] Speaker A: användare som har blivit approvade enligt precis samma principer som vi gör med spannloggarna. De användare som har blivit godkända av oss, det kommer vi vara väldigt liberala med, men vi kommer hålla viss koll på dem. De kommer få möjlighet att bjuda in sina kompisar. Enligt principen att en god person

[01:33:15] Speaker A: tillräckligt sällan bjuder in en spannare eller någon som är missbrukare. Jag har liknande sådana system på andra sidor. Man kan inte komma med, det blir rent ut sagt rekommenderade av någon som redan är inne. Men på de här har jag också sett att de har ett sorts straffsystem. Så att de bjuder in någon som missköter sig. Så åker man själv på att få skit för det så att säga. Är

[01:33:40] Speaker A: det någonting som ni har funderat på? Vi tar en väldigt naiv approach till all hantering av missbruk. Det innebär att vi hanterar inte missbruk förrän det uppstår. Så vi gissar inte på hur vi kommer hantera det missbruket förrän vi ser vilken form det tar. Då tar vi beslut på hur vi ska hantera

[01:34:05] Speaker A: det. Så vi kommer alltid ha en viss nivå av missbruk som vi inte har hanterat ännu i systemet. Och till viss del så är det ju positivt. Därför att folk som går in för att hitta metoder att missbruka systemet, de är oftast väldigt energiska och gör väldigt mycket väsen kring sig. Så för oss är det lite positivt om Om någon försöker bjuda

[01:34:31] Speaker A: in massor med användare till ett stort kompisgäng där alla klickar på allas blogginlägg och sådär. Det är ju marknadsföringssaker hos oss också. Då tittar vi på dem lite grann och ser vad de gör. Om vi sätter den här gränsen, hur beter ni er då? Sen jobbar man undan för undan fram till en lösning som passar alla. Som befordrar kvalitet. För det är det som är det yttersta målet. Jag

[01:34:57] Speaker A: vet faktiskt inte vad svaret är. Kommer vi införa ett bestraffningssystem? Det är en uppenbar möjlighet. Har du bjudit in någon som missbrukar så kanske du ska få en bestraffning själv genom att bli av med dina provrating själv eller att det du gör får mycket mindre påverkan på andras arbetsplats. Men det som kommer bli det stora verktyget

[01:35:22] Speaker A: för att befordra för att motverka missbruk, det är att vi kommer låta folk lyssna på de användare som, eller välja ut vilka användare man själv litar på och låta deras, det de gör påverka ens eget sökresultat i mycket större grad än andra människor. Så man

[01:35:47] Speaker A: har en lista på kompisar eller en lista på på personer som har samma intressen som man själv, som man litar på och som använder systemet. Så kommer man kunna lägga in dem i en kompislista och låta deras agerande i systemet påverka

[01:36:12] Speaker A: ens eget sökresultat väldigt mycket. Har de då samma intressen så kommer de hjälpa till att lyfta upp det. Det som är kvalitet är intressant för just mig när jag söker, men inte när du söker för du har andra intressen och andra kompisar. Finns det någon plan på att på något vis ha möjlighet till rena sökningar så att säga? Det vill säga att man inte tar med den här rankingen

[01:36:40] Speaker A: så att säga? Ja, det kan ju finnas det behovet. Så det kan man mycket väl tänka sig. Det är ju en... Det är att vi gör en... Vi kan ju till exempel göra en ren datumranking. Man gör en ranking som är helt enkelt asocial. Eller vad man ska kalla den då. Men i övrigt fungerar det som annat. Sen

[01:37:07] Speaker A: kan man i vårat system... Söka på tomstängd. Vilket innebär i det här fallet, nu har jag ställt in sökfiltern här så att jag får allt på engelska från sista veckan sorterat i datumordning. Ska

[01:37:36] Speaker A: se om jag väljer svenska här. Det är den här oerhört användbara språklistan. Där har vi svenska. Jag vet inte om du som är kockvetare kan hjälpas med den här. Nej, då kan jag väl avbryta så att man inte... Så här får vi alltså... Får vi alltså de... Inlägg

[01:38:03] Speaker A: som svenska inlägg i datumordning. Sista först eller senaste först. Är det någon som är här och ser? Och vi kan också se som jag pratade om. Har

[01:38:32] Speaker A: Primelabs.se länkat till DN.se? En gång? Nej, det har de inte. De bloggar som

[01:38:58] Speaker A: vi umgås väldigt mycket med, det är ingen progress här. De umgås i betydelsen att vi rullar på dem. Får inga resultat. Så här är det. En liten hemlis där, ska man ha alla dokument så måste man lägga till en stjärna på slutet på länken. Det

[01:39:25] Speaker A: är inte helt logiskt, vi ska ta bort det här för nu. Men här får man alltså, kan göra den här saken, kolla på Primelabs. Har vi någon gång läckt ut i din? Nej, vi har inte det. Sen kan man också sitta i hjälpen. Du ska ta blogg.primerlabs. Kanske.

[01:39:51] Speaker A: Jo, kanske det. Med en site. Ja, fast primelabs.se är faktiskt en blogg. Twingly.com är inte en blogg. Med Primers.se. Ser ni? Ja,

[01:40:17] Speaker A: det syns ganska bra. Det här är ett urval av de värden som vi kan ha. Länk och sajt. Blogg. Att vi skiljer på blogg och sajt innebär att blogg.se är en sajt som innehåller väldigt många. Språk, det här är lite unikt också i vårt sökspråk, att skriver man langs kan man

[01:40:42] Speaker A: agera många språk i samma sökning. Man kan söka på tag, vilket till exempel Google språksök inte har. Då kan man både Det finns en och-operator och en eller-operator däremellan. Sen

[01:41:12] Speaker A: kan man söka i det spanska indexet eller inte. Man kan söka på ett bestämt tidsspann. Man kommer också kunna söka på ett specifikt från och till datum. Det är lite skakigt just nu så vi inte dokumenterat den biten. Men det kommer också nästan möjligt. Och när man satt ihop en sökning som man tycker om så är det

[01:41:37] Speaker A: att man tar till exempel alla som vill så skriver de NAC på svenska. Ja, och så ner här. På svenska i datumordning. Det var inte så bra. Sök.

[01:42:04] Speaker A: Där. Det är många som skriver med det där CSN. Om jag vill lyfta in det här på min egen sajt så så finns det ett RSS-fil som man kan använda och lyssna på i RSS-läsaren. Om man vill ha in det på sin sajt så finns det också ett format som heter JSON. Känner ni till JSON?

[01:42:32] Speaker A: Så man kan ta den här sökningen, plugga in i... Ett skript som läser en ISO-string. Här lägger man på en callback som heter foo. Det som händer då är att

[01:42:58] Speaker A: ni ser den här. Det här är ett rent dataformat som lagrar en array av blogginläggsobjekt. Om man lägger på callback foo så wrappas det här helt enkelt i en metod som heter foo. Vilket innebär att när jag lägger

[01:43:25] Speaker A: det i en skripttagg i en vanlig HTML-sida så läser den in det här enkla skriptet. Som för mest innehåll i data, men anropar metoden foo med datat. Som jag definierar metoden foo här uppe så kommer den när stifttagen här nere är laddad

[01:43:50] Speaker A: anropa metoden foo med datat som ingår i datasättet. Och då kan Kan man då få ut samma innehåll här? Ska spara här också så att det blir rätt. Spara.

[01:44:19] Speaker A: Där får vi LOs innehållet. Så på det sättet så kommer man Baserat på Twingly Search så kommer man kunna bygga väldigt enkelt kunna bygga widgets och det är vi som ska hantera spårbarheten i det här fallet. Ni kan åtminstone tills vi bestämmer oss för hur vi ska ta betalt för det.

[01:44:45] Speaker A: Bumma på med hur mycket förfrågningar ni vill och sen så får vi försöka hantera det. Det kommer bli en utmaning. Men som jag sa så har vi redan en lösning för att hantera väldigt stora volymer av trafik. Den använder vi idag för att hantera

[01:45:12] Speaker A: trafiken som vi får från alla tidningar som hämtar data från oss. Det sätt det sker på är att Vi helt enkelt inte tar hand om den här partiken utan vi när vi får in ett blogginlägg så tittar vi i det blogginlägget. Länkar det till någon av de sajterna som använder Twingly? Gör det det så tar vi den tidningsartikeln som det länkar till och

[01:45:38] Speaker A: publicerar ut en ny nytt innehåll för den widgeten. Alltså inte bara den. Plus länken till blogginlägget som har kommit in, utan alla länkar som ska vara publicerade på artikeln. Faktiskt i JSON-format och publicerade till Amazon S3, deras lagringstjänst. Vilket innebär att när tidningen sedan hämtar sitt data

[01:46:03] Speaker A: så ligger både JavaScriptkoden, den här lilla Twingly-logotypen och andra bildstilar som som hör till och själva datat sig ligger på Amazon server som klarar att hantera som lugnt klarar att hantera trafiken av 45 stora mediesajter. Så vi har alltså ingen. Vi

[01:46:30] Speaker A: har in vår belastning beror inte på hur många tidningar som är kopplade till oss, utan bara på hur många blogginlägg vi får in.