Jag, Joakim

jj

Efter snart tre månader på Svenska Yles “utgivning webb” börjar det bli dags att presentera mig själv: Hej, jag heter Joakim, kallas för Jocke och jag är kodare.

Det råder ganska spridda åsikter om vad en kodare är och vem som får kalla sig kodare. Vissa purister tycker inte att jag får använda titeln, eftersom jag endast skriver program i språket PHP som är ett s.k scriptspråk och tolkas av datorn utan att programmeraren först behöver översätta det till maskinkod. Samma purister får hjärtslag när någon som “bara” arbetar med HTML kallar sig för kodare. Ovannämnda hör till mina huvudsakliga verktyg och för enkelhetens skull brukar jag ändå presentera mig som kodare.

Här är mitt försök att definiera kodande och samtidigt en beskrivning av vad jag gör här på YLE: En kodare löser logiska problem och skriver sedan ner lösningen på ett språk som han behärskar och som stöds av servern. Pluspoäng fås om man skriver ner lösningen på ett sådant sätt att också andra kodare förstår den. Vill man vara extra öppen, så kan man skriva koden så att hela världen kan ha nytta av den och till och med vidareutveckla den. Då måste man följa vissa riktlinjer och koda på en ganska allmän nivå i stället för att välja lösningar som endast kan utnyttjas av vår begränsade nisch. Jag gillar den sortens öppenhet och det var en glad överraskning då jag fick höra att man också på YLE värdesätter öppenhet och att det finns stora satsningar för att göra det vi håller på med mera öppet.

Min officiella titel är “webbutvecklare” och här på YLE ska jag i första hand arbeta med webbsajten svenska.yle.fi och specifikt som Drupalexpert.

Kanske man bättre förstår vad jag sysslar med om jag get ett konkret exempel: När YLEs redaktörer skriver webbartiklar, så ska varje artikel helst förses med nyckelord som är relevanta för det man skriver om. Orden kan inte väljas hur som helst, utan ska sökas från en ordlista, en s.k “ontologi”. En av mina första uppgifter var att se till att redaktörer kan tagga sina artiklar med ord också från andra ontologier än standardontologin, “koko”. Som konkret exempel kan man nämna “mesh”, som innehåller medicinska termer och ska användas av Webbdoktorns redaktörer. Som kodare tacklar man uppgiften steg för steg: Först måste jag se om jag över huvud taget kan söka mesh-termer från ONKIs tjänst. När jag kan göra det på teknisk nivå måste jag fundera hur en redaktör vid inmatning av en artikel lättast specificerar att nyckelord ska sökas från t.ex mesh. Det finns många alternativ: man kan välja från en s.k rullgardinsmeny, man kan kryssa för en eller flera ontologier med s.k checkboxar och så kan jag som kodare kräva att en redaktör vet att man ska fylla i ontologins namn före sökordet, t.ex “mesh:huvudvärk”. Det sistnämnda är ett bra alternativ om endast väldigt få ska använda andra ontologier. Vi vill gömma funktionen för dem som aldrig behöver den, för att inte verktyget ska bli svårare att använda.

Jag ska återgå till presentationen. Jag är i skrivande stund 37 år gammal och har jobbat som webbutvecklare och utbildare för samma företag i drygt 15 år före jag kom till YLE. Utbildningarna skedde till 90% i samarbete med Arcada och jag har stått tusentals timmar i klassrum både på Drumsö och i Arabia när Arcada flyttade dit. Nästan all utbildning har skett inom fortbildningen för vuxna elever och kurserna har handlat om allt från fotografering och Microsoft Excel till programmering i olika språk, som PHP, HTML (förlåt, purister), JavaScript och Flash Actionscript.

