Collaboration across borders


Nordvision agreed to fund a programmer’s exchange between DR in Denmark, Rúv in Iceland and Yle in Finland. The exchange started off with me going to Iceland for two weeks. We collaborated on a meta-data project for Drupal called Yild by preparing for migration of Rúv’s terms to a Yild-compatible format and by writing a new Spotify provider module for it. We feel a lot of good came out of the project and are eager to continue it when someone from Iceland comes to Yle for a similar exchange in Q1/2017.

The project

Three nordic broadcasting companies: Svenska Yle, DR and RÚV have received funding from Nordvision to undertake a two week developers’ exchange between the companies. This text documents my experiences and findings from working with RÚV for two weeks.

Where it all started

The project first started in Amsterdam in 2014, when we met Helgi Páll Þórisson from RÚV at Drupalcon, a big convention for enthusiasts and professionals of the content management system Drupal. Both Icelandic RÚV and Finnish Yle were already using Drupal and we have the unique common ground of both being a publicly funded public service company with the same challenges and demands on the web platform.

We discussed the merits of Drupal and the unique problems we were facing. Quite soon the idea of collaborating was born. Coincidentally, there is already an organisation for such collaboration: Nordvision, which gathers representatives from all Nordic public service companies around the same table in a partnership.

Later, we would run into Helgi several times at various Drupal events and our visits to other Nordic public service companies. The idea of working together started to grow and pretty soon a developer exchange was proposed: One developer from Yle would work in Iceland at RÚV for a couple of weeks and later on, someone from RÚV would come work with Yle in Finland. Danish DR also expressed interest in being part of this program and time tables and other circumstances permitting, a similar exchange involving DR is planned for the future.

The exchange

After the summer of 2016 things started coming together: Nordvision approved the request for funding and pretty soon a time table was drafted: I would go to RÚV for two weeks in November 2016. At Yle and RÚV we started planning the details of the exchange.

We decided the developer exchange would focus on metadata, since Yle already uses a tagging system for Drupal that connects tags to an official source, such as Wikidata. This module or plugin for Drupal is an open source project called “Yild” (for Yle integrator for linked data). We agreed that our main focus would be to determine whether the same system could be used at RÚV and if so, to start implementing it.

The team

RÚV has a team of highly skilled web developers wrestling with a multitude of technologies, such as Swift, Python, PHP, to name a few. The team is cooped up in a far away corner of the building, fairly well isolated from the rest of the workforce. This is typical and unsurprisingly the same arrangement we use at Yle: Developers need to be isolated from outside disturbances and any interaction should ideally be channeled through one intermediary, a team leader or a scrum master.

What’s impressive is that two of the developers, Hannes and Jón, had only been at RÚV for a month when the exchange started and they were already highly productive. Hannes showed me the Apple TV app he was working on and told me the first version was already in production! Most of all, what stayed with me, was how fast RÚV had managed to make their new employees productive. Something many other companies could take note of.

Volunteer work

One thing that sets our organisations apart is that many developers at RÚV seem to be involved in some kind of extracurricular and in many cases volunteer activities:

Jón runs an non-profit initiative at the web address to teach young kids programming. This is done with a Raspberry Pi computer that is able to run the popular game Minecraft in such a way that it can be programmatically manipulated using Python. This means the kids can learn to build houses by programming logic instead of the traditional approach of walking (in the game) to a spot and placing a building block there. I was impressed by how visual this process of learning the basic tools of programming is.

Gunnar is deeply involved in an initiative first introduced by BBC to give 9000 Icelandic children their own one-circuit-board computer, the so called Micro:bit. This collaboration between Microsoft and BBC gives the children an app that runs on their mobile. Using Bluetooth, they can first design the program in the app and then transfer it to the Micro:bit for running. I started Googling the Micro:bit and apparently there have been some Workshops at Kiasma, our modern museum, in Finland to introduce it to the public. In Iceland, this project has already evolved into an Icelandic web page developer by RÚV that contains dozens of exercises for those who want to learn how to program. I’m hoping to see similar initiatives in Finland as well. Maybe Yle could look into something similar or even collaborate with RÚV?

