Touch me – I wanna feel your body eller hur man effektivt jobbar digitalt med Kanban

Som bakgrund till detta inlägg kan nämnas att vi har en ödmjuk inställning till agil metodik på Aftonbladet IT-utveckling och inser vikten av att kväsa scrumtalibanism och uppmuntra förenklingar, nytänkande och förändring.
Då jag tog över rollen som scrum master (kanban master?) i vårt maintenance team – Superteamet – hade vi Jira som ärendehanteringsystem tillsammans med en klassisk white board (för översikt och morgonmöten) med post-it lappar av blandad kvalitet. De ”vanliga” post-it som ramlar ner vid minsta vinddrag (läs chefen går med långa ben förbi tavlan), super-sticky som visserligen sitter bra men är så eftertraktade på kontoret för sin fästande förmåga och klara färger att de raskt försvinner. Och sen har vi Bootlegvarianten… Den som den stackars ovetande kontorsmaterielinköpsansvarige i god tro och med sparivriga förtecken (”titta, man får TRE block med ful-post-its för samma pris som för ETT original!”) köpt in i ovisshet om dess utomordentligt usla egenskaper som post-it lappar och som har den inbyggda egenskapen att ramla ner i exakt det ögonblick man vänder ryggen till. Till detta lapphelvete kan läggas min medfödda aversion mot slumpmässigt monotont arbete (skriva lappar i takt med att ärenden kommer in via email till Jira) i kombination med den tankspriddhet som kanske främst min sambo beskyller mig.
Vid ett extra förvirrat morgonmöte där jag trots ansträngning inte fått alla lappar i rätt kolumn och swimlane slängde ut frågan, utan hopp om medhåll – om teamet kunde tänka sig en digital tavla – och fick det av sarkasm drypande svaret ”Visst, om du fixar en stor touchskärm så…”, så föddes idén – varför inte? Närmsta chefen var oväntat positivt inställt till tankeexperimentet så jag började undersöka vad som finns på marknaden. Ganska omgående framgick att stora touchskärmar inte direkt är en konsumentprodukt och att tjänster som prisjakt och pricerunner inte var till någon hjälp. Här gällde det att ta nästa steg – kavla upp ärmarna, klistra på sin mest uttråkade min och utrusta sig med en hel ryggsäck tålamod – möta hungriga säljare som lovar runt och håller tunt… Samtliga skulle enligt utsago stödja Mac OSX – något som i slutändan begränsades till att stödja enbart single touch på Mac medan drivrutinen för Windows kunde hantera två punkter. På frågan varför fick jag till svar från en återförsäljare ”99 % av våra kunder har Windows”. I wonder why – kanske för att ni inte stödjer Mac OSX? Nederlaget att, hos Macfrälse, behöva använda Windows späddes på en aning när jag insåg att Internet Explorer var den browser som fungerade bäst i touchläge. Skillnaden mellan singel och två punkters touch illustreras bäst genom att jämföra Macbooks touchpad med gamla tiders styrpinne och höger och vänsterknapp. Med touchpaden och tvåpunkter touch zoomar man, scrollar och går framåt respektive bakåt i en browser med två (eller tre) fingrar. Med styrpinnen och singelpunktstouch måste men styra muspekaren till den knapp eller funktion som hanterar detta. Nå, efter en del turer som involverade några veckors provande av olika storlekar och modeller mynnade det hela ut i att 65″ var en optimal storlek, dels nog stor för att ett team om 6-8 personer ska kunna samlas kring den, och dels en storlek som tillverkas i tillräckligt stora volymer för att komma ner i pris. Valet av leverantör föll på en utan lokal närvaro men med upplevd god service, acceptabelt pris och med den skärm som enklast klarade av att byta dator (operativsystem), något som två andra skärmar föll på då man var tvungen att både hårdvaru- och mjukvaruresetta skärmen vid byte mellan Mac och PC.

För att ytterligare effektivisera vår Kanban funderade vi en hel del på hur workflowet skulle se ut i Greenhopper och stödja oss i det dagliga arbetet. Ett stort problem som identifierades var att många ärenden inte kunde utföras av en eller annan anledning, t.ex. för att vi visste/misstänkte att ärenden inte borde utföras då de eventuellt stred mot uppsatta designprinciper eller att de berörde etik och policys utanför avdelningens beslutanderätt. Dylika ärenden blev brus i inkorgen i väntan på utredning. För att minimera den störningen skapade vi en kolumn till VÄNSTER om inkorgen dit vi drog ärenden som bör utredas av produktägare.