När jag kom till YLE hade jag inte speciellt djupa kunskaper om Drupal, eftersom jag i omkring 10 år arbetat med en konkurerande produkt, ett eget innehållshanteringssystem som gör ungefär samma saker som Drupal. Det var intressant att märka att många av de lösningar som finns i Drupal är saker som jag själv har funderat på och det var därför inte särskilt svårt att “komma in” i Drupals sätt att göra saker och reglerna för hur man skräddarsyr lösningar.

I mitt tidigare liv som utvecklare arbetade jag mycket och ofta med olika webbprojekt. Den stora skillnaden mellan mitt liv då och nu var att organisationen var så liten att jag ofta “fick” vara med och t.o.m ansvara för hela processen: Det första mötet med en ny kund, skrytande med tidigare projekt, genomgång av kundens specifikationer och önskemål, frågor om budget, planering av en offert som passar in i nyssnämnda, utarbetande av tidtabell, förverkligande av layout, html, javascript, css, php, databas, kommunikation med kunden per email, telefon och regelbundna möten under projektets lopp, registrerande av webbadress, konfigurering av server och e-post, testande, buggfixar, avslutande av projektet, klagomål… Exempel på projekt vi gjorde var webbshoppar, valmaskiner, auktionssystem, ekonomisystem, “vanliga” webbsidor och många helt skräddarsydda lösningar för vad kunden sade sig behöva.

Det som övergången till YLE har medfört är en möjlighet att få fokusera på färre saker och göra dem mera ordentligt. Jag var en sorts allt-i-allo och nu ser jag mig mera som webbutvecklare eller kodare som också får vara med och visionera och planera ibland, men som ändå huvudsakligen arbetar med ett ganska snävt område. Faran med att, som jag tidigare gjorde, jonglera så många uppgifter och t.o.m olika projekt samtidigt är att kvaliteten lätt blir lidande. Speciellt som man hela tiden begränsas av slutsumman på en offert som oftast ligger i den lägre ändan av vad som är mänskligt möjligt. Risken är också att man är för fokuserad på “the bottom line” och inte kan vara stolt över att man gjort nåt fint, utan endast då firman tjänat en massa pengar.

I mitt privata liv dras jag främst till olika kreativa hobbyer, som fotografering, chiliodling, matlagning, bakning, pianospel, hemrenovering. Jag bor i ett hundra år gammalt hus med många flagande ytor och spruckna väggar och försöker så småningom lära mig rätt sätt att ta hand om stället. Datorer ligger också ganska nära hjärtat och när min son nu nått den mogna åldern av tre år, så är det intressant att se hur han tar till sig teknologi. Det tog förvånansvärt länge för honom att förstå varför det ska finnas tv-program som kommer bara en gång och ett visst klockslag. Han är också ytterst förbryllad när man talar i telefon med nån utan att se personens videobild. I hemlighet avundas jag honom som fötts till en värld som är så mycket mera teknologiskt avancerad än min var på sjuttitalet. Jag tror det säger en del om hur jag är som människa och mitt motto eller min livsfilosofi kunde egentligen uttryckas som “visa mig flera coola saker!”. Det känns som att många här på YLE tänker i liknande banor, så jag kände mig både hemma och välkommen från början.

Publiksiffror för svenska.yle.fi, tidsperioden 1.5 – 31.12.2012

Bara några korta kommentarer till bildpaketet, som laddats upp här nedan.

Jag blandar lite, för i kurvorna använder jag unika webbläsare som ”valuta”, medan jag i  topplistorna använder sidvisningar.

Eftersom flera av artiklarna tagit sig med på listan tack vare att de är sk. snackisar, ville jag ha sidvisningar. Jag misstänker nämligen att samma människor öppnat artikeln gång på gång på gång för att läsa diskussionen och kommentera mera.

Jag har också parat ihop kurvorna med kriteriet att de alla skall rymmas på samma bild. Därför är också X3M:s kurva ensam – alla andra kurvor ser så flacka ut i samma bild!

Håll också ett öga på de totala sidvisningarna i topplistorna. Vink till hur du tolkar det? Läs totala sidvisningar i första topplistan och jämför de kommande listorna med den…

