Att hantera underliga datum i RSS-strömmar just nu och förberedande inför en mer korrekt framtid

I fortsättning på tidigare publicerat kring spindling efter RSS-strömmar resp. initial inhämtning data där övriga publicerade innan de fyra föregående kan hittas i dessa:

• Resultat spindling efter RSS- och ATOM-strömmar (2014-04-27) [Red. Totala antalet har nu från vid denna tid ca 100 - 200 000 st passerat en miljon och bredare spindling efter strömmar avslutas inom ett par dagar.]
• Några bias från en enkel web spindel (2014-05-04)
• Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död (2014-05-05)
• Avsnitt II: Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död (2014-05-05)

En ganska vanlig idé är att vår tid är begränsad därför att vi föds och dör och att det är viktigt att hinna med väldigt många. Andra menar att det kanske oftare leder till höga kortison (kortison hellre än kortison kan passa bättre givet den medicinska kopplingen oavsett biologiskt snarare än syntetiskt ursprung) med förtidig död och försämrad livskvalitet som resultat.

Lösningen på problemområdet kan ibland vara (vill jag röeslå) att ta sig an något troligt i framtidens historia lagom gigantiskt men medan det genomförs inte överdrivet stressat (när fungerande idellt medan vi alla vet hur det ofta blir det mesta mänskliga). Vi minns ju från skolans undervisning i historia att nästan vad som helst relativt dagens mått mätt rena trivialiteter kan bli del av obligatorisk kunskap när den anses vara del av en gemensam kulturellt grundförståelse snarare än förhoppningsvis att någon tar den icke-vetenskapliga forskningen i dessa ämnen som att tolka ut och driva teser "vetenskapligt" om vad som skett bakåt i tiden med jämförbara krav jämfört vetenskap (hard science) i ämnen likt kemi, fysisk (utanför den "utsvävande teoretiska" som börjar när försök ej kan avgöra om hypoteserna är korrekta d.v.s. tvingande fram metoder tämligen lika ex. historia: från några saker sekundärt noterade i rest-effekt försöka göra en teori trolig eller ännu bättre utan bias söka en god teori).

Men hur förstår vi när något egentligen inträffade i historien? Befann jag mig där och såg det inträffa har det mycket högre trovärdighet än när resultatet av det inträffade själv försöker göra troligt för mig att det inträffade vid en tidpunkt. Betraktar vi detta (ett ex. från en vid varje tidpunkt aldrig helt ovanlig förekomst) ser vi att det försöker påskina att det inträffade i framtiden trots att det uppenbart är felaktigt:

Thu, 04 Sep 2031 0:00:00 CLT___http://www.goreloslagos.cl/resources/downloads/rss_es.xml___http://www.goreloslagos.cl___Noticias - Gore Los Lagos___www.goreloslagos.cl___en_osorno_se_realiz___la_primera_sesi__n_del_consejo_regional_de_los_lagos _TITLE___HH____En Osorno se realizó la primera sesión del Consejo Regional de Los Lagos___GG____URL_STORY___HH____http://www.goreloslagos.cl/sala_prensa/noticias_det/690___GG____DESC___HH____A la cita asistió el subsecretario de Desarrollo Regional, que recogió las sugerencias realizadas por el Consejo Regional.___GG____PUBDATE___HH____Thu, 04 Sep 2031 0:00:00

Det är förövrigt det mest extrema fallet av en serie underliga tidsförskjutningar från samma entitet vilka i ett "stickprov" från de första 900 000 av antagligen cirka 40 - 50 miljoner RSS-strömmar där övriga tänkbart kan innehålla några "senare inträffade" publicerringar.

Men som sagt är det inte helt ovanligt även om det är mycket mer "normalt" att saker inträffar några månader in i framtiden.

Samtidigt gäller åtminstone i min import där jag står just nu (framtida importer hanterar givetvis en del av detta i den mån kontroll om någon månad indikerar det meningsfullt att addera parallella lookup-dimensioner för att göra möjligt att kontrollera) kan inte avgöra om inlägg publicerade ex 2014 fram till idag egentligen publicerades säg 2000 till 2013 men satte datum felaktigt.

Och också om jag filtrerar bort uppenbart rimligt orimliga datum tillåter jag förnärvarande år ganska långt bak i tiden innan RSS var vanligt eller ens förekom. Orsaken är att jag upplevde mig minnas att ett par stora entiteter översatt publicering via annan kanal till RSS med samma aktuella datum och önskar följa upp det när i databas innan ev. radering om ej så eller problemområdet i övrigt tycks betydelsefullt (troligen är det för aktuella år säg från 1999 till cirka 2004 försumbart även om API varken för dem eller ett antal år i framtiden tillåter användning exponerat annat än totalt "dumt" tidsoberoende tillstånd).

Några exempel på år från de första 900 000 som ej tilläts utan gick i filter. Ett ganska uttjatat begrepp i och med betydelsen sociala media när de kan översättas till entitet har för påverkan sökmotorer är domäntrust. Men möjligen givet negativa stereotyper kring "universitet i solen" m.m. kan vi kanske (och kanske vad som när mer import är gjord visar sig varken mer eller mindre korrekt än för andra universitet) tänka oss att detta var mer förväntat för University of Hawaii än för (också universitet i solen faktiskt) Stanford (men IT-iinovativ-marknadsförda Palo Alto vilket tänkbart balanserar sol-slappa stereotyper) eller Harvard närmare den regniga östkusten.

Wed, 01 Jan 1964 00:00:00 GMT___http://scholarspace.manoa.hawaii.edu/feed/rss_2.0/site___http://scholarspace.manoa.hawaii.edu:80___ScholarSpace at University of Hawaii at Manoa___hdl.handle.net___pa1_013 _TITLE___HH____PA1-013___GG____URL_STORY___HH____http://hdl.handle.net/10125/32782___GG____DESC___HH____Box of 942 index cards of plant and animal names, labeled "Marshalls." Given in indigenous languages, English, and Latin. Digital versions provided as tiff, jpg, pdf.___GG____PUBDATE___HH____Wed, 01 Jan 1964 00:00:00 GMT___GG____URL_COMMENT___HH____

"ScholarSpace is an open-access, digital institutional repository for the University of Hawaii at Manoa community. ScholarSpace stores the intellectual works and unique collections of the UH at Manoa academic community and also provides a permanent web location for those accessing these resources. Click here for more information."

http://scholarspace.manoa.hawaii.edu/

Och vi noterar vid manuell-kontroll att aktuell datasamling vid University of Hawaii kan argumenteras handha datum fullt korrekt. Och ett utmärkt (men ej planerat) exempel på entiteter jag ade för mig lade ut väsentligt data med datum i RSS satta utifrån när publicerat förr och ej när publicerat i RSS:

Från: http://scholarspace.manoa.hawaii.edu/handle/10125/32782?show=full

Öar och jämförbart geografiskt i resurser och infrastruktur begränsade entiteter med få möjligheter att ta stabilitet av ett större land är vad jag riktat låtit spindel söka RSS strömmar från publikationer associerade till. De är intressanta att se till att man får med eftersom de av och till kan bli mer flexibla i vad man tillåter för att säkerställa typiskt ekonomiskt stabilitet.

Därav att vi har försvarlig mängd tjänsteleverantör inom "utökad" banksekretess lokaliserade i dessa regioner. Och i all accounting särsklt när ränta ska beräknas eller när AI intelligenser söker transkationer i Swift efter handel med länder under bojkott eller relaterat terrorism (resp. än mer kritiska vid inloggning mot deras nätlösningar) är tidsstämplarna viktiga.

Men knappast verksamhetskritiska i RSS för publicister i regionerna. Jag inaser förövrigt att jag tog fel på ursprunget och att detta nog inte är den "ö-nation" jag fick för mig var aktuell men exemplet kan ha värde ändå om inte annat för att visa upp höjden på min kvalitetskontroll och hur jag vanligen inte irrationellt döljer mina fel för läsaren (det är ju viktigt när ungdomar och yngre vuxna kan tänkas läsa vad man skriver som på nätet att ej glömma att man är ett föredöme - dessutom på plus-sidan sparar jag in tid på att ta bort redan skrivet). Hur som helst är ev. problem snarare än hälsa runt det mentala diskuterade möjligen Alzheimers sjukdom eftersom man nu tror sig befinna sig ett antal år bakåt i tiden:

Wed, 31 Dec 1969 19:00:00 -0500___http://www.countyofperth.on.ca/fileBin/news.xml___http://www.perthcounty.ca___Perth County___www.perthcounty.ca___perth_county_ems_hosts_emergency_workers_mental_health_workshop___heroes_are_human _TITLE___HH____Perth County EMS Hosts Emergency Workers Mental Health Workshop - Heroes Are Human___GG____URL_STORY___HH____ http://www.perthcounty.ca/page/news&iArticle= ___GG____DESC___HH____Perth County EMS Hosts Emergency Workers Mental Health Workshop - Heroes Are Human    Share On Twitter___GG____PUBDATE___HH____Wed, 31 Dec 1969 19:00:00 -0500___GG____URL_COMMENT___HH____

"Welcome!
To the County of Perth
A vibrant, rich agricultural community, diverse in its heritage and culture. The County will strive to efficiently and measurably deliver excellent services and work to strengthen the capacity of the local municipalities that Council represents."

http://www.countyofperth.on.ca/

Sista exemplet är del av en försvarlig mängd inlägg i RSS-strömmen alla "publicerade Wed, 31 Dec 1969 19:00:00".

En till aktör med ett filter-belastande stort antal publikationer 1969. Varav det första (givet året och konceptet "love" inte otroligt något hippi-relaterat kanske inkluderande hasch-knark och naken-dans):

Wed, 31 Dec 1969 16:00:00 -0800___http://www.ppt.org/announcements/index.rss___http://www.ppt.org/announcements___Pittsburgh Public Theater - What's New___www.ppt.org___shaw_s_sparkling_comedy _TITLE___HH____Shaw s Sparkling Comedy___GG____URL_STORY___HH____http://www.ppt.org/pages/shaws-sparkling-comedy___GG____DESC___HH____In this sparkling British comedy directed by Ted Pappas, love and marriage are the targets of George Bernard Shaw s celebrated wit.___GG____PUBDATE___HH____Wed, 31 Dec 1969 16:00:00 -0800___GG____URL_COMMENT___HH____

WELCOME
TO THE PUBLIC!
Welcome to Pittsburgh Public Theater, contemporary theater in the heart of downtown Pittsburgh's Cultural District. With our unique three-quarter thrust stage — the audience surrounds the actors on three sides — The Public offers intimate, engaging, professional theater.

http://www.ppt.org/

En till från årtiondet av riktigt dåliga polis-serier på televisionen. Om det är mer förtroende eller inte att en leverantör av mjukvara var med redan på 1970-talet är en fråga jag upplever kognitiv dissonans runt men just här fick jag för mig att det var en anpassning avsedd att köra på ett Windows kanske från Microsoft vilket mest känns underligt:

Thu, 01 Jan 1970 00:00:00 -0500___http://www.Acrocat.com/rss/en/news_rss.xml___http://www.Acrocat.com/bbs___Acrocat Software Announcements___www.Acrocat.com___acrocat_software_releases_pdabs_3_0_18__windows_ma _TITLE___HH____Acrocat Software releases PDAbs 3.0.18 (Windows/Ma___GG____URL_STORY___HH____http://www.Acrocat.com/bbs/forum_posts.asp?TID=665___GG____DESC___HH____Acrocat Software releases PDAbs [Desktop Component] Build 18 (v3.0.18):Enhancements \ Bug FixesEdit dialog was populating incorrectly. (#35)Manage Clients dialog drop down list updated t___GG____PUBDATE___HH____Thu, 01 Jan 1970 00:00:00 -0500___GG____URL_COMMENT___HH___

Här reflekterade jag kort om det kanske fanns mening i hur datum var angivet? Är det tänkbart att dokumentären gjordes januari 1984 (Diktaturen mellan September 11, 1973 till Mars, 1990)) enligt Wikipedia för ett par konkreta händelser):

Thu, 03 Jan 1974 00:00:00 +0000___http://www.journeyman.tv/rss.php?id=1___http://www.journeyman.tv___Journeyman Pictures :: Documentaries RSS___www.journeyman.tv___inside_pinochet_s_prisons _TITLE___HH____Inside Pinochet s Prisons___GG____URL_STORY___HH____ http://www.journeyman.tv/?lid=8946 ___GG____DESC___HH____Inside Pinochet's Prisons - 30' '' - 3 January 1974___GG____PUBDATE___HH____Thu, 03 Jan 1974 00:00:00 +0000___GG____URL_COMMENT___HH__

Hur hanterar vi det i framtidens filter?

D.v.s. publicerat nu men kommande från framtiden. Antingen p.s.s. som inläggen kan eftersökas databas just nu d.v.s. kontrollera om de förekommer med titel och innehåll redan innan tagit vid tidigare tidpunkt.

En tror jag egentligen mer stabil lösning men mer kostsam än jag just nu ser rimlig är att utgå från att något dyker upp i RSS-ström vid tiden t_i oavsett om t_i är rimlig och innehållet ej noterades i RSS vid tidpunkt t_i-k då orimlig ej innebär att innehållet ej publicerades vid någon annan tidpunkt föregripande t_i.

En nyhet kan exempelvis publiceras 2014-01-01 men ej komma i RSS oavsett samma entitet eller annan förrän senare kanske 2016-01-01. Att spindla nätet vid sidan om detta - eller utnyttja sekundär tjänst för detta i samband med kontroll av tillförlitlighet av entiteter - är en lösning.

Ett mindre krävande mellansteg är att spindla varje URL ett inlägg i RSS pekar ut. Detta är förövrigt mindre krävande än man kan tänka sig därför att en försvarlig del av värdet hämtande data via RSS medför kommer av att man skjuta på utmaningen att parsa html-sidor godtyckligt gjorda medan nedladdningstid resp. svarstid ej är väsentligt (i min erfarenhet) sämre för html utan tvärtom när ej tjänster motsvarande ex. feedburner.com används är ofta RSS långsammare (vilket är logiskt i perspektiv från publicist). Utökad kostnad inhämtning data detta medför behöver därför inte vara avgörande när det görs samlat vid diskreta tidpunkter kanske ett par, tre dagar eller kanske rent av en vecka i taget medan kostnad kvalitetskontroll är noll under antagande att hemsidor aldrig ändras och varje motsvarande nyhet alltid kommer se ut som en gång publicerad eller också förenlat men fungerande för möjligen tillräckligt antal för att göra lösningen rimlig att samma URL kan ses som indikation (i vilket fall vi egentligen inte behöver spindla men upparbetad historik är ju själva saken här om man vill utöka kontroller: kostnaden att spindla ifatt ett gigantiskt antal inlägg är abnorm vid vilken tidpunkt som helst).

Jag minns förövrigt från många år tillbaka i samband med en inkludering i Google News för en publikation ägd av mig att del av kraven där (och antagligen för RSS-strömmar rörande Google i övrigt ex. bloggsökning) är tillgänglighet i båda kanalerna RSS och vanlig HTML för Google-robotarna.

Avsnitt II: Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död

Medan den i antal länkar som hålls i minnet cirka (tror och skattar jag ganska ungefärligt) hundra gånger (eller mer) fortgår utan problem har spindlingen riktad med start från några teknik aktörer dött p.g.a. indikerat brist på minne. Ev. en slump när några andra trådar tog upp ordentligt vid uppstart (om den allkerar samtidigt har jag fått för mig att de för åtminstne Perl-pgorammen troligare dödas) eller som jag gissar här därför att de laddat ner exe-filer som petat runt med mängden data ej skrivet till filen i för snabb takt i samband med annars minnesbrist vid uppstart konkurrerande trådar.

Eftersom diskuterat i Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död komprimerade jag samman de första två filerna (ev. saknas den för tredje-epoken men ids inte titta exakt när filehandles skapas om för ny fil: om saknad ändrar jag troligen det hela något för att minska risken för att tappa tydligt: erfarenheten allmänt från hur Perl fungerar på min konfiguration Ubuntu är att mindre data än aktuellt här sparas mellan samtidigt är jag riktigt nöjd med hur hela domänen av minne vs. disk fungerat här på Windows 7 just för spindlingen så jag klagar absolut inte: verkligen över allt jag hade förväntat mig):

• https://drive.google.com/file/d/0B5IBnalBS0bxRHBxanBWeVNCbjg/edit?usp=sharing