I och med att nya Greenhopper stödjer swimlanes kunde en fastlane- (expedite) och fixed date-swimlane skapas för att lyfta upp ärenden med sådana karaktäristika.
Funktionen ”Quick Filters” där man kan skapa filter och lägga över sin Kanbanvy – t.ex. ärenden ”äldre än en vecka” har vi ännu inte utnyttat till den potential jag tror den har, men det kommer kanske.
Nu, några veckor efter inköpet och förändringarna i Kanbanflödet kan vi sammanfatta de första intrycken:

  • Ärenden i synk – Eftersom synkronisering mellan jira och tavla sker automatiskt har en del tid sparats in men framförallt har frustration över osynk eliminerats.
  • Ärendeflöde – Då vi alla ser alla ärenden som ligger och skvalpar i In Progress och On Hold har vi fått bättre fokus på att slutföra ärenden, från ca 20-25 ärenden i dessa statusar till 5-10.
  • Prioritering av ärenden – Tack vare Greenhopper och nytt workflow har prioritering av ärenden underlättats

En och annan teammedlem med farhågor att det strul som varit ledstjärnan under utvärderingen skulle permanentas blev successivt övertygad om skärmens förträfflighet och nu törs jag nog säga att ingen vill återgå till den manuella tavlan.

Mona Lisa vid touchskärmen

Och så levde de lyckliga i alla sina dagar.

Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

Mobilism: the good parts

Förra veckan var det mobilism, en konferens med diverse ”mobilt”
innehåll. Här kommer en snabb sammanfattning av ett par av mina favoriter. (Läs mer…)

Inlägget är publicerat i Mobilism 2012 | Inlägget har kommentarer

Hackday #8

Igår och idag har vi genomfört Aftonbladets Hackday, den åttonde i ordningen. Även övriga bolag inom Schibsted är välkomna och vi har därför döpt om eventet till Schibsted Hackday. Hashtaggen på twitter är #hackday8.


Många valde att testa olika idéer kring mobilt vilket är glädjande då vi står inför en ombyggnad och stor utveckling av mobilsajten och våra mobilatjänster. Några testade Spotifys app:ar andra olika ramverk. Visuella demos varvades med kod som sig bör på en Hackday.


Precis som tidigare blev resultatet av hackandet mycket inspirerande och innovativt. Känslan efter en Hackdaydemo är alltid lika härlig och optimistisk och det är fantastiskt kul att se alla idéer som finns på avdelningen.


Här följer en lista över vad våra utvecklare på Aftonbladet presterade på Hackday#8:

Oscar Thiel – geo-taggade artiklar
Thomas Granström & Henrik Tengelin – Offlinecachning i mobilen
Kenneth Ocklund – Spotifyapp för Nöjesbladet
Peter Björkman – Alternativa sätt att rendera webbsidor med Knockout.js
Thomas Thyberg – Enhetstestning på Android
Fredrik Wärnsberg – Bättre mobila gränssnitt
Peter Sjövall – SPiD och inloggning via API
Tobias Järlund – CoverItLive i mobilen
Patrik Linderl – Heroku och Continous Deployment
Daniel Färnbo – Responisve design i Viktklubb 4.0
Fredrik Forsberg – Spotifyapp för Nöjesbladet
Tobias Genberg – Automatisk kapacitetshöjning för mobilsajten vid stora nyhetshändelser
Fredrik Johansson – Social Reader Facebook
Joakim Norrinder – Bättre användarupplevelse mha minifiering av javascript och css:er
Håkan Jacobsson – Ramverk (Sencha) för att utveckla mobilsajter och app:ar

Hur tar vi då alla idéer vidare? En del går direkt in i våra ordinarie backlogs och prioriteras där. Vi provade förra gången att också låta en jury utse de bästa bidragen som sedan presenterades för redaktionsledning och andra intressenter för att få ytterligare återkoppling och prioritering. Så även denna gång.


Hackday har verkligen landat bra och jag rekommenderar alla bolag att testa liknande koncept för att släppa lös innovation och nytänkande. Tack Anders, Sara, Daniel, Erik och alla som jobbat hårt för att göra det här möjligt. Jag ser redan fram emot nästa Hackday.
Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

Friendly iFrames på mobilsajten