Eftersom vi under 2012 bytte till Comscore Digital Analytix, så gäller siffrorna inte för riktigt hela året. Alla listor och kurvor är för perioden 1.5 – 31.12.2012.

ps. De veckorna kulturkurvan ligger på noll är en bugg. Jag jobbar på att fixa det.

Karoliina Korhonen, nätanalytiker

DUI-heatmap Finland 2012

A month ago I created a heatmap visualization of driving under influence records in Finland 2012. The story and visualization itself were fairly popular on svenska.yle.fi during the week of the release, ranking up to be the most read news-article (see inrikes category artikel.har-aker-rattfylleristerna-fast-se-karta.sivu). It also raised a fair amount of feedback trough the comments section about usability of heatmap visualizations in general.

Heatmap
Heatmap of DUI-incidents at Helsinki area

Heatmaps are a bit tricky to use as visualizations. XKCD-comic has tackled the essence of it. If a map correlates heavily with the population distribution, it may only tell to the viewer what people can already expect, things happen where there is a lot of people. Also when the visualization is dynamic, you get more details on demand. When you zoom in, you’ll see more details and when you zoom out you see less details..which can mean that there will be a huge red blob on top of a map at certain distance.

The data for the map was acquire by a journalist via a information request to police. We received it as an excel-form with 20352 lines of raw data of DUI incidents in Finland. Data included an identification number to police records, municipal area and a mysterious area code, street-address of incident, weekday of incident and date and time of incident. As usual the data was somewhat ‘dirty’ and required thorough clean-up to make it fit our needs.

Screen Shot 2013-03-21 at 12.44.34 PM
Raw-data in Excel

Data itself may reveal patterns and information about measurement and how it was collected. In our case we noticed that the naming convention of incident addresses is fairly imaginative. There’s an address-field that police officers fill in, among other things, when they report the DUI incidents into the system. This field should contain an address of incident so it can be pinpointed if necessary. However there doesn’t seem to be an unified practice of reporting the addresses.

Address field seems to be filled in many different ways which makes the exact pinpointing of the incident later on a fairly difficult task. For example an incident address that has happened at crossroad of two roads might be marked as road1 X road2, or road1, road2 crossroad or road2xroad1 or  road1 at crossroad road2 etc. Or the address-field has been used to give more information about place of incident instead of just an address, i.e. Address xyz, from the yard.

My personal favourite version of the data in the address field was ‘Kylän Kohdalla Jäällä’ = ‘at the region of the village on the ice (lake)’, which couldn’t be more vague in terms of locating the exact spot.

Sure, all these addresses could probably be pinpointed by someone with knowledge of local surroundings, but for outsiders the location stays a mystery. For a future implementation of such a system I’d highly recommend adding the possibility to insert longitude and latitude coordinates field. But enough ranting and back to the topic.

The dataset is fairly large (20k+ addresses) and if one wants to get a overview of geographically distributed data one method to approach this is to plot incidents on to a map. But what tool to use?

I personally prefer to use existing methods and tools to visualize and gain insight on data and after googling for a while I bumped into a heat map javascript library called Heatmap.js. So it was chosen as a prominent technology to implement the test-case. A random city of choice was chosen -Tampere.

The next task was to figure out how to translate this given data from excel-format into a format that Heatmap.js accepts. Heatmap.js uses a list of longitude and latitude coordinates and a weight of how many incidents are at those coordinates. The weight can be calculated in Excel by counting the amount of occurrences of addresses, but the addresses need to be converted into coordinates. This conversion of address into longitude and latitude is usually referred to as geocoding.

Geocoding multiple addresses
Geocoding multiple addresses trough yahoo api