Relaterat Ericsson var illustrerande vad diskuterat (men mer illustrerande än jag förväntat mig egentligen givet stort företag och ändå ett ganska försvarligt stort antal publicister relaterat teknik spindlade) fanns ytterst få länkar till Ericsson. Ex. från de tre entiteter jag såg vid manuell sökning i Emacs var:

http://pinterest.com/ericssonpins/a-history-of-communication/

www.lightreading.com/
http://www.lightreading.com/mobile/ericsson-appoints-chief-strategy-officer/d/d-id/708861

t.co/
http://www.ericsson.com

lemonodor.com/
http://the.taoofmac.com/space/SonyEricsson/T610

Oavsett i mening av närmare externa redaktionella avtryck resp. engagemang att se till att man finns med i kanaler där företag själva talar, berättar och visualiserar sig är det relativt vad jag uppfattar som normalt dåligt avvikande. Oavsett innehållet eller kanalen i sig kan det dessutom ge en känsla av att internet känns lite nytt för Ericsson och man inte riktigt märkt mycket av det vilket knappast är riktigt utan att det just blir bättre av det. Kompletterande följande korta reflektion:

"Föreställning att det ej spelar roll tror jag är felaktigt. Jag kan tänka mig att en del äldre koncept hade kunnat kvarstå framgångsrika om områden som dessa fungerar bättre. Vidare även om man riktar in sig på större affärskunder i långsamma affärer kännetecknas ju dessa just av att vara mycket kompetens-drivna rörande allt relaterat att passa in tekniska koncept i dom egna lösningarna. Att etablera synlighet för hela området för tekniska standarder, inriktningar m.m. närmare det egna tänket bör tror jag sett över en längre tid löna sig oerhört. P.s.s. för färskare konkurrerande företag kan samma synlighet löna sig ordentligt mycket mer därför att för dem finns mindre av upparbetad befintlig kunskap om de egna lösningar hos potentiella kunder. Däremed gäller eftersom mängden uppmärksamhet en befintlig kund eller prospektiv kund är begränsad att det är viktigt oavsett välkänd aktör eller ny aktör att etablera synlighet också för att inte lämna det itll andra att ockupera. Dessutom är det i kostnad så billigt att det bara är löjligt att inte göra det ordentligt. "

Från: Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död

Kan vi tänka på något längre sikt än så och som av och till noterat här (bl.a. Är GSM värt mycket mer i framtid än vi kanske tror? Och krigiskt? (2014-01-30) och Mobila WLAN för frihet & Europeisk impotens från självstympning (2012-02-16)) uppmärksamma att priserna relaterat att etablera nätverk oavsett typ reduceras och att det inte är självklart oavsett hur stabil affär mobil- och fast-telefoni-operatörer resp. deras leverantörer har att affärer närmare konsumenterna (ex. mindre aktörer) kanske blir fortsatt vanligare och i fler teknik-domäner.

T.co har förövrigt varit ytterst vanlig allmänt. Och precis som jag gissade (jag tar ingen olämplig stolthet i att jag inte behöver följa nyheter om sociala media tjänster för att känna igenom url-förkortning även om jag inte riktigt begriper varför det ska förkortas istället för att sätta en ankar-text på länken ex. men med samma "egenhet" kvar förkortad url som ankar-text och riktig url som länk så att man kan se var man kommer genom att hålla muspekaren över länken eller kopiera ut den) var det tjänst för att korta ner URL. Och det förenklar kanske med en dominerande tjänst associerad en av de största aktörer där förkortade url:er praktiskt regelmässigt används: Twitter.

Referensen o Spindlande Ericsson konkurrerande konkurrenter: Att indirekt indikera nätets "riktigare" kunskap och kultur istället för att upplevas död till ett konto sociala media som togs upp för Ericsson var korrekt Twitter:

www.ericsson.com/
http://www.ericsson.com/news?tagsFilter=ICT+industry

www.ericsson.com/
http://www.ericsson.com/news?tagsFilter=consumers

twitter.com/
http://twitter.com/EricssonTV/status/461988780707438592

Givetvis är det inget fel på Twitter. Men en erfarenhet från spindlingen senaste veckor är att Tumblr uttrycker något av den betydande smyg-etablering Flickr gjorde under flera år tills man någon gång 2007 - 2009 kanske började inse att det hela var på väg att bli riktigt stort. En viss elegant existens utan den annars ibland lite överuttryckande behovet av att berätta om betydelsen av existensen och hur riktigt stor man blivit (det elegantare är självklart enklare för en entitet likt Yahoo som ej har ett socialt media som Tumblr mer singulärt: men det kan också vara relaterat mer allmänna tankar om varumärken relativt tid).

För loggar (likt filerna ovan) från idag och igår och totalt 14 325 991 (plus några stycken till eftersom totala antalet efter sista filen ej skrevs ut - jag programmerade fel - men ungefär säg 15 miljoner) länkar fördelades länkar till tre stycken sociala media jag fått för mig liknar varandra i tänk (kortare text och möjlighet att uttrycka relation till entiteter man vill läsa eller mer social länkning / följande / gillande) resp. Stumbleupon:

Twitter	91 576
Facebook	61 087
Tumblr	56 112
Stumbleupon	1453

Resp. sorts motsvarighet i det rent länk-spam-funktionella tog jag ej ut något av men också där skiljer motsvarighet till Stumbleupon ut sig något med auto-surfande funktioner eller nätverk där besök delas (eller att besöks köps rätt av för att försöka öka annonsvisning). Jag sökte här eftersom RSS-strömmar egentligen endast söktes ej filtrera bort dem och såg det ev. som användbart att ha en dump för enklaste tänkbara mönster oavsett spam, reklam eller affility-relationer. I någon mening är en refererad bok representerade värde därför att den uppskattades (kanske länkande Wikipedia eller lika gärna Amazon) eller en bok länkad via affility-länk intressant från ett värde-perspektiv även om "valutan" inte är den samma (dock är det önskvärt att förstå vilken valuta som värde indikeras via eller nära relaterat).

En tolkning är att entiteter utanför individer - företag, organisatioer m.m. - fortsatt så länge resp. är aktiv för de tre första med jämförbar funktion kommer konvergera antalen. När använda bland individer d.v.s. läsare, personer man vill ha kanaler mot o.s.v. är det vettigare att existera i resp. Det kommer ju inte med någon merkostnad. Jämför med Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist för Vita husets utlokaliseringar:

"Vidare för att ge ett exempel motsvarande vad som noterades särskilt relaterat SEO föregående motsvarar mitt gamla koncept (från säg 2006) om ambassader i sociala media eller vilka som helst samhällen på nätet bundna till en nod vi enkelt kan särskilja (d.v.s. typiskt minst ett domännamn och ibland pået mindre grupper). Vi kan ex. se hur Vita huset (kanske också för rättvisa mot olika ofta amerikanska företag) lokaliserar sig i ganska många motsvarigheter samhällen.

Motsvarande företag p.s.s. ger det möjlighet att möta samhället där de oftast här och ofta nog viktigare praktiskt finns relaterat innehåll när samhället söker det lokalt eller reagerar och uttrycker om företaget, organisation o.s.v. En inarbetad väg att tala lokalt vid behöv. Skillnaden relevant här som ex. finns där mellan default-publiceringen t.ex. samma filmklipp på resp. video-social-media-sajt (Youtube, Vimeo och jämförbart) resp. när reaktionen är riktad eller en meningsfull reaktion lokalt. Och för default-publicering om denna är direkt associerad till samma entitet eller uttrycks för ett antal olika entiteter där det senare kan indikera bl.a. "spam", behov av anonym publicering andra orsaker, eller något viralt."

I kontrast tycks åtminstone Nokia, BBC och Unesco ockupera internet-area österut (Ukraina m.fl. länder...):

www.nokia.com/
http://vk.com/nokiaukraina

www.unesco.org/
http://vk.com/unesco

Respektive finns bredare än så inkl. för Unesco följade (för att ge ytterligare några exempel):

www.unesco.org/
http://itunes.apple.com/us/institution/unesco-united-nations-educational/id435087097

www.unesco.org/
http://www.youtube.com/unesco

www.unesco.org/
http://www.weibo.com/unesco

www.unesco.org/
http://www.linkedin.com/company/unesco

