Från Java till Ruby på 12 månader

Under 2010 har vi i allt större utsträckning börjat använda Ruby som utvecklingsspråk istället för Java. Det är egentligen bara en av saker vi gör annorlunda idag jämfört med tidigare. I kväll kommer Brian berätta mer om hur det gick till och vad vi lärt oss på SHRUG under rubriken “J2EE to rails noob in 12 months”.

SHRUG – Stockholm Ruby User Group – ordnar oregelbundet träffar med presentationer och mingel och i kväll är det dags igen. Värdar är MyNewsdesk.

Förutom Brian kommer vi som är där också lyssna på:
– En månad av TextMate → Vim (Henrik Nyh)
– Request logging with MongoDB (Peter Marklund)
– Show off your data. Create a dashboard. (Richard Johansson / Jonas Forsberg)

Och sessionerna följs av ett block med “Vi söker folk” (det är ett oerhört sug efter Ruby/Railsutvecklare). Förra gången var det tre företag som aktivt sökte personal, jag gissar att det blir ännu fler ikväll.

Om ni ska dit ikväll – säg hej!

Praktik under 2011?

Vi håller på att skapa två stycken praktikplatser på avdelningen: en under våren och en under hösten 2011. Varje period kommer vara åtta-tio veckor lång.

Praktikplatserna är för oss ett sätt att få in personer som pluggar på yrkesskola eller högskola (enligt TV4’s policy) och som vill (och behöver) komma ut och skaffa sig erfarenhet i arbetslivet.

För oss som redan arbetar här är det ett bra tillfälle att ta del av ny färsk kunskap och nya synsätt och för dig är det förhoppningsvis en intressant upplevelse att få vara med “bakom kulisserna”. Som praktikant kommer du få vara med i utvecklingsteamet och bidra i projekt och verksamhet med planering, utveckling, förvaltning, möten och annat som är en del av vår vardag.

Vi har tidigare haft både praktikant och prao-elever här som arbetat med WordPress och med javautveckling. Vilken kunskap eller bakgrund vi söker har vi inte bestämt ännu, men när vi gör det i januari kommer vi berätta här om första praktikplatsen.

Låter det intressant? Hör gärna av dig redan nu. Och hjälp oss gärna genom att tipsa bekanta som ni tror är intresserade.

Snabba cash

Idag blev PaaS-företaget Heroku uppköpta av Salesforce för ungefär 212 miljoner US$ i kontanter. Heroku är ett 3.5 år gammalt företag med ungefär 30 anställda som driver en plattform för att köra Ruby-applikationer. Vi använder dem bland annat för TV4 Play och Väderkanalen.

Affären kommenterades av företagen i deras respektive företagsbloggar (Herokus här och Salesforces här) och bland annat Techcrunch hade en artikel om den. Kommentarerna är dels i form av ett stort GRATTIS till personerna bakom Heroku som på 3.5 år skapat en verksamhet som någon var beredd att betala nästan 1.5 miljarder SEK för, och dels lite blandade reaktioner på att det är just Salesforce som är köparen. Oron är att Salesforce ska förändra det som gör att användarna älskar plattformen: den enkla användningen, den tydliga prismodellen och den ständiga förbättringen. Men i blogginlägget är Heroku tydliga med att de tidigare planerna gäller framöver också och att namnet, personal, ledning osv kommer behållas och fungera precis som tidigare. Hur det blir får vi se i framtiden, men för säkerhets skull gjorde jag en skärmdump av inlägget så vi har något att referera till framöver.

För oss innebär affären inte någonting i dagsläget. Om det skulle visa sig att tjänsten försämras eller att det dyker upp något bättre alternativ kan vi lämna när som helst: all vår data är enkel att exportera, alla moduler vi använder är standardiserade och de resurser vi använder faktureras på sekundnivå utan några bindningstider. Vi behöver alltså inte sitta inlåsta och klaga över sakers tillstånd utan hittar vi något bättre så flyttar vi. Det är en av fördelarna med den här typen av tjänster och en av de egenskaper vi letar efter i partners och leverantörer.

”Things change, embrace it.”

Saker vi lärt oss om prioritering

Eftersom vi är en liten webbutvecklingsgrupp här på fyran har det alltid varit en utmaning för oss att välja vad vi ska göra och vad vi inte ska göra. Vi har många beställare från olika sajter med olika projekt och krav, men inte resurser till att jobba med mer än ett par projekt samtidigt. Den här utmaningen har förstås alltid funnits, men efter att vi börjat jobba mer iterativt och strukturerat har valen blivit synliga och vi har därför behövt göra tydligare och mer välmotiverade val. Här kommer några lärdomar vi dragit när det gäller prioritering.

Involvera rätt personer och tala om vem som står för prioriteringen
För oss var det viktigt att få med oss en person från beställarsidan i prioarbetet som kunde ta beslut på en övergripande nivå. Innan beställarsidan själva var med och tog ansvar för helheten hamnade vi ofta i rättviseprioritering där alla intressenter skulle få lika mycket tid snarare än att vi gjorde vad som var viktigast just nu. När vi väl fick med någon med helhetsansvar från beställarsidan blev det lättare att välja bort saker och få tydligare fokus på vad som är viktigast. Det blev också tydligt för beställarna på våra olika sajter vem de skulle prata med för att kunna påverka prioriteringen.