There exists a fair amount of web-based tools to quickly geocode a single address into gps coordinates. I used http://www.gpsvisualizer.com/geocoder/. It’s probably not the best, but it gets the job done. The downside of it lies in the ability to geocode multiple addresses. Gpsvisualizer.com offers an ability to use yahoo geocoder for multiple addresses, but sadly it’s fairly inaccurate in Finland. For example I tried to geocode street-addresses from Tampere and ended up getting a wad of similar coordinates.

But it’s possible to geocode a single address at a time with Google geocoder at gpsvisualizer.com, which gives much more accurate readings, but as you would guess it is also a lot slower method. As I had a deadline breathing down my neck and 20k+ addresses to geocode I gave it a shot. In my case roughly a week of typing and copy+pasting, so clearly a slow method.

Geocoding one address
Geocoding a single address trough google api

A slightly better way to do this is to use Google geocoder api and create your own geocoder. This is the method I would use to geocode multiple addresses now if I’d have to do another address based visualization. But at the time I was working on this the deadline was looming on and I was busy with getting the visualization forward. So I accepted the fact that I’d be spending a considerable amount of time on smashing the same button combination over and over.

Screen Shot 2013-03-21 at 4.36.09 PM
Geocoding multiple addresses trough google api

After the data was in a appropriate format for visualization tool it was a fairly straightforward job to fine tune it and release it.

Well, what I learned from the project or at least reconfirmed, is that 80 percent of the time goes into purifying, transforming and fiddling with the data to get it into a format that can be represented and the rest 20 percent is fine-tuning and adding extra functionalities into it. An interesting dataset and a fun project, and when the data is interesting it seems to translate fairly well into ‘news’.

The making of a Yle Drupal Distro (YDD)

From the start of the project (Swedish Yle’s New Drupal (SYND)) we had a goal to build it as a distro. What is better than that someone else can use the same code base? 🙂 With YDD we reached the internal distro milestone, an important step if we also some day want to be able to make it a public distro.

During January we spent two weeks making our own code more abstract (for some reason there is always something that gets hard coded), making new features that were wanted for the PoC (Proof of concept) of FYND (Finnish Yle’s New Drupal), setting up a new dev environment and splitting up the install profiles to support YDD, SYND and FYND.

The structure we decided to use is as follows: YDD contains the basic functionality that all sites should have. SYND and FYND each contain their separate modifications. Example; recipes, maktbasen and some Svenska Yle specific styling is found only in SYND. The themes in fynd_themes and synd_themes are subthemes of the theme in yle_themes.

The GIT structure and install profile logic:

FYND

YDD

SYND
fynd_modules
fynd_features
fynd_themes
fynd_profile
yle_modules
yle_features
yle_themes
synd_modules
synd_features
synd_themes
synd_profile

With this structure we are able to use a common core, and if needed add more functionality, translations or styling per site. Issues we ran into include views that were created when the system was in Swedish. It does not work to then switch the system to English before exporting, the view will be in Swedish.

Another issue was that a view that limited content based on a taxonomy was exported with the VID, and not the machine name of the taxonomy. Solved by changing the view so that the machine name was used in the filter.

We also had some displacements of fields and taxonomies. They had been placed in the wrong feature, so they were not available when some features needed by SYND were not enabled in FYND.

Moving theming to the features and modules was also something that we now needed to do. Not all the views that had styling was going to be used in both SYND and FYND.

The RSS feed generated by Views is one open question. It would be good to share them between the install profiles, but settings like Site name and headlines are hard coded in the view.

Being more thorough in with what is placed where and making sure that the language always was English would have made the process even smoother.

One thing we should have done in the early phase is to change the name on the live production install profile. That we tried to do it at the same time as we had moved some of the modules from yle_modules to synd_modules caused problems when migrating the production database.

The process itself turned out to be a good way to also do a review of the code. Even though we have had two external reviews (thanks Bala, @dasphere) it sometimes takes deep knowledge of a site to realize that something has unnecessary overhead. Having to split the site forces you to look at parts of the code that otherwise does not get looked at that often. We ended up merging and/or removing four features/modules.