Kanske hemvant för Nokia, Ericsson och Siemens m.fl. är att se kanalen sociala media. Men kanske mer funktionellt för innehållet kan vara att inte göra det svårare än att tänka telefonbok med skillnaden att man betalar för större annons genom att själv medverka till att folk hittar fram på resp. sajt (d.v.s. som normalt numera länka till dem från egen sida m.fl. uttrycksformer på nätet).

Jag hade hur som helst innan knappt märkt Tumblr (men har inte följt nyheter kring upplevt nytt i ämnet på ett tag): Men det är riktigt stort och det är stort hos entiteter som gärna vill finnas men är lite mer försiktiga vilka kanaler man väljer. De märks mycket bland medier, universitet, politiska entiteter m.m. (där givetvis kanske mer välkända Facebook, Twitter m.fl. också existerar inte sällan samtidigt) samtidigt såg att Wikipedia refererade källor som menade att kanske inte det gedigna kompetens-drivna eller ordnat vardags-relaterade innehåll vi lärt oss att förvänta på Twitter alltid är fallet (en grov gissning betraktande ungefär vad jag sett från perspektivet spindlande är det antagligen inte sämre än Twitter och mycket möjligt kanske lite seriösara även om jag knaske har tolknings-bias från att faktiskt använt Twitter mycket mer).

Några bias från en enkel web spindel

Låt mig här ta "erfarenheten" från Resultat spindling efter RSS- och ATOM-strömmar och vända på det enligt:

• "Egenheter" p.g.a. att det är enklare som ger bias hur sajt (i mening sammanhållen entitet oavsett subdomäner, "ambassader" på twitter) m.m. spindlas.
• Hur jag gärna vill se ambassader uttryckta i mening av stöd från Youtube, Twitter o.s.v. utan att ännu tittat hur de gjort det.

Rörande det först gäller givetvis att desto centralare och mer långsiktig kod för en spindel är desto bättre hanterar den analys av sida utan att förfalla till många av de bias jag tog med här. Aktuell spindel här är tämlingen ung (ev. "fortfarande") även om den blev lätt mer begåvad än från början tänkt p.g.a. en del utmaningar jag inte räknat med. Syftet här var endast:

• Identifiera ev. RSS-ström indikerad på sida som laddats ner. Om identifierad sparas den alltid ner tillsammans med sida där den hittades.
• Ev. länkar till andra sidor vilka som helst. Dessa för att ge nya sidor att senare titta på för att hitta RSS-strömmar. Ingen skillnad görs mellan samma sajt eller andra.

Bias I: Ordning på länkar

Just nu ligger cirka 500 - 600 miljoner länkar totalt identifierade. Samtidigt är det av och till mycket önskvärt att prioritera spindling mot något särskilt område eller sajt jag bedömer som viktig (eller p.g.a. tidigare fallstudier eller beräkningar som gjors av och till på dem för att följa förändringar i logik) att spindlas fritt direkt oavsett vilka länkar som nu finns identifierade.

Dels kan det göras med samma system som i övrigt men beskriva preferenser för sajt utifrån url. Praktiskt har jag dock vanligen gjort det genom att ge spindel riktad seed för ett antal sidor och sedan låtit samma tråd spindla dessa och fortsätta själv på samtliga identifierade länkar utan kontroll av om de spindlats tidigare. Medan spindel i övrigt vanligen ej spindlar samma domän mer än en eller ett fåtal gånger oavsett antal länkar sätter jag ofta här gränsvärdet för när en given sajt ej accepteras högt. Ex. lät jag precis spindla igenom stora delar av The Guardian därför att de har RSS-strömmar ämnes-uttryckande utspridda över hela sajten.

Siffrorna under resp. länk anger för siffra höger om domänen antal gånger domänen besöks, samt direkt under antal tecken i hämtat data för aktuell sida (antalet sju är dock oftast en felkod bestående av sju stycken underscore) resp. för den rad med två siffror separerade med tab: antal länkar identifierade resp. antal strömmar identifierade.

Arbetande per epok inkluderande alla identifierade länkar som ej överstiger tröskelvärde för domänen. Här i epok tre med totalt cirka 40 000 länkar att gå igenom. Minns jag rätt hade epok två cirka 400 och epok ett inkluderande de sidor jag gav manuellt som utgångspunkt (cirka 10 st och samt på det adderande exakt 27 st.). Tillväxt som funktion av epok (när y-axeln ger summan sidor upp till och inkluderande epok) - och allmänt för större sajter (men ej 100% säkert så stora att jag ej spindlat större delarna men upp till sajter av Orble.com storlek) - ger inlärningskurvan: trögare tillväxt första epokerna, därefter explosiv, och lugnare ökning längre fram.

---

Komplettering Epok fyra en stund senare. Expansion till cirka 400 000 länkar.

Sajter ej The Guardian kan har antingen vara länkade från dem under tidigare epoker eller länkade från ej sajt de initialt länkade under en tidigare epok.

---

Av detta ges flera bias. Först och främst gäller att den länk som först spindlas kommer donera där identifierade länkar först till tabell. Ordningen dessa spindlas är ej i exakt samma ordning (utan har mer att göra med Perls hash-funktion) men samma bias existerar fortfarande indirekt mellan och över epoker. Hinner gränsvärde nås ges dispergens mot övriga. Tänkbart generellt bland enklare robotar tidiga länkar på sida resp. länkar vi sannolikt snabbare möter via sidor vi kan tänkas nå den via.

Bias II: Enkel regel-logik

Att sätta gränsvärde per domän är ganska enkelt att göra. Klokare är självklart att hantera själva den gemensamma domänen hellre än som jag gjorde separerande resp. subdomän (eller för den delen betraktande självklara "alias" som ofta ex. www.något-exempel.se resp. något-exepel.se som samma).

Jag tycker mig från längre tillbaka - flera år bakåt - minnas ett för en branschledande sökmotor ev. något besläktat ex. som fick viss uppmärksamhet relaterat sushi restauranger i Sverige placerade på sajt (jag tror det var www.sushikartan.se). Sedan några år tycks för mig att Google försöker se entitet gemensam eller uttryckande ett stycke innehåll (det senare återvänder vi möjligen till i avsnitt önskat från sociala media sajter) d.v.s. ej självklart behandlande subdomäner annorlunda i mening av inverkan med andra subdomäner (men ej heller självklart så utan också möjligt behandlande dem som separerade representerande olika entieter - spekulativt ex. för de flesta men kanske inte riktigt alla subdomäner på tumblr.com och wordpress.com).

Vidare för att separera "sidor" ämnesuttryckande resp. nyheter just på The Guardian filtrerade jag kastande på sidor vars url innehöll följande eller jämförbart /2013/, /2013/, /2012/ o.s.v. Det fungerade ganska bra just där.

Bias III: Enkel tillförlitlig leverans av fler datakällor

Av de sorters sajter jag enkelt kan beskriva att söka RSS-strömmar för från mängden identifierade länkar är bloggar på Google Blogger och Wordpress.com i särklass levererande i antal relativt tid spindlande dem (särskilt Blogger är brutal: möjligen finns någon orsak till det att söka hur Blogger visar upp sajterna - kanske deras gemensamma grunka överst men jag har inte kontrollerat det) medan Typepad.com levererar mycket mindre och inte just lönt att göra som egen tråd.

Just handräknande väldigt inexakt ett stycke bakåt verkar cirka en stycken typepad.com ges per tio wordpress.org.