Att mobil.aftonbladet.se inte alltid är världens snabbaste mobilsajt att ladda är ingen hemlighet. Ibland kan det kännas som att sajten ”står och tuggar” så snart den första annonsen har börjat läsas in. Anledningen till detta har dryftats tidigare här på utvecklingsbloggen. Kortfattat kan man säga att document.write() (som vi använder för att rita ut annonser på mobil.aftonbladet.se) är tråkigt av flera anledningar, men framför allt är javascript som gör document.write() för att skriva ut ytterligare <script>-taggar ”mitt på” en sida trist då det tvingar webbläsaren att vänta tills det att javascriptet har körts färdigt innan utritningen av sidan kan fortsätta. Detta är givetvis illa nog i en ”vanlig” desktop-webbläsare, men det blir riktigt tråkigt om man surfar med en mobiltelefon som har en taskig 3G-anslutning.

Ett sätt att komma runt denna problematik är att använda sig av s.k. ”friendly iframes” för annonser, något som vi har gjort ganska länge på www.aftonbladet.se. För att illustrera problemet, och samtidigt visa på hur friendly iframes kan rädda situationen, skapade jag en extremt långsam annons, som tar 6 sekunder att ladda (övriga sajten fick dock tuffa på som vanligt), och kortslöt annonsystemet så att jag fick den långsamma annonsen på varje annonsposition. Jag spelade in lite video av hur en (simulerad) iPhones MobileSafari beter sig utan, och med, friendly iframes.

I och med att laddningen av flera annonser kan ske parallellt om man kör med friendly iframes blir inte bara den upplevda laddningstiden för sajten kortare, utan också den faktiska laddningstiden. Man bör notera att detta exempel är väldigt tillskruvat för att illustrera nyttan med friendly iframes, detta är ingenting som man faktiskt råkar ut för på mobil.aftonbladet.se.
Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

7 saker

Sven Peters

Sven Peters från Atlassian  berättade på Jfokus sina tankar runt vad man kan göra för att motivera utvecklare och utvecklingsteam. Sammanfattningsvis har Sven sju olika områden med tips som kan göra bra team ännu bättre. Nedan finns en lista med dessa. Inom varje område finns ett betyg (ett plus till fem plus, fem är bäst) som anger hur väl Aftonbladets utvecklingsavdelning lyckats inom området. Betyget är ett medelbetyg baserat på en omröstning bland utvecklarna. Kommentarerna är mina personliga reflektioner.

1. Flow – att kunna fokusera
Skapa ”stör-ej” tid
Det ska vara möjligt att stänga in sig i ett rum för att kunna jobba ostört
Sluta läsa e-post vissa tider
Se till att inte hela teamet avbryts utan ha en person som tar all ”support” under en dag

Aftonbladets utvecklingsavdelning: ++

Kommentar: Vi sitter i kontorslandskap vilket har många fördelar men det försvårar möjligheten att arbeta något så när ostört. Vi har experimenterat en hel del med hur vi ska hantera support för att teamen ska få jobba mer ostört.

2. Kompetensutveckling
Delta på Konferenser, barcamps, open space-konferenser, utbildningar, user groups, kod-dojos
Anordna interna träffar med presentationer och filmvisningar

Aftonbladets utvecklingsavdelning: ++++

Kommentar: Vi jobbar kontinuerligt med personlig utveckling där kompetensutveckling är en stor del. Vi har satsat på konferenser och utbildningar. Jfokus, Öredev och Web 2.0 Expo är några av de konferenser vi återvänder till. Men en stor del sker på initiativ av Aftonbladets utvecklare själva, t.ex. interna kompetensträffar, filmvisningar och besök på user groups osv.

3. Beröm/uppskattning
Visa uppskattning även för små framsteg
Beröm någon inför andra
Fira framgångar, stora som små

Aftonbladets utvecklingsavdelning: ++++

Kommentar: Vi jobbar med feedback och firar gemensamma framgångar, tex lanseringar. Genom att vi som avdelning varje vecka summerar vad vi gjort på våra veckomöten så blir det fler tillfällen för beröm. Det är också viktigt att andra avdelningar känner till vårt arbete. Därför jobbar vi nu med att sprida mer information om vad vi gör internt.

4. Visualisera mätetal

Samla så mycket data som möjligt: antal möten i veckan, ok byggen, tid att bygga, testserver prestanda, antal user stories, velocity, cycle time, lead time, supportärenden, kundnöjdhet
Det är viktigt att rapportering och rapporter är så automatiserat som möjligt

Aftonbladets utvecklingsavdelning: ++

Kommentar: Vi använder Bamboo och Sonar för att samla och rapportera information runt byggen av system. Vi följer även upp ”nöjd-sprint index”, en variant av happiness index

5. Testa internt
Låt ditt företag testa det som utvecklas först
Snabb feedback, effektiv testning
Ökar kunskapen om produkterna och användarna internt