Image showing how small the micro:bit device is.
Micro:bit. The price is as tiny as the device itself: 25€.

Team management at RÚV

The first thing that catches your eye at the web developers’ office at RÚV is the gigantic kanban board in the middle of the room. Almost all the sticky notes are in the “ready for testing” or “done” column.

Image depicting the Kanban board at Rúv
Yes, most of the issues are in the ”done” column.

Like most software companies these days, the chosen methodology is a sort of customised agile model with daily meetings and a desire to achieve synergy through shared problems and tasks. Whenever I told the team about a problem I was facing during a daily meeting, someone was always eager to offer a solution: “Icelandic always has problems with character encoding because of our many special characters”, Gísli Þórmar Snæbjörnsson offered helpfully.

Whenever one team-member recognised another member was working on something they had previous knowledge about, they were quick to offer assistance. I believe one big reason, perhaps the biggest, for implementing agile in a team is to move from working as individuals to working as a team and the Icelandic developers’ team was clearly a team. I often saw three or four people flock around the same screen, speaking enthusiastically about some new idea of problem they were having. In contrast, at Yle I usually see people keep to their own screen and I think this is something we could learn from the Icelandic team: to be more brave in seeking out other people’s ideas and thoughts.


We started the project with a kick-off meeting the very first day. Everyone on the web-team attended and it was decided I would primarily work with Jón, Hilmar and Helgi. These were all people with prior Drupal experience or, in Jón’s case, new employees who needed to familiarize themselves with the platform.

As part of the Kick-off meeting I demonstrated the Yild module to the whole team. Yle has been using the module for tagging content for several years and it is this experience and expertise that puts us in a position to help RÚV take their tagging to the next level.

Real structured data opens up exciting possibilities: For one, Google will start to know what the content is about, which will help the search engine ranking. Using a common vocabulary, there is also the possibility of linking content from different sites. If Svenska Yle writes about the Eurovision Song Contest, we could link to RÚV’s content about the same subject.

Code review

The next day the Drupal developers gathered for a more technical meeting: The code review and presentation of the Yild module. I explained the structure of the project and walked the team through the programming patterns in use.

Yild is a multi-part module where a core module provides the basic functionality. The core then calls upon so called provider modules to fetch tag suggestions and details from various external sources. Each external service has its own provider: Wikidata, Geonames, Wikipedia, Musicbrainz, etc.

As a result of the collaboration with Rúv, a stable version of Yild was published. You can read more about it and test it yourself at

Writing your own provider module is a relatively trivial task if they have a well-documented api to fetch data from. As a result from the code review, Hilmas became enthusiastic about writing a provider module for Spotify since that was something he needed for another project. By making Hilmar a co-maintainer for the Yild project, it would also be possible for him to contribute to the Yild project itself with a new component that added functionality:  the ability to tag articles and other content with any artist, song or album that is on Spotify, complete with l descriptions and album covers.

Jón would in turn work on a provider for tagging with Icelandic politicians (an idea that was later scrapped and replaced by a provider for looking up Icelandic companies).

Helgi and I would work on researching how to best migrate from the current tag system on RÚV’s Drupal site. It was suggested that a migration tool for trying to match existing tags against a preferred provider would be useful for the whole Drupal community, so that would be my main focus for the next weeks, along with trying to match RÚVs tags against Wikidata to find out how many I could actually match.

The Spotify Provider

Hilmar was quick to finish his first draft of the Spotify provider module. After committing it to the version control repository at, I read the code, tested the module and offered my comments and insights.

In just a few days, Hilmar went from not having seen the project before to contributing a provider module that was added to for the benefit of the whole world. This felt like a big win for the project. Two Nordic public service companies had actually worked together on the same code and then released it as open source.

Image showing the Spotify provider in action.
Looking up the Icelandic artist Mugison using the Spotify provider finds all albums and songs.

In the meantime, Jón discovered a bug that broke an important part of the functionality of Yild on cleanly installed systems. He quickly fixed the bug, made a patch, which was added to and credited to him. We now had two Icelandic web developers from RÚV with official contributions to a Drupal project started by Finnish Yle.