Detta medför ett bias i vad jag väljer att prioritera mer av. Särskilt som både Blogger (Google's tjänster för att leverera RSS ut mer generellt) är mycket snabbt och det samma gäller tycks det också Wordpress jämfört med många andra sajter med egna domäner (men antagligen verkar det för mig utan exakt mätning inte lika snabb som Googles hämtningspunkter).

Bias IV: Spindlings-levererande intern-länkning

En del universitet harjag märkt är brutala på att ständigt expandera under DRILL-spindling mot egna associerade subdomäner, andra domäner, och ut från det sajter relaterade staden och liknande runt om kring. Konkurrerande andra kan de ta större delen av utrymmet. Minns jag rätt var ett exempel utanför USA University of Toronto medan ett omvänt exempel på sajt jag fick hjälpa upp med fler initiala seed-sidor Uppsala Universitet. Med cirka fem till tio extra sidor var UU egentligen inte så dålig i hur man tänkt relaterat innehåll resp. uppdelning eget innehåll (ex. bibliotek, botaniska trädgården, informationssidor m.m. intressant för att förstärka sitt eget värde genom att visa upp stadens värde).

Liknande för ett antal större amerikanska universitet är det mycket lättare när fritt spindlande dem från ett fåtal utgångspunkter (även forsknings-nära) att få en hög andel sidor relaterat att anmäla sig m.m. relevant prospekterande studenter snarare än som optimalt för mig hellre mer undan gömda bloggar eller sidor med pressmeddelanden för avgränsade forskningsområden. Möjligt har det sin orsak i att för affären studenter relativt affären forskning är internet mycket viktigare för den första.

En mer begåvad spindel bör hantera en hel del här enklare. Samtidigt ska man vara klar över att en kostnad att direkt under spindling bibehålla och göra tillgängligt fullständigt tillstånd och upparbetad information för resp. existerar. Det är ej ett olösligt problem men det är enklare mer effektivt när resurser oavsett utveckling, hårdvara eller hur tillgång till vad som körs på hårdvara i form av kataloger, databaser m.m. är begränsade att separera spindling och ta in data där uppsamlat till varaktiga tillstånd i batch-import. D.v.s. det är kanske klokt att inte överskatta hur dum ett robot kan vara. Jämför gärna besläktat runt lösningen diskuterad i:

• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier
• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist

Desto mer av tillstånd nere i spindel ju bättre i mening effektiv behöver den vara i en till domän. Kostnad reducerad hastighet spindlande ska vägas mot vad man vinner genom att spindla effektivare och där ligger förutom mer direkt relaterat lösningarna i best-practise också utvecklingstid.

Önskvärda egenskaper sociala media

I domän av sociala media har jag mycket positiv erfarenhet av att spindla på från länkat via andra sajter in i facebook.com resp. flickr.com.

Även Youtube är snabb, fungerande och levererar ofta förvånande mängd riktigt data (d.v.s. skriven text snarare än filmklipp vilket inte just nu primärt intresserar mig för strömmarna). Eftersom Youtube är ganska tung att komma fel inpå och målsättning närmast är att undvika spindla den för att istället använda RSS-strömmarna (via data.youtube.com) införde jag följande enkla krav på de länkar att spindal som accepteras:

if (

( index(lc($url),"youtube.com") != -1 ) &&

( index(lc($url),"/user/") == -1 )

)

{

return 0;

}

Regeln är inte utvärderad med den noggranhet önskvärd där eller för motsvarande andra sociala media (något för veckorna framöver beroende på prioritering mellan sociala media och bloggar rörande en del data önskvärt från strömmarna) men syftet är att:

• Primärt söka en enskild entitet - d.v.s. ej entitet Youtube utan entitet användares - centrala punkt på sajten.
• Denna punkt önskar vi helst kunna se lika tydligt som för en egen domän.

Först och främst är det därför önskvärt att sociala media uttrycker dessa så att de går att särskilja. Utan att nu tittat egentligen på någon relaterat detta bedömer jag att det normalt är möjligt för åtminstone nästan alla. Viss information är trevligt om den finns:

• Möjlighet för entitet att uttrycka viss personlig information i form av associerade punkter på nätet. D.v.s. om man önskar kasta entiteter som det ej är uttryckt för.
• De viktigaste RSS-strömmarna (om alls aktuellt) personliga för entitet. Ex. motsvarande tweets eller blogg-inlägg och likes (och varför inte globalt alla kommentarer gjorda, kommenterarer levererade av andra på inlägg, likes m.m.) o.s.v.

För forum var det vanligt att ge sammanfattande uppgifter om ålder på sajt, antal inlägg m.m. Jag vet inte hur vanligt det är på sociala media enkelt att ta ut direkt. Det är för mig mindre viktigt än punkterna ovan och spekulativt tror jag att åtminstone många av de stora sociala media har mycket av vad jag önskade. Det underlättar ju både för dem själva såväl som viktiga stora externa aktörer att tidseffektivt hantera meta-tjänster ovanför kärn-funktionalitet (ex. sökning och vägar för användarna att ansluta till sajten via RSS).

NoSQL med Rebel-AS: Berkeley DB prestanda optimerat i två kraftfullt enkla steg

Sammanfattat: 1. För-sortera (design pattern sort) stora chunk och 2. Stoppa in. Men glöm inte att stoppa in det sista datat.

Tidigare har jag haft stora problem Berkeley DB i att skapande av databaserna vid resp. 80 MB mängd databas gjord kom en stor tidskostnad. Längre ut kunde det i princip gå hur länge som helst. Av den orsaken hade jag tänkt ersätta det med något färdigt mer paketerat inkluderande mer av färdiga funktioner för dimensioner m.m. Men standardprodukter kommer ju med viss kostnad inlärning, legacy och för ex. MongoDB jag lutade åt att jag ogärna just nu vill installera om utvecklings-server från 32-bitar Ubuntu till 64-bitar (med 32-bitar är MongoDB ej meningsfull relativt vanliga hash-tabeller inlästa från fil därför att datat är väldigt litet).

Varför brytpunkt ligger där vet jag inte. Ev. är det just relaterat 32-bitars adressering i OS (jag har fått för mig att både den Berkeley DB jag använder, MongoDB m.m. alla normalt ej gör något mer underliggande eller långt ner i OS nära disk eller adressering utan använder ett färdigt anrop för stora filer att adressera likt minne i Linux). Det stämmer i alla fall ungefär i magnitud:

2³² (82 * 1024 * 1024) ~ 49.951

Men har alltid prövat det på samma filsystem (ej prövat det på mitt Ext3 - eller om det är Ext4 - jag prövar eller formaterat för att pröva i alla fall som tänkbart just för disk där NoSQL databaserna ska ligga längre fram: givet bl.a. ingen checksum m.m. passande för databaser där ej tänkt att ändras kontinuerligt och i behov av god prestanda relativt begränsad hårdvara - osäker om det gör praktiskt kommer göra märkbar skillnad eftersom jag egentligen aldrig varit i närheten av storleks-magnitud totalt data som kommer behöva hämtas kontinuerligt men anar att det kanske gör skillnad).

I Rebel-AS jag döpte en fortsatt egen legacy NoSQL jag byggt ovanpå just Berkeley DB har jag samma fördröjning som funktion av cirka 80 MB nedsläppt. Men nu mycket snabbt skapande av databasen. Ett natal GB med inlägg från bloggar och sociala media för fortsatt analys handlar om ett fåtal timmar eller kortare tid (satt ej och tog tid på det framför datorn).

Berkeley DB snabbt: Sätt dig ner och sortera nycklarna åt datan (likt programmera: människa gör det kostsamma - datan gör egentligen föga)

Och hela skillnaden i prestanda ligger i vad jag trots av och till utdragna - säg fyra timmar totalt - försök att hitta en förklaring och lösning ej hittade alls. Förutom mer av slump slutligen i en kort kommentar till en fråga svår-hittad både nu och tidigare (möjlig utgångspunkt: Berkeley DB Slow via sajt-sökning med Google).

I övrigt läsande på Stack overflow fick jag ut föga värde. De flesta verkar heller inte göra särskilt stora databaser. Exakt vad orsaken är eller varför det ev. är god vana vet jag inte. Databaser har aldrig särskilt intresserat mig och ingenting jag direkt önskar att lära något mer än nödvändigt om. Jag hade snarare föreställt mig att det logiska vore att om distans eller skillnad mellan nycklar som går in pre-expanderar man motsvarande fil mycket mer för att slippa flytta om datat senare alt. slippa hantera kollisioner via redundant för träffar nycklar eller pekare vidare till annan position.

Hans reflekterar vad han redan lärt och slutade lära cirka 2003 rörande databaser och tyckte sig inse att det räckte bra nog ändå: Datan gör ungefär samma fel varje år även om skärmen blivit skarpare och hårddisken större

Det är när jag spekulerar kreativt utåt bra att komma ihåg att min vetskap databaser snarare än hash-funktioner, kataloger (typ Open LDAP) eller för evigheter sedan fil-databaser via radnummer respektive:

LIST RANDNUMMER

på Commodore 64 någon gång i årskurs fyra när datorernas sanna små-defekta natur inte doldes lika smygande riskfyllt som idag: Ex. databas genom att lista "programkod" - lika gärna text eller annat data så länge man inte kör koden som BASIC II. Istället listade man programmet - eller en del av programmet där datat fanns men som ej kördes just för dom raderna. Ex. LIST 3210 - 40000. LIST liknar hemvant trevliga goto men var sundare strukturerat genom att utnyttja entydiga nummer istället för dom kvalitetsprobglematiska labels vi säkert alla gärna förfaller till likt abc, donxt, do_next en bit nedanför med svårbegriplig beräkning mellan förändrande värde, odd_erorr, debug_but_do_not_remove_it m.m.) syntax för att ta ut en datapost från dess början på rad enligt första numret till dess slut på den andra siffran - plus så klart för stora databaser behov av att ladda in grupper av poster från olika delar på kassetband utiliserande s.k. "spolning" / "att spola fram eller bak bandet§" - eller rent av krävande många kassetband) är så begränsad men dessa tre tillsammans gav mig en känsla av att jag sådant som Berkeley DB borde vara begripligt för mig. LIST är heller inte olikt hur många idag gör lookup från indikation vi vill fråga med (ex. URL eller sökord) till radnummer i enorm fil där själva datat för sökord eller URL ligger lagrat (och så klart snabbare i absolut-mening idag jämfört med C64 men inte mycket högre relativ prestanda).