Aftonbladets utvecklingsavdelning: +++

Kommentar: Detta är något som vi jobbar mer och mer med. Varje team testar förstås själva men det finns många på andra avdelningar som går in och testar. Vi kan dock bli bättre på att göra det oftare.

6. Hackday
Samla ett gäng utvecklare och ge dom fria händer att på kort tid utveckla något intressant och användbart
Det måste finnas mycket godis, jolt-cola och pizza
Utvecklarna visar på kort tid vad de gjort på en demo

Aftonbladets utvecklingsavdelning: +++++

Kommentar: Detta har vi lyckats bra med. Vi har genomfört sju hackdays och tagit evenemanget till ett koncerngemensamt event. I mars genomför vi vår 8:e hackday.

7. 20 % tid
För att städa upp, fixa bugar och refaktorera
För att labba och testa nya tekniker

Aftonbladets utvecklingsavdelning: ++

Kommentar: Vi har tid avsatt för att labba men det är svårt för utvecklarna att få tid till detta. För hantering av teknisk skuld har vi testat olika alternativ men här kan vi bli bättre.

Här finns länkar till Svens presentation:
http://www.jfokus.se/jfokus/talks.jsp#7%20Things%3A%20How%20to%20make%20good%20teams%20great
http://www.jfokus.se/jfokus12/preso/jf12_7Things-HowToMakeGoodTeamsGreat.pdf

Inlägget är publicerat i Jfokus2012 | Inlägget har kommentarer

Jfokus 2012: 3 x Continuous och annat

Jag tror att Jfokus kan bli en stor miljöförkämpe framöver. Om de håller årets nivå eller bättre finns det helt enkelt ingen kunskapsmässig anledning längre att resa långt för att få kompetent och inspirerande info som Java (JVM-baserad?)-utvecklare i Stockholm. Här nedan har jag summerat mina intryck – som inte alls är heltäckande förstås för konferensen. Jag är trots allt bara en enkärnas CPU och skalar dåligt till flera lokaler.

CONTINUOUS
Ett av ledorden på Jfokus var Continuous. Det togs upp på flera plan och jag tolkade dem så här:

- På ett högre plan är Continuous Delivery (CDiv), vilket är löftet om att leverera produkter affären behöver (inte att förväxla med vad de vill) när det är affärsmässigt lämpligt. I praktiken innebär det att produkten alltid är redo att produktionsättas, men affär beslutar när nya produkter/features publiceras. Tekniskt kan det åstadkommas genom att produktionsätta med feature toggles (funktioner som kan slås av/på) eller dark launch (t ex backendfunktionalitet som inte syns)

- För Continuous Deployment (CDep) är fokus att få ut ändringar i produktion så fort som möjligt med så lite motstånd som möjligt. Det innebär att alla ändringar produktionsätts direkt efter rigorösa automatiska tester. Ändringarna är så små att risk för fel i produktion minimeras. Man rullar aldrig tillbaka utan driftsätter istället bättre kod. CDiv är i praktiken CDep fast det är ett affärsmässigt beslut att trycka på deploy-knappen när ändringar samlats ihop till något vettigt (minimal marketable feature)

- Continuous Integration (CInt) har fokus i början av leveranskedjan (delivery pipeline) där varje ändring som checkas in i källkoden plockas upp av byggserver, genomgår tester och resulterar i distributioner som kan driftsättas automatiskt i testmiljö och automatiskt/manuellt i produktionsmiljö. CInt är alltså en förutsättning för CDep och CDiv

Rådet som alla ger är som vanligt ”gräv där du står”. Börja automatisera det du kan från vänster till höger – bygge, test, driftsättning i test/prod, mät och följ upp. Här kan konceptet DevOps hjälpa till, vilket i stort sett går ut på att riva muren mellan utvecklings- (devs) och driftavdelning (ops). Det kan vara en person som funkar som en brygga mellan dessa eller ett förhållningssätt, t ex att en ops är med i projektteamet.

Det finns förstås flera utmaningar med detta – t ex att gå från arkitektur (svårt att ändra) till design (lättare att ändra), kunna ändra databaser och snabbt kunna sätta upp korrekt infrastruktur. Några tips som gavs var:

- Se leveranskedjan från idé till produktion som en kostnad och jobba för att få ned denna kostnad till ett minimum

- Dela upp system i komponenter som kan driftsättas oberoende av varandra. Det är ok att inte dela domänobjekt eftersom olika system använder dessa på olika sätt. Dela gärna på use case istället för domäner, t ex en service /user blir svår att hantera när det används både av admin (inlåst, 5 användare) och huvudsajten (publik, miljoner användare). Pröva /useradmin och /useraccount istället, ”Working complex systems comes from simple systems that work”