One thing to keep in mind is that the quality of your structured data can only be as good as the data you get from the provider. There was always a concern that Wikidata wouldn’t be good enough in Icelandic to actually be used with RÚV’s content.

During one of our first meetings, Jón mentioned there was a very exciting open source initiative for cataloging and structuring content on Icelandic news sites called Greynir. Greynir is an NLP (Natural Language Processing) parser for the Icelandic language. It indexes several sites and breaks the content into a tree structure, distilling the content into specific terms, such as names of people, places, job titles etc.

Greynir is developed by Vilhjálmur Þorsteinsson, a veteran programmer and enthusiast of deep learning and artificial intelligence. Jón set up a meeting to sit down with mr Þorsteinsson to discuss the possibility of turning Greynir into an API for use with Yild.

One way we use Yild at Yle is to fetch term suggestions based on the content. This requires some kind of analysis service that reads the text and offers suggestions on terms that are relevant for the content. There is currently no such service for Icelandic that we know of, but Greynir is very close and with a small amount of work might become such a service. This would help immensely with the tagging of Content at RÚV.

During the meeting mr. Þorsteinsson said it would be quite easy to give Greynir an Api structure and it’s an angle we are excited to move forward with.

Read more about Greynir and try it out yourself at their website.

Migration tools

The biggest obstacle for implementing Yild on RÚV’s site was always migrating from the current, unverified tags to something actually connected to Wikidata.

I set out to write a migration tool that would go through all 2000 tags used on RÚV’s website and try to match them with their Wikidata counterparts. After some challenges with character encoding – of which I had been duly warned – and a lot of translation help from my fellow team members and Google translate the tool was finally ready. Out of more than 2000 terms approximately half could be matched against Wikidata. The rest of the terms were saved in a report delivered to Helgi for further inspection.

Image depicting the migration of terms by matching against Wikidata.
Matching tags in Icelandic against terms found on Wikidata.

The way to move forward is now to analyse the migration data and see if it’s good enough to work with. The plan is to run the migration script on RÚV’s test servers and then on the production servers, after which moving to use Yild is simply a matter of enabling the module and teaching the editors to use it.

One particularly amusing problem was when I tried to match the Icelandic word for heavy rock, Þungarokk and kept getting a totally unrelated word from Wikidata that means “roofing sheet” (the sheets of corrugated steel used as roofing on some houses). The word was bárujárn. After a while I asked a team member if he had any idea why this might happen and he laughingly told me it was actually a term used by metalheads as a synonym for heavy rock since back in the beginning of the musical genre they thought the music sounded like hitting sheets of corrugated steel with a hammer. Sometimes the code works perfectly and it’s just the interpretation of the data that is wrong.

The way forward

Having completed the first part of the collaboration project, I feel it’s important not to lose momentum. It’s easy to pat ourselves on the back and congratulate each other on a job well done, but the reality is we’re not done yet.

In the near future, possibly in January, a developer from RÚV is scheduled to join our developers at Yle for two weeks. During that time we will work more on the metadata issues and hopefully come a step closer to implementing Yild on RÚV’s website. We will also likely work together on other issues to benefit from the knowledge of the Icelandic web developers.

In February RÚV is hosting Drupalcamp Northern Lights 2017 in Reykjavik. This will be another opportunity to meet and discuss the project. Hopefully by then, we will be on track to enable the Yild module at RÚV and start tagging in a common way.

There is another Nordvision project focused on API collaboration between the companies. During my stay I demonstrated Yle’s many APIs and walked some RÚV developers through the documentation. As it turns out, RÚV is eager and excited to bring their content to a similar API structure and I feel there is a great opportunity for collaboration around this issue as well. Both in imparting our knowledge of API design, but also ensuring our APIs are built with a similar structure so that we can share information and data more easily in the future.

Above all else though, I feel it’s important to keep the wheels in motion. There is a lot of potential and we’ve come a long way already. By producing something tangible, we stand a chance of bringing even more Nordic public service companies and specifically the developers together in collaboration.

Changing a Drupal pathauto alias pattern with working redirects

So we recently found out we’ve been a bit boneheaded with the pathauto alias to our Freebase taxonomy pages. The pattern was, where 1234 was the term ID (tid) in Drupal.