Working with Jari Lana who does Drupal for Ylex, Oppiminen & co was also a good way to get a fourth review, from someone who also could make improvements directly in the code.

Even if FYND is never launched, the work will not go to waste. SYND has reached a new abstraction level, got new features and improvements. If the need arises, a new site can be up and running in no time.

Currently svenska.yle.fi is running on the new YDD + SYND setup.

Who is Jarno?

Greetings everyone!

My name is Jarno Marttila and I am the new ‘Teemo’, or incase you don’t yet know Teemo. I’m the new datajournalist for Yle Svenska. I joined the merry band of YLE just a few weeks ago, mid-January.

Well who am I. I guess I’m a lot of things, or maybe one could even say in Finnish a ‘jokapaikan höylä’ (a jack of all trades..) when it comes to data and information analysis and visualizations. I’m 28 year old Diploma Engineer with a major in Hypermedia, though I have studied a little bit of this and a little bit of that on my way.

Past three years I have worked as a researcher at Intelligent Information Systems Laboratory, previously known Hypermedia Laboratory, at Tampere University of Technology with tasks involving all kinds of cool things, including but not limited to, Social Network Analysis and Information Visualization and web-development. My tools of choice in graph and network visualization have been Gephi, Gource, and Javascript libraries such as d3.js, JIT and highcharts when it comes to visualizing and analyzing data. In web-development I’ve mainly dealt with drupal.

In my Master’s thesis I studied on data-driven social network analysis in context of Children’s Parliament of Finland. Lately I’ve been into information visualization techniques and methods of creating insight into complex data-sets. At TUT I’ve done many projects related to gaining and communicating insight into different kinds of data. Whether it has been studying an impact of Government Official in social media or mapping service potentials for customers customers in heavy industry.

Cliques, networks, outliers, factors and facts that explain why data is what it is, and what connects to what, and why things are how they are excite me. Hence a jump into telling stories with information visualization and data-analysis in context of news, or in grander terms in context of data-journalism was a natural leap of faith for me.

At YLE I wish to create interesting and important data journalistic stories for people to consume. As there’s almost nothing more intriguing than succeeding in finding stories from data and implementing them so that they communicate to the readers.

You can find me also from:

LinkedIn
Twitter

Den tidvis vrickade diskussionen kring Flash och HTML5

I mitt tidigare inlägg presenterade jag ytligt hur vi jobbar med att animera material för Buu-klubbens webbsida i Adobe Flash.

För oss på svenska.yle.fi är diskussionen kring Flash och HTML5 nu högaktuell, och konkreta linjedragningar är att vänta inom snar framtid. Diskussionen har ju på bred front pågått en längre tid, och ibland reagerar man på hur generaliserande och flummig den som värst kan vara.

“Flash är ett problem”

Fel! Flash är inte ett problem. Flash är ett verktyg, och ifall man missbrukar det uppstår problem. Försöker man tvätta fönster med en hammare är det troligt att resultated blir ganska dåligt, och i värsta fall går saker och ting sönder.

Det man ser och hör allt för mycket av är attityder och åsikter som helt och hållet saknar grund, och tydligt beror på blind övertygelse. Vissa tar hela diskussionen väldigt personligt, och jag påstår att folk som är redo att kasta den ena eller andra lösningen ut genom fönstret utan desto mer åtanke har definitivt andra (ofta personliga) målsättningar i baktankarna.

Flash har under årens gång sträckt sig till så gott som allting man hittar på webben, på gott och ont. Exempel som alla känner till är animerade banners, spel och även hela webbsidor byggda uteslutande i Flash. Det är uppenbart att Flash inte är det klokaste alternativet till precis allt man kan göra med det, och därför ser jag det som mer än välkommet att det nu existerar utmanare för de plattformer och för de lösningar där Flash helt enkelt inte är det bästa möjliga.