Stora nycklar en aning mer kostnad ibland för-sortera men ev. högre prestanda skapande databas

Något besläktat - kanske relaterat implementation på vad - ges här också StackOverflow: BerkeleyDB - implications of incorrect sorting order? (via cache-Google: ibland når jag ej StackOverflow vilket jag trodde berodde på att jag råkat spindla deras kategorier hårdare än korrekt programmerat för statitistiskt analys av inlägg men ganska ofta fungerar den så ev. relaterat någon defekt på Stackoverflow kanske relaterat last så jag länkar indirekt istället och tror ej det tolkas av spindlande entiteter som problem prestanda eller tillförlitlighet med sajt länkad). Om det egentligen stämmer som skrivet ofta eller alls vet jag inte.

Vad jag märkt är emellertid att ingen kostnad för mig existerar av att använda större nycklear (undantaget ev. ökad risk för kollisioner och hantering av det: men jag vågar gissa att vettig hash-funktion används och om så troligt föga problem). Och längre nycklar om en mappning mellan nyckel och position (snarare än jag hade föreställt mig motsvarande MD5 - jag vill gissa att föregripande lookup-up till värden från nyckel finns och att hasching kanske ej görs till en redundans-reducerad form som för MD5) finns motsvarande "komplexiteten summerad" nyckel innebär det ju mer exakt vetskap om relativ positionering. D.v.s. kommer fler entiteter gå in och vi tar in dem i chunk vettigt urtagna innan sorterade föreställer jag mig att det kanske tvingar upp lite vettigare initial hantering föreberedande för att mycket kommer in. Jämför att sortera:

AAAAAB AABAAA br/> resp br/> AAAAAABAAAABBBBAAAA AAABAAABAAAABBBBAAAA Eller motsvarande mina nycklar datum och tid publicering, länk indikerad övergripande RSS eller ATOM "sajt", domän uttagen över inläggen för resp. länk till inlägg (d.v.s. kan vara annan än sajt), titel på sajt indikerad, titel inlägg, resp. hela sökväg feed där data hämtades (ej exakt i samma ordning mot mitten ev. samt inkluderande en till indikation om källa i URL-mening). Poängen längd ligger i att gå över alla nycklar utan hänsyn dimensioner för annan lookup för enklare förändringar, kontroller m.m. där allt nödvändigt för mycket finns direkt för varje nyckel (ex. för en del underhåll kontrollera om ett datum finns eller ex. som nyligen defekt-data ej önskat som läckte in: <![ eller liknande ibland förekommande i RSS-strömmar ev. för "sekundärt" data-relaterat innehåll (just här för sajt-länken för ganska många vilket missades vid skapandet).

I en värld där resp. två nycklar för de två grupperna egentligen motsvarar samma nycklar men där de första kommer ge fler kollisioner tvingande fram att append görs för resp. om plats finns, och när plats lokalt i filen där lagring redan skett saknas tvinga fram en pekare till nytt data allokerat på disken eller värre (ej kanske otroligt givet prestanda kostnaden jag fick tidigare) att data flyttas om ständigt görande att en ny växande jätte-fil behöver lagras gång på gång för varje 80 MB med exponentiellt växande tid för det eftersom komplexiteten att göra det ökar när resp. omflyttning kan inverka på nästa omflyttning. Om nu den Berkeley DB implementation jag fick via Perl (eller om den ligger ovanpå något i Linux) är riktigt dum kodad (elegansen i Berkeley DB är ju att det är enklaste tänkbara så mycket möjligt förväntas förståelse och ansvar hantering liggan ovanpå).

Tänkbart faktiskt en tids-kulturell-atavistisk företeelse. Berkeley DB har ju funnits så pass länge att problemen och utmaningarna när etablerad var mycket annorlunda: RAM-minne relativt litet (men kanske problem-baserat jämförbart) men förr var hårddiskar som nu inte mer eller mindre kostnadsfria om man inte behöver lägga på mer än några tera byte. Ev. lite default optimerad för att ej börja med att skapa en rimligt tilltagen fil (kanske konfigurerbart men jag såg det ej via Perl gränssnitt i DB FILE och utan att kontrollera konfigurations-loggar vet jag ej om jag installerade på något kompletterande).

Appendix A: Design pattern sortera nycklar i två enkla steg

Pre Berkeley DB power sorting:

1. Ta ut nycklar från mellan-lagring i Perl's vanliga hash-tabell. Exempel:

my @keys = keys %ldb

2. Sortera nycklarna. Exempel:

@keys = sort @keys;

Och stoppa in i Berkeley DB via lämpligt för det. Glöm inte att synkronisera mellan-lagrat data i sista steget. Vi antar att vi stoppar när överskridande viss storlek med målsättning att söka göra det med så stora chunk i taget som möjligt för att inte Berkeley DB ska allokera onödigt små-utrymmen i varje steg givet att om inte allt data redan är sorterat gäller att en del omflyttningar eller vad Berkeley DB nu gör behöva ske. För mig cirka 900 000 blogginlägg med RSS-meta översatt till trevlig CSV-fil (som vi i en rimlig värld hade haft direkt på webbsidan istället för SGML-rekursionens onödiga komplexitet praktiskt oavsett hur elegant språkteoretiskt). EFtersom blogginlägg kan komma från entiteter vid en tidpunkt efterföljande vad vi stoppar in idag okänd gäller att inlägg vi ska stoppa in ofta nog i perioder när tidskostnaden kan ha betydelse (d.v.s. spindlande ifatt internet där jag just nu ett tag expanderar antalet entiteter publicerande med cirka 50 000 till 100 000 per 24 - 36 timmar men räknar med att stoppa det om en eller ett par veckor) vara äldre och ej följande logisk ordning i övrigt samtidigt som jag tyckte det mindre tilltalande att försöka lägga till en bokstavsräknare initialt eftersom jag gärna vill kunna ta ut alla nycklar optimerat i meningsfull ordning att se ungefär var saker befinner sig i tiden vid underhåll o.s.v. via snabbtitt skärm.

Betryggande nog när vi står kvar på en robust gammal välkänd komonent är den välanvänd av andra gamla lösningar man känner igenom sedan snart 20 år. Ett fåtal från Wikipedias längre lista:

"MySQL database system – Prior to v5.1, MySQL included a BDB data storage backend.
OpenLDAP – A free/open source implementation of the Lightweight Directory Access Protocol (LDAP)
Postfix – A fast, secure, easy-to-administer MTA for Linux/Unix systems"

Även om det får erkännas att min lilla praktiska erfarenhet av MySQL och Postfix var en brutalt plågsamt fascinerande verklighet: Så slött saker kan bli med eller utan på det Apache resp. karttjänster ovanför. Men OpenLDAP är ju bra även om det var ett antal år sedan jag gjorde något med den. Och menar - det kan kanske diskuteras - Wikipedia dessutom något färskare news-fresh:

"Bitcoin - A distributed peer-to-peer open source digital currency."

Fortfarande lite små-coolt att skapa stabila stengolv med Berkeley DB hellre än något vulgärt IKEA-färdigt golv som limmas eller nitas. Riktiga värden som håller många år byggs med stenhacka och förståelse av problemen man vill lösa med att bygga golv.

Tidigare från samma domän av stegvis kreativt skapande för undvikka samma välkända strunt-problem i datan nu som på 1980-talet

Som Rebel-AS levererar sin lösning till:

1. Steg I: Behovet av praktisk big-data utan mina enkla ganska brutala ta in och ut ur minnet läsande data uppdelat i mindre filer resp. den gamla Berkeley DB lösningen där ingen databas praktiskt gick att ta större än 80 MB (d.v.s. samma problem praktiskt ungefär: många fil-accesser, opraktiskt att strukturera, och ordentligt med extra-logik i koden). Men eftersom vi är i domän av databaser blir det ändå segt eftersom jag varken kan eller vill lära mig teorin för dem. Varande så inarbetat sedan år borde det tycker man bara fungera.... Likt hash-funktionen i Perl.

• NoSQL och Sun's och övriga hårdvaru-inriktades problem att orka med dom teoretiska utmaningarna vi alla behövt sedan år (2013-09-02)

Plattform jag reflekterade som tänkbar lösning: Mongodb.org. Huvudsakligen därför att den av flera indikerades snabb och endast i föga läsande dokumentationen verkade ha "överdrivna databas" relaterade funktioner: enkel och begriplig närmare hash-funktioner jag ju redan tycker mig kunna. Mindre risk onyttig inlärning. Och startade smidigt dessutom. Men hade fodrat ny installation Ubuntu om praktiskt funktionell vilket just nu ett tag är opraktiskt på utvecklingsservern.

Och diverse små-tester, läsande m.m. resulterar slutligen i att jag väljer samma teknik-plattform som tidigare förutom att skärande cash-logiken för parallell också utan Berkeley DB (användes uteslutande för similarity beräkningar mellan koncept där cirka 900 MB - 2 GB förberäknade värden fanns mellan koncept vars similarity oftare var efterfrågade eller förväntades vara det: dessa tar annars upp till för värsta tänkbara om gjord med hög exakthet närmare 20 minuter - och för aktuell version Blue light gällande i denna lösning fanns cirka om jag minns rätt 10 miljoner relationer bedömda troliga över cirka 140 000 existerande koncept jämfört med nu några miljoner koncept och ett okänt antal relationer troliga att återkommande behöva ta ut likhet m.fl. operationer applicerade för inkl. nu att fler resp. större andelar av vikter använda ska beräknas kontinuerligt uppdaterade vilket expanderar upp data tvingat via cash än mer så att det kan göras u bulk ett par gånger pe rdag - hence att databas-problem blev löst trots databas-fobi).

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt) (2014-04-21) (och Google: Feedburner, Youtube och Feedproxy.)
• Resultat spindling efter RSS- och ATOM-strömmar (2014-04-27)

Mycket typisk mänsklig problemlösning i den ena av två grova grupper kreativitet vi kan se. Här stegvis-förändring sökande behålla värde vi har (eller ofta nog slippa lära något nytt). Äldre mer erfarna kan prestera väl i företagsutveckling i denna domän. Vanligt i antal nya företag ovanför detta är konsultverksamhet byggande på upparbetad vetskap om en form av problemlösning eller förståelse av en verksamhet. Den andra domänen är innovation i emergence skapande något radikalt nytt.

Säger vi att emergence är kontextuellt beroende utifrån ett perspektiv - här jag om tvingad att behöva lära något externt system nytt för mig resp. behöva plåga mig med att sätta upp nya version Ubuntu och ett ganska komplext legacy-system liggande ovanpå: ny kunskap, nya komponenter adderade och inte otroligt nya värden svåra att förstå från Berkeley DB perspektivet - har vi ex. när en metod från ett annat expertområde inses optimera i ett annat eller när en upplevt ny upptäckt kommer (för vilka ofta gäller att olika individer oberoende i vad ytligt uppenbart gör samma upptäckt ungefär samtidigt i tiden d.v.s. latenta faktorer existerar). Tidigare diskuterat många gånger även nyligen i år Emergence relationer - Emergence demokrati (2014-04-21). Innovation via emergence är ibland oftare lättare för yngre: de kan ju föga från början och har inte lärt sig hur det ska gå till att hämta upp data lagret (kanske inte ens hört talas om X.500, LDAP eller MD5).

Lite som att redan förstå varför allt i datat alltid ställer till med små-problem och hur vi ungefär löser det. Relativt att söka en ny givet viss tid mellan inlärt problemen och nutid möjligt bättre lösning kanske genom att elt undvika problemen.

• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier (2014-04-30)
• Minimalistiskt sido-algoritm-skiss beräknande läsare nyhetsmedier II: Algoritm omvandlande tidskostnad referera nyhet till förtroende publicist (2014-04-30)
(Och mer kompletterande de sista snarare än just relaterat lösning i problem-domänen för mig varande vad inarbetade algoritmer med föga behov förändring finns för: arbetet här och relaterat har mer att göra med att ta saker större i antal koncept vi förstår och ser, mängden statistik relationer, antalet publicister hanterade, antalet "skrivande läsare" analyserade o.s.v. för vikter diskuterande rörande ungefär emotionell intensitet: Att välja mellan kontext och känsla vid betraktande av "minnen" (2014-04-20) i mening att göra referensen begriplig ungefär vad avsett).

Resultat spindling efter RSS- och ATOM-strömmar

Det huvudsakliga syftet med sista "spindla efter strömmar" (när refererat rss-ström avses vilka som helst strömmar oavsett RSS eller ATOM resp. version) projektet var att öka mängden blogg-strömmar (och på vägen dit nyhets- / pressmeddelande-strömmar) på .edu-domäner eller övrigt inriktat forskning. Spindlingen utgick från alla pressmeddelanden publicerade på EurekAlert! fortfarande i Breaking News.

Robot dumpade hittade länkar tidigt i samma fil och längre fram när jag började tråda den i filer med slumpmässigt namn. Vidare sattes ett stopp-värde per domän parametriserat vid start d.v.s. vid varje återstart eller att tråden börjar om (för att slippa hålla mycket stora mängder länkar gjorda eller att göra) är det inte självklart att de länkar först skrivna till fil för en domän tas först utan ordningen ges av filerna sorterade efter namn.

I skärmdump framgår ordningen filerna för redan besökta resp. identifierade länkar läses in. Rörande parametrisering anger första siffran antalet besök på domänen som tillåts, andra hur många länkar att besöka som tillåts ligga i minne (kan praktiskt hamna något under resp. över), tredje parametering vad som ska finnas i länken för att den ska besöka (eller tillåts resp. allt ska finnas) samt den fjärde ej i bilden omvänt från den tredje d.v.s. vad som ska uteslutas.

Utifrån tanken diskuterad i:

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt)

Införde jag möjlighet att parametrisera vilka undermängder av identifierade länkar en tråd ska prospektera. Bl.a. lät jag trådar gå tämligen länge (kanske 10 - 48 timmar totalt) för:

• Just Blogspot.
• Wordpress.com resp. Wordpress förekommande i url.
• Typepad.com
• .edu inkl. .edu.
• .gov inkl. .gov.
• .mil inkl. .mil.
• .org inkl. .org.

En relativt övrigt kortare tid men med vid den tidpunkten startad (sista 25% av tiden robotarna vandrade nätet) snabbt expanderande i antal hittade rss-strömmar: .com (minns jag rätt ej inkl. .com.).

Samma trådar efter att de kommit igång med att besöka tidigare identifierade länkar.

Exakt som jag förväntat från när jag skapade första proof-of-concept versionen av sökmotorn gäller att spindla efter RSS-strömmar är vekt inom flera områden med viktiga newsprovidera:

• Att utgå från <link ...> levererar ej och när det leverar en försvinnande liten andel.

Istället behöver man spindla efter länkade undersidor och där suga upp länkar (jag begränsade till länkar och intrycket är att det täcker upp de flesta även om några endast skriver dem i text) till RSS-strömmar man publicerar. Detta gäller särskilt:

• Amerikanska .gov och .mil sajter.
• P.s.s. som föregående en del nyhetstidningar.

Vidare besläktat men när man väl hittar motsvarande blogg fungerar ofta <link ...>:

• Bloggar som enskilda medarbetare, organisationer m.m. har "undangömda" långt in i spindlings-väg relativt endast enklast domän-namn.

I detta spindlings-projekt sökte jag endast <link ...> medan jag vid ett föregående också analyserade länkar för att söka avgöra om de ev. är RSS. Det första projektet gav ordentligt fler RSS-strömmar men införde också diverse felaktigt antaget RSS som ännu ej filtrerats bort (bl.a. en del sitemap-länkar).