En grupp behövs för att göra en prioritering, men bara en kan ha sista ordet
Det vore orimligt att låta en person göra hela prioriteringen. Ingen har så bra koll både på verksamhetens behov och tekniken att de kan ta ansvar för helheten på egen hand. Samtidigt är det svårt att som grupp välja mellan flera lika viktiga projekt. Vi löser det genom att vi i utvecklingsgruppen grovprioriterar tickets per projekt och resonerar oss fram till ungefär i vilken ordning saker bör göras. Sen får den ansvarige från beställarsidan välja mellan projekten och göra de svåra affärsmässiga val som ibland uppstår.

Var tydlig med vad som planeras i sprintarna
Inför varje sprint listar vi vad som ska utvecklas i en punktlista så att beställarna kan se vilka tickets som finns med. Vi skickar också med en förklaring i löpande text om hur vi gjort prioriteringen och vilka projekt och sajter vi fokuserar på under sprinten.

Var lika tydlig med vad som väljs bort
I ovan nämnda mejl listar vi också de puckar som är viktiga men som ändå hamnat utanför sprinten. Innan vi började lista vad som valts bort trodde beställarna ofta att deras punkt tappats bort vilket ökade stressen både hos dem och hos oss som fick ta emot upprörda mejl och samtal.

Hitta en gräns för när något är så akut att prioriteringen måste ändras
Akuta fixar dyker ju alltid upp, och då gäller det att bestämma om vi ska släppa det vi har för händerna för att ta itu med saken eller om den kan vänta.  En bra utgångspunkt i de situationerna har varit att jämföra med den aktuella priotavlan. Är det viktigare att få ut fixen snabbt än att hinna med de tickets som sitter längst ner på priotavlan? Ofta blir valet enkelt när man jämför.

Synliggör konsekvenserna när prioriteringen ändras
De gånger vi väljer att klämma in något i prioriteringen under pågående sprint är vi också noga med att kommunicera ut vad som fick prioriteras bort för att få igenom snabbfixen.  För oss har den kommunikationen gjort att snabbfixarna minskat rejält.

Dribbla inte med tickets som ändå aldrig kommer att hinnas med
Det är lätt att tickets blir liggande vecka efter vecka trots att man inser att de aldrig kommer att hinnas med. Såna tickets gör prioarbetet onödigt krångligt och skapar samtidigt en falsk förväntan hos beställarna att jobbet snart ska utföras. Är en ticket för lågt prioriterad för att rimligen komma med i prioriteringen de närmsta tre-fyra sprintarna är det bättre att ta bort den, så får man skriva en ny ticket om den blir aktuell igen.

Alla ovanstående lärdomar handlar egentligen om öppenhet och tydlighet. Ju bättre vi blivit på att vara raka och tydliga med prioriteringen desto mindre tid har vi behovet ägna åt argumentation och snabba fixar, vilket har gett oss mer tid till utveckling.

Fler visningar i bruset på Play

Idag släpptes första numret av DN:s iPad-anpassade version, kallad DN+. Den bygger på plattformen News+ från Bonnier som har ett uttalat mål att liksom  papperstidningen ha en början och ett slut (50 sekunder in i presentationsfilmen). I TV-världen vill vi istället locka till fortsatt tittande och det finns inte någon självklar början och absolut inte något slut.

Därför har funktionen för att titta vidare i TV4 Play varit central. När man tittat färdigt på ett klipp eller program så vill vi tipsa om andra program som tittaren kan vara intresserad av.

Det finns två viktiga beståndsdelar i en sådan funktion:

  1. Få ut relevanta klipp
  2. Presentera på ett förståeligt sätt

Det första görs idag genom att visa fler program/klipp i samma kategori som det klipp man för tillfället tittar på. I första hand de som är från samma program men i annat fall sådana från samma kategori eller genre.

Det senare handlar mycket om att göra det lätt att förstå i vilken ordning klippen visas. Klickar jag för att titta på ett annat klipp bör inte förslagen på liknande klipp ändras alltför mycket eftersom chansen är påtaglig att man vill titta på ytterligare klipp som visades i listan första gången.

Det finns en del corner cases som varit lite luriga att lösa. Om vi visar sex klipp åt gången i vyn och det finns åtta klipp, ska vi då visa de sista klippen ensamt? Vi vill ju att användaren ska ha flera alternativ men samtidigt att funktionen ska bete sig förutsägbart.

När vi pratade om det i somras blev det snabbt tydligt att det blir alltför abstrakt att bara prata om utan att använda sig av visualiseringshjälpmedel. Då kommer kontorsprylarna snabbt till hjälp. Inplastade papper får bli avgränsare och våtservetter bli till klipp.

utveckling

Fortsätter sedan diskussionen på annat ställe i kontorslandskapet så är det istället postit-lappar som får tjäna som avgränsare och whiteboard-pennor blir klipp.

Utveckling del 2

Ute på webbplatsen kan nu funktionen se ut såhär (när det finns fem klipp in alles):
Titta-vidare-modul i TV4 Play