Det man inte kommer ifrån är att Flash är ett utmärkt verktyg för produktion av spel, och i nuläge är det totalt omöjligt att rakt av ersätta det med HTML5.

HTML5

Vad gäller renodlad webbdesign är HTML5 perfekt. Det erbjuder obegränsade verktyg för designers att producera snygga dynamiska lösningar som har alla förutsättningar att fungera på varje plattform så fort understöd existerar. Det här är också ett exempel på ett delområde där man “missbrukat” Flash allt för länge. Missbruk av Flash har lyckligt vis (med tanke på användbarhet) minskat redan innan diskussionen ordentligt hettade till.
Att man nu kan ersätta Flash med HTML5 då man producerar t.ex. banners, datavisualiseringar eller enbart utveckla snyggare webbsidor är en strålande sak. Jag har personligen höga förväntningar för vad HTML5 och CSS3 i framtiden kan medföra.

Buu

Att införa HTML5 i arbetsproceserna för webbdesign är alltså ingen dålig sak alls. Farhågorna väcks då man börjar höra kommentarer riktade emot spelproduktionen. Att producera spel i HTML5, även lika avancerade som i Flash är ingalunda omöjligt. Exempel finns det gott om. Däremot handlar det om arbetsprocesser och resurser. En grundlig kartläggning av vad som krävs för att åstadkomma det vi nu gör vore på sin plats, förutsatt att nuvarande nivå är nånting vi vill bevara. Faktum är att ingen vet vad det i praktiken skulle kräva att exempelvis producera en motsvarande julkalender som vi erbjöd i år, genomförd i HTML5. Jag kan här och nu berätta att det i nuläget aldrig skulle lyckas pga. bristfälliga resurser och otillräckliga verktyg.
Alternativet skulle då vara att gå i en helt ny riktning, där det säkert finns möjligheter, men det skulle i så fall att ske på en bekostnad av mycket av det som nu är Buu-klubbens webbsida.
Det är upp till dem som fattar besluten att avgöra vilka linjer som skall dras för innehållet. Ett mardrömsscenario är en situation där man slänger in nya arbetsmetoder och processer och förväntar sig samma resultat som tidigare, trots solklara brister i kapacitet.

Realism och is i hatten

Lyckligt vis är det knappast realism att förkasta det ena eller det andra alternativet helt och hållet, utan att utnyttja alla fördelar så gott det går. Strävan till att bemöta användarna på alla tänkbara plattformer utan kompromisser i innehållet torde vara en självklarhet, och med tanke på den legacy vi har kommer Flash att vara en del av vår vardag ännu i långa tider. Vår uppgift är att presentera innehållet så att möjligast många kan utnyttja det. Samtidigt skall vi se till att experimentera med nya möjligheter och se till att också HTML5 med alla sina fördelar blir en del av det vi gör.

2013 kommer att bli väldigt intressant, inte minst vad gäller spelen på Buu-klubbens webbsida!

///Johan

Så flyttade vi tio års arbete

Finnairplan i farlig situation” lyder en rubrik publicerad på Yles webbnyheter onsdagen den 30 oktober 2002, klockan 10.35. Den rubriken inledde ett årtionde med verktyget ”Nyhetswebben”.

Ett decennium och 225 000 artiklar senare har Nyhetswebben ersatts av ett nytt system, ”Drupal”. Men de gamla nyheterna finns kvar.

Hur flyttar man tio års arbete mellan två olika system? Det var en utmaning som Svenska Yles webbavdelning stod inför år 2012. Nyhetswebben är ett lättviktigt internt verktyg, medan Drupal är ett komplext öppet verktyg.

Till att börja med sammanställde vi en ”Entity Relationship”-modell som visualiserar hur nyheternas databas är uppbyggd. ER-modellen avslöjar relationer mellan databasens tabeller och kolumner. Denna information hjälpte oss utveckla skript för att pussla ihop artiklarna.

ER-modell