Trots att .gov och .mil prioriterades i timmar blev andelen RSS-strömmar levererade försvinnande få och inte mer än cirka 10% av vad jag lade till manuellt genom att gå igenom de viktigaste sajterna (ex. resp. vapengrens huvudsida för .mil med ex. site-sökning med Google) , tjänsterna (ex. tjänster för varningar rörande väder - ex. tsnunami-alert - o.s.v.). Det understryker hur begränsat <link ...> är.

Riktad spindling mot URL inkluderande news och/eller press levererade vettigt och tämligen högt men prioriterades relativt ordentligt mindre än övrigt. Bäst resultat i antal identifierade strömmar gavs av självklara orsaker när Blogspot, Wordpress och Typepad prioriterades. Dessa prioriterades vidare ordentligt i tid utifrån tankarna diskuterade i:

• Riktad sampling Blogger för ökad tillförlitlighet (och pågående unikt problematiskt internet från min accesspunkt)

Totalt tycks 147 172 RSS-strömmar identifierats. En del är antagligen defekta bl.a. av följande noterande orsaker:

• Angiven men används ej. D.v.s. man har växlat url någon gång men ej förändrat vad angivet alt. att den ej fungerar just när jag kontrollerat.

Den initiala start-noden EurekAlert! gav så länge jag körde en hög andel strömmar relaterade forskning. Men vilken andel det är av totalt identifierade domäner vet jag ej och har ej kontrollerat hur stort det totala antalet identifierade (spindlade eller inte) domäner är.

Trådar pollande RSS-strömmar. Den eller de parametriserade först inkl. EXTRA hämtar från vad som identifierats i diskuterad spidering. FAST särskilt prioriterade avseende bl.a. nyhetstjänster likt ex. Reuters eller New York Times (och dessutom inkluderade sådana manuellt adderade oavsett ofta uppdaterade). ALL avser en ganska stor lista skapad genom tidigare kontroll av alla sajter där det för mig är känt med ganska hög tillförlitlighet vilken entitet de tillhör (utnyttjande tvättat Wikipedia-data): totalt cirka 90 000 strömmar inkl. ett mindre antal (cirka 5000 - 20000) "defekta" strömmar och ATOM- och RSS-strömmar för samma publicering.

Sampling är e diskriminerande från annan aspekt än att det är önskvärt att en hög andel strömmar är på engelska. Och prioritet i manuellt arbete har gjorts för att söka inkludera särskilt politiska entiteter från länder "problematiska" att enkelt från domän identifiera som tillhörande ex. myndighet (ex. Sverige med government.se snarare än government.gov.se jag gärna önskat som synonym eller Japan med go.jp) liksom politiskt "mer bråkiga" länder som Ryssland och Kina. Vidare sker hantering sampling enligt principer som gör att ingen kostnad annat än i tid processing föreligger avseende att "inkludera för mycket" (undantag hantering strömmar där inlägg saknar meningsfull titel där positiv-särbehandling sker på ett antal RSS-strömmar från amerikanska myndigheter eftersom de där av och till berör varnings-tjänster vilka jag gärna vill få med just indexerade).

Spidering av url:er inkluderande news men ej .blogspot eller wordpress (därför de senare har egna trådar).

Sista raden ovanför ett antal = kan ge upp till två siffor indikerande antal länkar resp. antal strömmar identifierade.

Hur jag gärna vill se att domäner relaterat regering eller myndighet indikeras och p.s.s. relaterat utbildning med .edu..

Antal identifierade för några utvalda meningsfulla under-grupper

Totalt tycks 147 172 RSS-strömmar identifierats. Ev. summerar uppgifterna ej korrekt för undergrupperna vilket om så har att göra med logiken för hur resp. grupp tas ut när RSS-strömmarna efter spindling hämtas för att tas ned (typiskt enligt för ex. wordpress: index(lc($url),"wordpress") i Perl). Medan tillförlitlighet totalt andel är mycket god eftersom allt förekommande i filerna med identifierade RSS-strömmar tas in och lagras i hash-tabeller för att garantera unik-förekomst samtidigt som domäner som notoriskt indikerar både ATOM- och RSS-strömmar - ex. Blogspot.com - särbehandlas för att hantera detta).

Självklara blogg-plattformar

Wordpress (Oftast Wordpress.com men allt inkl. wordpress i url-feed
51190
Feedburner
1435
Blogspot (extrahering utnyttjar Google's semantik för hur strömmar namnges men ej en perfekt lösning)
46020
Typepad (inkl. typepad i url feed)
4219

Domäner indikerande meningsfull indelning verksamhet

.edu (inkl. .edu.)
4847
.gov (inkl. .gov.)
799
.org (inkl. .org.)
18179
.com (inkl. .com.)
21430
.mil (inkl. .mil.)
162

Övriga

Alla övriga (ex. ip-adresser)

3152

Google: Feedburner, Youtube och Feedproxy

Spidering sökande riktat feeds nära entiteter forskning med utgångspunkt pressmeddelanden publicerade via EurekAlert, AAAS gav ett antal strömmar identifierade för Youtube-sidor. Där kunde konstateras att dessa precis som FeedBurner (Feedburner trevligt snabb) var mycket snabba.

Vidare noterades att även feedproxy.google.com märkte ut sig som mycket snabb. När jag testar feedproxy.google.com i webbläsaren hamnar jag på FeedBurner. Förklaring tycks vara att Bloggers egna feedsystem nu är FeedBurner direkt (förändring ska nog tas som trolig skett för flera år sedan utan att jag märkt något förrän nu).

Praktiskt gäller tveklöst att ju fler strömmar hos dessa desto snabbare att polla igenom allt. Konkret märkbart - tydligt - snabbare än vad jag märkt allt förekommande nog i antal för att man ska märka det. Från denna aspekt är ex. blogg på Blogger trevligare än Wordpress (men säger givetvis inget om värde indexering eller som statistiskt mätpunkt varför de lika självklart pollas precis som Blogger).

RSS vs ATOM: FeedBurner

Spännande eller bättre sagt udda / fascinerande nog fick Google ett antal år sedan för sig att blåsa liv i nära nog döda Atom kanske för att inspirera nätets publicister och utvecklare med en till standard att hantera. FeedBurner är här ganska trevlig och vilken standard önskan kan konfigureras till önskan från (om jag inte missat någon ev. konfigurerarbar begränsning feed-ägaren kan ställa) vilken som helst feed-indikerad.

D.v.s. som i exemplet nedan för att säkerställa RSS (Perl och låt oss tänka - oss utan risk att någon oväntat hoppar fram och erbjuder mig en stor summa pengar för att direkt binärt sälja det just då - att jag egentligen gjorde det hela mycket mer avancerat riktigt pressande allt vad standarden och Feedburner har att erbjuda i möjlighet men för läsarens enkelhet valde att skriva något kortfattat):

if ( index($cline,"feedburner.com") != -1 )
    {
 if ( index($cline,'?') != -1 )
 {
     # Tar bort givna parametrar...
     $cline = substr($cline,0,index($cline,'?'));
 }

 $cline = 
     $cline . "?alt=rss"; 
    }

Jag såg förövrigt på Stackoverflow.com (Feedburner RSS url variable for number of items in feed? - mer FeedBurner Stackoverflow) att det ej går att styra FeedBurner till att visa fler inlägg än vad som ges. Om det stämmer är jag inte säker på (har överhuvudtaget inte läst manualerna men funderar på att se över möjligheterna där såväl som från andra källor eftersom FeedBurner tycks riktigt stor).

IDG märker ut sig

RSS-strömmar (och jämförbart) detekterade från sidor antingen från associerade entitet eller för färre (huvudsakligen för att få större antal relativt existerande bloggar på edu-domäner) via random-walk över länkar. Nedan för samlade antalet märker IDG ut sig med att det tycks kommit med någon form av unicode-escape när det extraherat sparats ned:

Jag såg inte det för någon annan URL men tittade inte mer än en bunt page-down. Kanske relaterat för hög OS-intelligens på datorn som först sparade ned sidorna innan extraktionen skedde? Men jag tror oavsett det inte att värden indikerade via href oavsett vad en eller flera webbläsare läsande in all meta ev. korrekt fungerar med är särskilt stabilt med mer optimerade besökare som robotar.