This is a stupid alias pattern, since it makes our urls obfuscated – impossible to determine from the outside without access to our Drupal database. Also it feels like bad semantical form, because the url contains something that’s meaningless to most people. So we wanted to change the pathauto alias to use the unique Freebase ID instead.

Here it is important to remember that the best looking url naturally would be just, but because of disambiguation (dealing with the case where a word can have many different meanings, such as ”mercury”, which can be an element, a Roman god, a planet and many other things) we want to guarantee that a url is unique.

If we look up the word politics on Freebase, we find that its unique Freebase ID is /m/05qt0 and so we would like our url to have the form

Using our own Freebase module (which may be released to at a later time) has put a field called ”field_freebase_freebaseid” under a taxonomy vocabulary called ”freebase”. This means we have access to the token [term:field-freebase-freebaseid] and that makes the whole pattern for Freebase taxonomy term listings the following:


The problem

The problem is that when we change the url alias pattern we want to leave the old alias intact and redirect from it to the new one. This functionality is built into the pathauto module: you can open up a taxonomy term for editing, save it and the new alias will be generated and the old one made into a redirect.

However, we have 6 000 Freebase terms and it would take a day to open up them all and save them to get the new alias with a redirect. It seems fortunate then, that we have a bulk update feature in the pathauto module. Bulk update generates aliases for all entities in a specific content type. Unfortunately, bulk update only works on entities, in our case taxonomy terms, that don’t yet have a pathauto alias. What you have to do is delete all current aliases and then start the bulkupdate, which will generate new aliases using the new pattern. If we start by deleting all current aliases, no redirects can be created! Here are some articles and threads discussing this very issue. Apparently it’s been a problem for around four years:

Basically, if you’ve created thousands of pathauto aliases that have been indexed by Google and need to exist as redirects to the new alias, you’re out of luck! This seems like an incomprehensible oversight and part of me thinks I must’ve missed something, because this isn’t acceptable.

The solution

Searching the web has given us several ideas about how to deal with this issue, but most require some kind of manual hacking of the database, which doesn’t really sound like something we want to do.

Instead, we ended up writing a simple drush script that just loads all terms in a taxonomy vocabulary (”freebase” in our example, but the script could easily be modified to take a command line parameter). Writing the script took about a third of the time it took to write this blog text, so hopefully at least two other Drupal-users will find this beneficial.

I am assuming you are familiar with Drush scripts, but to briefly explain, assuming your module is named ”freebase”, you can just create a file called ”” in the same folder and when you activate your module, your file will be autoloaded as an available drush script.

The code

The definition of the Drush-command:

function ydd_api_drush_command() {
  $items = array();
  $items['yle-resave-freebase-terms'] = array(
    'description' => "Loads all Freebase terms and saves them to force Drupal to create new pathauto aliases.",
    'callback' => 'drush_fix_freebase',
    'aliases' => array('yrft'),
  return $items;

The accompanying function that does the actual work:

function drush_fix_freebase() {
  // Find freebase vocabulary id.
  $fbvoc = taxonomy_vocabulary_machine_name_load('freebase');
  if (!empty($fbvoc)) {
    $vid = $fbvoc->vid;
    // Get a list of all terms in that vocabulary.
    $tree = taxonomy_get_tree($vid);
    $counter = 0;
    // Loop through all term ids, load and save.
    foreach ($tree as $t) {
      drush_print('Fixing '.$t->tid.' ['.++$counter.' / '.count($tree).']');
      // Load and save term to refresh its pathauto alias.
      $term = taxonomy_term_load($t->tid);

Finally, you need to run the script which will tell you how many terms have been processed out of how many. The command is:

drush yrft

After running this, it’s easy to verify that all terms have indeed received new aliases and a redirect from the old alias.

Knytkonferans på SR i Stockholm

Den 5.4.2013 åkte en delegation bestående av Kristoffer, Mårten, Alexander och Joakim till Sveriges Radio i Stockholm för att delta i ett evenmang som av arrangörerna döpts till “knytkonferans”. För mig var konceptet nytt och jag ska beskriva det utgående från mitt nybörjarperspektiv. Totalt var vi 42 deltagare från SR, UR, SVT, ATG och Finska Svenska YLE.

Idén med en knytkonferans är att man inte bestämmer exakt vad som ska behandlas i förväg. I stället samlas alla som är intresserade av ett övergripande tema på ett gemensamt mötesställe och börjar med att brainstorma kring de exakta rubrikerna man vill ha workshoppar om.

Vårt övergripande tema var “följsam webb” eller RWD (Responsive Web Design), vilket innebär att man designar en webbsida som funkar olika och ser olika ut med olika skärmupplösningar. Det var ett mycket löst övergripande tema och väldigt få av workshopparna handlade egentligen om följsam webb. Temat valdes egentligen för att det är väldigt aktuellt och knyter samman alla deltagande bolags intressen.

När vi anlände till konferansen började vi med att skriva ner idéer till rubriker på stora, färggranna papper som sedan hängdes på väggen. Var och en fick sedan rösta på de rubriker som kändes intressanta genom att skriva sina initialer på lapparna. Till slut räknades rösterna och ett officiellt schema gjordes upp med de mest populära rubrikerna.


Här följer beskrivningar av några workshoppar som ordnades och som jag deltog i:

Öppet API

En av workshopparna handlade om APIer, dvs gränssnitt mellan data och applikation. Många av deltagarna, däribland också YLE, ansåg att de i framtiden kommer att föras heta diskussioner kring öppnandet av public service -bolagens data för offentligheten. Sveriges Radio har tagit ett av de första stegen och har sedan år 2010 ett öppet API som erbjuder vem som helst information om kanaler, program, avsnitt, låtlistor, nyheter osv. Vill vi t.ex veta vad som går på P3 idag öppnar vi URLen och ser ingen vanlig webbsida, utan ett XML-formaterat dokument med den önskade informationen.

Ett API innebär en mångsidig, väldokumenterad lista med kommandon (t.ex “scheduledepisodes” som ovan), som applikationsutvecklare kan använda för att utföra olika sökningar och komma åt olika listor i ett maskinvänligt format. När ett bolag öppnar sitt API på detta sätt, så tar man samtidigt bort alla hinder för andra utvecklare att utveckla egna tjänster som är beroende av bolagets data.

Jag har själv som programmerare kämpat med motsvarande problem utan API. För flera år sedan prenumererade jag på satellitkanalpaketet Viasat och fick förutom en massa filmkanaler också ett helt drös svenska tv-kanaler. Problemet var att Viasat i Finland inte hade någon programtablå och det var i praktiken omöjligt för oss i familjen att veta vilket program som går vid en viss tid på en viss kanal. Det enda jag kunde göra var att försöka tolka strukturen på HTML-koden på flera olika webbsidor med den information jag behövde och skriva ett program som “stjäl” informationen om tv-program och klockslag från de olika kanalerna och sparar dem i min egen databas. Mitt system gick ofta sönder pga att strukturen förändrades, eller pga att jag inte hade tolkat den rätt. Det var heller inte tal om att jag kunde publicera min egen tablå med “stulen” information för andra Viasatkunder i Finland.

Ett API löser det här problemet och ger mig ett löfte om kontinuerlig, väldokumenterad tillgång till programdata. Dessutom använder jag datan på ett sanktionerat sätt och behöver inte vara rädd för att sprida den vidare om licensen tillåter det. Ett öppet API ska dessutom per definition få användas fritt och informationen spridas vidare. Jag kunde t.o.m ta betalt för min Viasat tablå, bara jag tar betalt specifikt för appen och inte informationen.

SR erbjuder också tillgång till programinnehåll via sin API. Man kan t.ex lyssna live på deras radiokanaler (också i Finland) från URLen[channelid].mp3

… där man ersätter [channelid] med lämplig kanal-id. T.ex P1 har id 134 och vill man veta flera kanal-id:n kan man lista dem alla på adressen, som naturligtvis också är en del av APIt.

Vid vår workshop lyftes naturligtvis också flera orosmoment fram och det blev snart uppenbart att ett API inte är helt problemlöst. Det gäller helt enkelt att väga fördelarna mot nackdelarna. Ett problem som av vissa uppfattas som ganska allvarligt är att om vi öppnar tillgången till information så behöver man i princip inte besöka t.ex SR:s webbplats för att lyssna på radioprogram. Jag lyssnar t.ex på P1 medan jag skriver detta med en direkt länk jag fick från SRs API och i min bläddare ser det ut så här: En spelare på en i övrigt totalt svart sida.

Screen Shot 2013-05-06 at 6.05.41 PM

Utvecklare kallar detta fenomen för “cherrypicking”. Besökare kan välja det innehåll de vill ha och undviker eller går miste om allt annat innehåll, som t.ex puffar för andra kanaler, teasers för artiklar och helt enkelt resten av SR:s innehåll som live-radio användare förut har blivit mer eller mindre påtvingade. Det fanns ganska varierande åsikter om hur stort problemet egentligen är, men en ganska stark röst tyckte att det kanske inte ingår i public service uppdraget att styra folks konsumtion av information utöver vad det själva önskar ta del av.

Ett annat problem som togs upp var piratism: All data som öppnas kan stjälas, dvs sparas på den egna hårddisken och sedan spelas upp flera gånger, modifieras och t.o.m spridas vidare eller användas i egna produktioner. Somliga anmärkte att risken inte egentligen är större nu än förut: Live radio på internet har ju funnits långt före APIer blev aktuella. Ett API är egentligen bara en ny, välstrukturerad och väldokumenterad version av vad vi redan länge erbjudit.

En stor utmaning med ett öppet API är att det faktiskt ska vara det: Öppet. Det innebär inte bara att alla ska ha rätt till åtkomst, utan att åtkomsten också måste planeras i första hand för hela världen och först i andra hand för bolagets interna bruk. Ganska många bolag har börjat sin API karriär med att bygga interna verktyg utgående från en API filosofi och då går det lätt så att APIet måste designas om totalt när det öppnas för allmänheten. Ett API som i första hand tillgodoser interna behov fungerar inte tillräckligt allmängiltigt för att fylla den stora allmänhetens krav. Man kan alltid lappa på med nya funktioner och justera hur existerande egenskaper fungerar, men i många fall kommer man ganska snabbt till slutsatsen att man måste bygga APIet med öppenhet som grundförutsättning från början för att det verkligen ska vara öppet i alla avseenden.

Motståndare till öppna APIer kommer ofta med argument som till exempel kan verbaliseras med “dom stjäl vårt innehåll”. Då menar man att bolaget producerar en mängd fina program och annat innehåll som sedan tredje parter kan ta åt sig och paketera om, utan att behöva anstränga sig för att innehållet ska hålla god kvalitet. Ett gott exempel är när en tredje part gjorde en applikation för iOs som kunde spela upp SR:s radioprogram utan att SR hade kontroll över hur innehållet presenterades. Debatten destilleras ganska snabbt till frågan: Ska public service uppdraget inkludera kontroll av presentationssättet, eller är det viktigaste att informationen kommer ut till allmänheten? Om vi svarar ja på frågan, så måste vi acceptera det faktum att bolagets egen webbplats och egna appar någon dag kan överskuggas av en produkt som tillverkats och till och med säljs av någon tredje part som bara “lånar” vår data.

Avslutningsvis kan man säga att vi kom till ett konsensus om att det är väldigt bra och till och med viktigt att public service bolags information kommer ut så effektivt och transparent som möjligt. Det kändes som att så gott som alla deltagare har planer på att skapa någon form av öppet API i framtiden för att ge ut sin data. Tidtabellerna varierar, men kanske huvudsaken är att viljan nu finns, även på ganska hög administrativ nivå.

Avancerade Javascript applikationer

Följande workshop handlade om avancerade Javascript applikationer. Jag ska inte skriva så mycket om det, eftersom ämnet är ganska nytt för mig.

Med avancerade JavaScript applikationer menar man webbplatser som inte är traditionella sajter över huvud taget med förflyttning från sida till sida via länkar. I stället strävar dessa applikationer att ge användaren känslan av en s.k “desktop applikation”, vilket ibland innebär ett totalt nytänkande av funktionslogiken på webben: Man stannar i samma vy en stor del av, eller kanske till och med hela besöket och sidans innehåll manipuleras med hjälp av JavaScript. JavaScript kan kanske karakteriseras som ett lättviktar scriptspråk som ofta används i samband med HTML på webbsidor för att göra upplevelsen rikare. Det är t.ex ofta JavaScript som kollar att man fyllt i en valid epost-adress i något formulär på webben och sedan hindrar en från att skicka formuläret före man korrigerat adressen. Då man använder JavaScript till större funktioner kan det bli ganska komplicerat, inte minst för att olika bläddrare ska manipuleras på lite olika sätt. För att underlätta det här arbetet har man skapat olika JavaScript frameworks eller ramverk, som de heter på svenska.

Det finns nästan skrattretande många ramverk för JavaScript. Med framework eller ramverk menas en samling verktyg och kanske en användningsmodell för utförande av specifika uppgifter. Ett ramverk möjliggör inget som inte kan göras med “vanlig” JavaScript, utan paketerar endast funktioner som ofta behövs till ett lättanvändligt gränssnitt för utvecklare. På det sättet behöver inte varje utvecklare uppfinna hjulet på nytt. Ett av de absolut populäraste JavaScript ramverken heter jQuery och kunskaper om det är nästan ett grundkrav för webbutvecklare idag. Det är emellertid viktigt att inse att när man talar om dessa avancerade JavaScript applikationer, så är jQuery helt fel verktyg. Det innehåller helt enkelt inte de rätta hjulen som inte ska behöva uppfinnas på nytt. Vi måste i stället vända oss till ramverk som utvecklats specifikt för uppgiften. Som exempel kan nämnas ember.js och backbone.js.

Efter att ha undersökt Ember ytterligare på webben och läst några tutorials, så är jag ganska imponerad. Jag ser en väldig potential och ett ökande behov att göra vissa webbtjänster mera applikationslika. Ember inför en MVC (model – view – controller) paradigm på JavaScript nivå i webbutveckling och det är något som vi väntat på länge. Det som är lite förvånande är att det känns ganska tystlåtet kring både Ember och Backbone för tillfället. Det är som om de hade en lite mindre, väldigt trogen skara anhängare, men att det stora genombrottet ännu låter vänta på sig. Jag ska definitivt hålla ögonen öppna och överväga i vilka sammanhang man kunde dra nytta av den här sortens ramverk, men att t.ex konstruera hela sin webbplats kring en såpassny och kanske till och med marginell teknologi känns ganska riskabelt. Jag hoppas intresset ökar i framtiden.

Även i gruppen som samlades under knytkonferansen för att diskutera avancerade JavaScript applikationer var det ganska tystlåtet. Av drygt 10 deltagare fördes nästan hela diskussionen av två personer som hade tidigare erfarenhet av tekniken och resten var bara hälsosamt nyfikna på vad det hela egentligen handlar om. En viktig del av vårt arbete går ut på att undersöka och evaluera nya tekniker och i vilken utsträckning vi kunde ha nytta av dem i vårt arbete. I det ljuset var workshoppen långt i från onödig, trots att den utspelade sig på en tämligen abstrakt nivå för många av oss.

Public Service

Dagens sista knyt-workshop handlade om det public service uppdrag som nästan alla deltagare har gemensamt via sin arbetsplats.

Den här workshoppen förde diskussionen i en lite mindre teknisk och mera ideologisk riktning. Det var främst två ämnen som steg till ytan: För det första hade vi mandatet om public service i kristid och hur t.ex ett öppet API kan äventyra den servicen pga större risk för dataintrång. Det finns förstås ett argument för att den största säkerheten uppnås då man stänger av all åtkomst till ett system, men eftersom vår uppgift är förmedling av information, så är det inte praktiskt möjligt. Några portar måste alltid lämnas öppna.

En möjlig lösning, som inte kräver så tunga restriktioner är att splittra servicen och erbjuda t.ex ett öppet API via andra kanaler än den egentliga informationskanalen. Då störs inte den officiella informationskanalen i samma utsträckning om API systemet överbelastas på flit eller av misstag. Denna typ av redundans är enligt många säkerthetsspecialister närmast ett grundkrav. Man bör också komma ihåg att ett fullständigt slutet system inte är någon garanti för osårbarhet. Speciellt i kristid är det väldigt många länkar som är sårbara i kedjan: privatpersoners internetuppkopplingar, bolagens internetuppkopplingar, strömtillförsel osv. Därigenom känns det logiskt ohållbart att “stänga APIer för att kunna garantera funktion i kristid”.

Det andra ämnet handlade om insamling och användande av statisik. Grundproblemet är att det är förknippat med vissa ideologiska problem att samla in statisik om besökares aktivitet på en webbplats och sedan erbjuda datan åt allmänheten t.ex via ett öppet API. Informationen kan användas för kommersiella syften genom att företag profilerar användare och deras beteende. Om besökarstatistiken t.ex visar på ett kraftigt ökat intresse för motorcyklar, så kunde företag ändra på sin verksamhet och mera aggressivt börja marknadsföra motorcyklar och relaterade produkter för att därigenom öka sin försäljning. Ska public service bolag ens indirekt hjälpa kommersiella aktörer att maximera sin vinst?

En ännu allvarligare aspekt är att besökarstatistik som är tillräckligt detaljrik kunde användas för att identifiera enskilda besökare och därigenom analysera vilka sidor de surfat på. En lösning är att dels anonymisera data, men också presentera den endast i sammanfattad form, så att inte enskilda mönster så lätt kan utläsas.

Ett relaterat problem gäller överlåtande av data åt en tredje part som tillhandahåller en statistikservice. Med det menar man t.ex att ett public service bolag utnyttjar Googles eller någon annans statistiktjänst för att få fram data om vilka sidor som är populärast, vilken väg besökare navigerar och varifrån de kommer. Argumentet mot att använda t.ex Googles statistiktjänst är att vi ger Google ännu mera makt än de redan har om vi avslöjar exakt vilken trafik webbplatsen haft och exakt hur enskilda besökare rört sig från artikel till artikel. Den mängd information Google har gör att de mycket exakt kan profilera användare och presentera riktad marknadsföring med sina sofistikerade algoritmer.

Motsidan av argumentet är att det helt enkelt är nödvändigt att använda en tredje parts statistikverktyg om vi ska kunna få jämförbar statistik mellan olika bolag. Alla kan inte ha en egen statistikservice eftersom siffror mätta med olika metoder inte är statistiskt jämförbara och eftersom man till och med kan manipulera siffrorna för att visa den statistik som önskas.

Ett alternativ vore om en statlig instans erbjöd en officiell statistikservice i stil med Google Analytics, men som kunde garanteras vara icke-kommersiell. Frågan är då om allmänheten hellre överlåter sin statistiska data åt Google eller åt staten, “big brother”. Osökt återvänder man till tanken om att det bästa kanske ändå är att fullständigt transparent erbjuda samma data åt alla. Då vet var och en exakt vilken data som finns tillgänglig och hur den kan användas av olika intressegrupper.

Det anmärktes också att public service bolagen ju producerar sina tjänster med skattemedel och att allt som produceras: artiklar, program, webbplatser, statistik, mm. borde överlåtas helt öppet till folket som betalar för tjänsten.


Knytkonferansen var ett första experiment för att se hur den här typen av forum fungerar för att skapa intressanta och givande sessioner kring olika ämnen. Det känns som att väldigt viktiga och intressanta ämnen togs upp och att vi inte hade särskilt stora svårigheter att hitta de relevanta frågorna. Eftersom grupperna saknade ordförande hände det ofta att vi då den reserverade tiden tog slut märkte att vi hunnit diskutera endast några få frågor och att det kanske hade funnits flera viktiga ämnen att ta upp. En ordförande kunde ha reagerat då gruppen fastnat vid ett visst ämne för länge och styrt diskussionen vidare.

Som helhet var dagen lyckad och jag hoppas vi får chans att delta igen!


Workshop om public service. 

Jag, Joakim


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 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.