Följande steg var att kartlägga innehållet. Den gamla nyhetssajten bestod ju inte enbart av nyheter, utan även av kolumner, fördjupningar och bloggar, med mera. Kartläggningen hjälpte oss besluta vilka delar av innehållet som skulle migreras, och i vilken ordning.

Vi undersökte och utvecklade tekniska migreringsmetoder. Vi beslöt exportera innehållet från den gamla databasen som en XML-ström (Extended Markup Language) och importera den genom Drupal-modulerna ”Feeds Import” och ”XPathParser”.

Två delar

Migreringen består huvudsakligen av två delar; dels av en exportdel som skapar en XML-ström ur det gamla systemet, dels en importdel som fogar in XML-strömmen som artiklar i det nya systemet.

Exportdelen utgörs mer tekniskt av ett PHP-program som kör MySQL-kommandon i databasen. Programmet pusslar ihop enskilda informationsbitar till artiklar. Artiklarna blir separata objekt i XML-strömmen, så att varje enskild informationstyp får en egen XML-tagg. En utmaning i exportdelen var att ”tvätta” dataströmmen så att avvikande eller korrumperade informationsbitar inte skulle söndra importen.

Den tekniska utvecklingen utmynnade i detaljerade planer. Detta var första gången vi migrerade ett så stort antal artiklar till ett nytt system och vi ville vara säkra på att processen skulle fungera.

Redan de första testerna visade att Drupal inte kan hantera 225 000 artiklar utan prestandaproblem. Det behövdes mellanlagring bland annat via programvarorna ”Memcache” och ”Varnish” för att höja prestandan till en acceptabel nivå. Ytterligare skapade Drupal för varje artikel ett visst antal lyft – lika många lyft som antalet avdelningar artikeln hade funnits i. Detta gjorde att det totala antalet artiklar i Drupal steg till mer än en halv miljon.

Testerna visade också att importen måste köras stegvis för att undvika tekniska avbrott, så kallade ”timeouts”. Vi skapade ett ”Drush”- (Drupal Shell) kommando som kunde köra importen i mindre paket. Detta kommando kördes i sin tur av ett ”Linux Shell”-skript automatiskt i etapper om hundra artiklar åt gången. Hela importen av de gamla nyhetsartiklarna tog ungefär sju timmar i anspråk.

Migreringen fortsätter

Importen av gammalt innehåll har fortsatt med bland annat ”kulturen.fi” där vi använde samma migreringsmetod som för nyheterna. I detta projekt testade vi också att importera artiklar direkt från RSS-filer (”Rich Site Summary”), vilket fungerar nästan lika bra. RSS är en sorts XML. Problemet med RSS-filer är dock att deras syntax är mer begränsad.

För ett tredje projekt, ”Maktbasen”, importerade vi icke-standardiserad information i form av så kallade entiteter, så som personer, företag och kommuner. Det fanns en del halvfärdiga importmetoder tillgängliga ute på fältet, men det effektivaste sättet för oss var att importera entiteterna direkt till Drupals databas.

Drupals entiteter består av en huvudtabell där innehållet hålls ihop av ett unikt ID, samt enskilda tabeller för alla fält som ingår i en viss entitet.

Migreringen av innehåll har fortsatt med bland annat Mat och fritid. För Mat och fritids recept använde vi en likande XML-generator som för nyheterna, men skapade en ny importör, eftersom recepten fick en egen innehållstyp i Drupal.

För resten av sajtens artiklar använde vi nyhetsimporten som vid det här laget hade utvecklats till en generell importör för artiklar. Denna XML-importör kan numera användas för i princip vilken typ av innehåll som helst som kan översättas till XML.

Fotnot:
Verktyget ”Nyhetswebben”, skapades ursprungligen av Robert Tamm. Nyheterna, tidigare ”Internytt”, har även använt andra webbverktyg. Artiklarna från tiden före oktober 2002 verkar dock till största delen ha gått förlorade.

Nyhetswebben 2.1