- Standarisera på data och protokoll (inte SOAP som tyvärr exponerar implementationen) istället för plattformar.

- Använd verktyg (t ex http://liquibase.org/) för att underlätta evolutionära databaser, d v s hantera ändringar på ett kontrollerat sätt

- Inse att ops-resurser (Operational Expenditure, OPEX) också är en kostnad, precis som inköp av infrastruktur (Capital Expenditure, CAPEX). Det är dumsnålt att inte investera i system och verktyg för att snabba upp leveranskedjan. Att ägna dagar/veckor åt få upp en korrekt konfigurerad server istället för på 5 minuter blir hög OPEX. Framför allt blir det också enkelt och snabbt att återhämta sig från en infrastrukturkrasch

- Använd verktyg (t ex http://puppetlabs.com/) för att automatisera hur infrastruktur sätts upp. En ny server ska vara ett knapptryck. Viktigt att versionshantera de script som beskriver hur infrastrukturen sätts upp

Källor:
- Continuous Delivery, Neal Ford, ThoughtWorks – http://www.jfokus.se/jfokus/talks.jsp#Continuous%20Delivery
- Agile Architecture, Marcus Ahnve, Valtech – Design For Replaceability – http://www.jfokus.se/jfokus/talks.jsp#Agile%20Architecture%20-%20Design%20For%20Replaceability.
- The road to REST, Rickard Öberg, Neo Technology – http://www.jfokus.se/jfokus/talks.jsp#The%20road%20to%20REST
- Retrospective from the year of DevOps, Daniel Fröding, Diabol AB – http://www.jfokus.se/jfokus/talks.jsp#Retrospective%20from%20the%20year%20of%20DevOps

ÖVRIGT
Vad gäller webbsidan ser det ljust ut för Java. Webbramverket Play fångade mycket intresse på Jfokus och verkar ha alla möjligheter bli förstavalet i branschen framöver, förutom kanske i Spring-lägret. HTML5 börjar bli bara HTML i de flestas ögon, även om implementationen de nya API:na i webbläsare släpar efter. Ett av undantagen ser ut att vara localStorage som stöds av de flesta och används flitigt redan.

Nu har konsekvenser av att deploya appar i molnet börjat dyka upp och även lösningar på problem som det medför. Aktörer som VMWare genom cloudfoundry.com försöker göra plattformen portabel, medan initiativ som jclouds.org försöker göra appen portabel mellan molntjänster (PaaS i det här fallet) genom att abstrahera bort plattformen. Kritik mot CloudFoundry finns att det inte är riktigt öppet förrän det är open source, medan jclouds får höra att deras modell inte räcker, eftersom de tjänster som molnen erbjuder (data store, jobs, queue, etc) har så olika karaktär att de inte går att generalisera. En sak som eldade på diskussionen om portabilitet var när Google App Engine blev aggresivare i sin debiteringsmodell. Just nu är det svårt att flytta från en leverantör till en annan.

Det var hyfsat högt intresse för Scala (ca 6 föreläsningar) tillsammans med funktionell programmering. Det får också lite draghjälp av Play (särskilt som version 2.0 RC släpptes i dagarna) som är Scalas hemmaplan. Andra intressanta saker som kanske inte var nya är Akka (händelsedriven, skalbar och feltolerant arkitektur – http://akka.io) och Hadoop (distribuerad skalbar processing – http://hadoop.apache.org).

Källor:
- Building a web page with HTML5, Robert Nyman, Mozilla – http://www.jfokus.se/jfokus/talks.jsp#Building%20a%20web%20page%20with%20HTML5
- Patterns of Agile Enterprise Architecture, Rebecca Parsons, ThoughtWorks – http://www.jfokus.se/jfokus/talks.jsp#Patterns%20of%20Agile%20Enterprise%20Architecture
- Client-side Storage: When & How, Pamela Fox – http://www.jfokus.se/jfokus/talks.jsp#Client-side%20Storage%3A%20When%20%26%20How
- An Intro to Hadoop, Eva Andreasson, Cloudera – http://www.jfokus.se/jfokus/talks.jsp#An%20Intro%20to%20Hadoop
- Functional Thinking, Neal Ford, ThoughtWorks – http://www.jfokus.se/jfokus/talks.jsp#Functional%20Thinking
- HTML5 with Play Scala, CoffeeScript and Jade, Matt Raible, Raible Designs – http://www.jfokus.se/jfokus/talks.jsp#HTML5%20with%20Play%20Scala%2C%20CoffeeScript%20and%20Jade
- Up and out: Scaling software with Actors, Viktor Klang, Typesafe – http://www.jfokus.se/jfokus/talks.jsp#Up%20and%20out%3A%20Scaling%20software%20with%20Actors
- Developing portable PaaS applications, Andrew Phillips, jclouds – http://www.jfokus.se/jfokus/talks.jsp#Developing%20portable%20PaaS%20applications
- One-liners are your friend: Increasing Productivity with Scala, Thomas Alexandre, DevCode Consulting – http://www.jfokus.se/jfokus/talks.jsp#One-liners%20are%20your%20friend%3A%20Increasing%20Productivity%20with%20Scala

Inlägget är publicerat i Jfokus2012 | Inlägget har kommentarer

Jfokus 2012: Det var det

Functional Thinking, Neal Ford, ThoughtWorks, Inc

Neal Ford är alltid intressant att lyssna på.
I den här föreläsningen påpekar han att man kan tänka funktionellt i vilket språk som helst.
Det finns en hel del man kan göra direkt, som t.ex att göra funktionerna fria från sidoeffekter, dvs. ge sjutton i att hålla ett state utanför funktionen och se till att funktionens enda resultat är returvärdet.
Om Oracle får till tail-call optimization i Java 8 så kan vi också börja skriva mer recursiv kod…

HTML5 with Play Scala, CoffeeScript and Jade, Matt Raible, Raible Designs

Det verkar som om Matt fick lägga ner merparten av sin tid på att få ihop alla ramverk och hjälp-bibliotek. Kanske hade gått snabbare att göra själv.

Up and out: Scaling software with Actors, Viktor Klang, Typesafe

En räsergenomgång av Akka 2.0. Funkade bra för mig som en liten doft av vad Akka är för något, eftersom jag i princip inte visste något annat än att det är en implementation av ”The actor pattern”, typ.
Jag har förstått att det är ett problem för Node.js-användare att hantera fel, speciellt att hålla reda på att något gått fel och sköta någon slags damage-control och självläkning. Känns bra att Akka-utvecklarna verkar ha tagit ett ordentligt grepp kring detta.

It Is Possible to Do Object-Oriented Programming in Java, Kevlin Henney, Curbralan

Ja det går att skriva objekt-orienterad kod i Java. Tror jag.
Problemet är att det är lätt att gå bort sig och förstöra inkapslingen genom att t.ex. låta främlingar känna till för mycket om dina objekts interna uppbyggnad.
Java är ju extremt flexibelt så man kan ju göra lite hur som helst…

Regex Applied – When Regex is a Winner, Staffan Nöteberg, Rekursiv AB

En grundläggande kurs i regexp. Lite för basic för mig men den gav mig i alla fall insikt att det finns en massa mer jag kan lära mig om regexp.
Är kanske dags att köra ett kunskapslyft?

Developing Mobile Web Apps with PhoneGap, Pamela Fox

Pamela är som vanligt insatt och kärnfull och radar upp alla valmöjligheter som finns om du vill skapa en app för flera olika mobila plattformar, t.ex.
* Koda native. – Mycket dubbelarbete, koda i Java, Objective C, C++, .NET
* Metaprogramera mot ett API som i sin tur kompilerar till native
* Metaprogramera mot ett API som i sin tur kör i en virtuell maskin som skickas med appen
* Gör en web-app som kör som en webview i en liten omslutande native-app
Hur gör vi?

Cool Code, Kevlin Henney, Curbralan

Jag gillar verkligen att lyssna på insatta akademiska analyser om konsten att programmera.
Kevin är kunnig och underhållande.
Det var en bra avslutning på en lyckad konferens.

Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

Jfokus, tisdag kväll…

En bra dag på en välorganiserad konferens.

Enterprise Java in 2012 and Beyond, Juergen Hoeller, SpringSource

VMware-kille som hade en hel del bra iaktagelser om vartåt java och webben verkar vara på väg.
Lite svag som keynote dock, för trist och för mycket VMware-pitcning.

The Kotlin Programming Language, Andrey Breslav, JetBrains

Ett nytt funktionellt språk för JVM:en.
Den vanligaste frågan JetBrains får är inte oväntat:
Varför?!
Enligt Andrey är Scala så komplicerat att det är i stort sett omöjligt att ge programmeraren ett vettigt stöd i IDE:n.
Kotlin ska lösa de vanligaste problemen kring java, t.ex.
* Mycket boilerplate kodning
* Concurrency är svårt
* NullPointerExceptions
* Förenkla och förkorta standardkod en programmerare skriver om och om igen
* mm
Detta utan att bli överkomplicerat.
Kanske kommer en beta ut i slutet av 2012.

CoffeeScript: JavaScript without the Fail, Bodil Stokke, Steria

Mycket bra och underhållande dragning om varför coffeescript finns och hur det ser ut i förhållande till javascript.
Bodil har sin ”facial hair theory” om varför javascript blev så fel.
Den går ut på att alla tidigare bra språk (Lisp, C, C++, Java, etc.) skapades av gubbar med skägg.
Men Brendan Eich var slätrakad när han skapade javascript…
Nåväl. Jag är ingen fan av meta-språk. Ofta tycker jag de handlar om utvecklare som försöker få ett nytt språk att se ut som något annat gammalt språk som de är vana vid.
Jag tycker inte heller det är så stor poäng med att ta bort semikolon, brackets, braces mm.
Det är inte där man förlorar vare sig tid eller överblick när man programmerar.
Å andra sidan hjälper Coffescript dig att inte göra en massa av de standardmisstag som är så vanliga när man skriver javascript och som kan ge väldigt jobbig felsökning.
Så jag är inte helt negativ.

Client-side Storage: When & How, Pamela Fox

Fantastiskt bra dragning om hur man kan spara data hos klienten i html5.
* Cookies, the god old way
* localStorage, name/value i en nyare variant med större möjligheter och utan att skicka en massa
data fram och tillbaka i http-headern
* IndexedDB, mer riktig databas med index, sökningar och asynkrona anrop
* fileAPI, spara ner filer lokalt, även binär data som bilder etc.
Än så länge finns ju bara stöd för cookies och localStorage (utom Chrome som har en första variant av IndexedDB på plats) så vi får vänta på det göttaste.
Men med hjälp av bibliotek som abstrahera bort en del browser-quirks så kan man använda localStorage redan idag.
Bra. Bara att sätta igång.

Vad Clojure lärt mig om objektorientering (som jag inte lärt mig av Java), Ville Svärd, Agical AB

Clojure är något annat. Ett funktionellt språk utan klasser har fått Ville att se med nya ögon på inkapsling, polymorfism och arv. Lite för kort dragning för att även jag skulle bli upplyst.

The Curious Clojureist, Neal Ford, ThoughtWorks, Inc

Det är så härligt, som gammal tcl-programmerare, att se ett språk som bygger på listor!
Inte tusen regler och reserverade ord och massor av syntax, bara en lista som börjar med ett funktionsnamn och sedan kommer indata vacker uppradat. Det är skönhet.
Blir nästan sugen att pröva.

JavaScript bonanza – the modern developer story, Björn Ekengren, Diversify

Ingen vidare dragning, tyvärr. Björn visade en JSF kontra en AJAX-lösning av en TODO-applikation, plankad från TODO-MVC. JSF:en åkte på stryk.
Inga nyheter där.
Bra listning av en massa ramverk för DOM, MVC, Testning etc.
Fast det kan man ju lätt hitta på nätet.

Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

Lärdomar & inspiration på Dagsvara

WAN-IFRAs konferens Dagsvara har precis gått av stapeln. Det var ett lyckat arrangemang där programgruppen, bestående av bl.a. Emanuel Karlsten, fått ihop ett inspirerande program. De flesta av talarna höll hög kvalitet och Anette Novak imponerade som moderator med vältajmade frågor.

Först ut var Georg Konjovic, Premium Content Director på Axel Springer. Det är lätt att känna sig obetydlig i jämförelse med en så gigantisk koncern, men Konjovic levererade mycket att inspireras av. Springers har ett hälsosamt perspektiv på sin egen verksamhet: “Papper är bara ett medium, det är innehåll som är vår business. Digitalt kan vi nå ut till fler kunder”. Med det synsättet på den egna verksamheten går man förhoppningsvis inte samma öde till mötes som Kodak.

Konjovic ifrågasatte också om vi verkligen behöver utgivare i en digital värld. “Är utgivaren som växeltelefonisten?” Han menar att det alltid kommer finnas ett behov för en medlare mellan innehåll och läsare, men att medlaren inte nödvändigtvis är en utgivare (publisher). Att konkurrensen inte längre enbart är från andra mediahus utan i minst lika hög grad från företag som Apple, Google och Facebook var också något som vår it-chef Peter Frey tog upp i sin presentation.

En satsning från Axel Springer att hålla ögonen på framöver är “MyEdition”, en aggregerad och personaliserad nyhetstjänst för iPad som nu håller på att betatestas. Tjänsten är ett samarbetsprojekt med andra utgivare där användaren väljer bland olika titlar för att skapa sin alldeles egna unika läsupplevelse.

Ett annat gigantiskt samarbetsprojekt är slovakiska Piano Medias gemensamma betalsystemsportal för nyhetssajter, inspirerat av betalmodellen för kabeltv. Tidningarna som deltar får betalt då deras innehåll konsumeras, det är tid spenderat på sajten och lockandet av nya kunder som ger utdelning. Inloggningen är extremt enkel, berättar VD Tomas Bella: “Vi bryr oss inte om demografi, bara om betalningsuppgifter. Systemet berättar sedan vilka de är genom hur de uppför sig.”

Ett annat tema som kom upp i flera presentationer var hur mycket det finns att tjäna på att använda tjänster som redan finns, gärna gratis och gärna i molnet, istället för att bygga eget eller köpa in dyra produkter. Per Åström, it-chef på TV4, berättade om hur de jobbar så, med motiveringen att “ju mer grejer man använder färdiga tjänster för, ju mer tid kan vi lägga på det som är unikt för oss”.

Andreas Ehn och Magnus Hult (båda Spotifygrundare) från WRAPP är inne på samma spår, och använder färdiga tjänster för allt från mejl till bugghanteringssystem: “Vi använder massa coola grejer som finns. Det är bekvämt att slippa ha servrar, det spar utvecklar- och systemtid.” Lista på tjänster att inspireras av, som används på WRAPP: Airbreak, NewRelic, Papertrail, Github, Google apps, Dropbox, Flowdock, Ducksboard, Asana, Get Satisfaction och Assistly. För den som inte känner till det är WRAPP en tjänst där man kan köpa digitala presentkort för att ge till Facebook-vänner.

Dag 2 rymde bl.a. en tankeväckande diskussion utifrån frågeställningen “Vad gäller när ett mediehus förmedlar sina tjänster och produkter med hjälp av molnet?”, med Claes Magnusson från Malmö Yrkeshögskola, PO Ola Sigvardsson och Bonniers kreativa chef Fredrik Strömberg. Riskerna för t.ex. källskyddet är uppenbara, men samtidigt erbjuder molnet fördelar som är svåra att låta bli att ta del av. Genomtänkta avtal är ett sätt att kontrollera riskerna. Ett par av leverantörerna, som fanns i publiken, poängterade att de kan erbjuda servrar som garanterat står på svensk mark.

Det här var bara ett axplock av presentationer, det fanns många fler att inspireras och lära av. Inte minst var det också trevligt att mingla med branschkolleger.

Tack WAN-IFRA för en välarrangerad konferens! Till nästa år vore det också trevligt om vi fick se fler kvinnliga talare.

Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer

Kvalité lönar sig

Vid utveckling av mjukvara och datorsystem är det tyvärr så att den negativa effekten av allt för mycket fokus på utveckling av funktion ofta förbises. Vid prioritering räknar man endast med kostnader som har att göra med den tid det tar att utveckla och testa funktionen och inte med kostnader sett till hela livscykeln. De senare kostnaderna är ofta relaterade till icke-funktion som dokumentation, utbildning, drift- och utvecklingsprocess, spårbarhet, överskådlighet, testbarhet, enkelhet vid vidareutveckling, kostnader för driftstopp etc. Alla dessa är exempel på värden som är svåra att formulera och ofta inte ingår i kraven.

När dessa värden inte prioriteras uppstår en teknisk skuld. Ett system med hög teknisk skuld är svårt att underhålla, utveckla och använda. Ju högre teknisk skuld desto högre kostnad är associerat med brandsläckning, utbildning, felsökning, drift etc. Paradoxalt nog innebär det alltså att en upp-prioritering av funktion resulterar i en ned-prioritering av den samma eftersom mer tid går åt till de nyss nämnda sysslorna.

På Aftonbladet har vi just inlett ett projekt för att amortera på den tekniska skulden. Lösningen är att systematisera, automatisera och förenkla processer kring utveckling och drift. Vi vill t.ex. säkerställa att alla projekten tillämpar automatisk kodgranskning, att vi genererar dokumentation från inställningsfiler för att slippa hålla wikisidor i sync m.m. På så sätt får vi mer tid att implementera funktioner med hög kvalité!

 

Inlägget är publicerat i Okategoriserade | Inlägget har kommentarer