Talare: Jon Skeet

Om konsten att tala och kommunicera om kod utan kod. Underhållande session där Jon delade med sig om hur han som person och utvecklare (pedant och ibland nitisk) försöker  kommunicerar på ett trevligt sätt. Hur kan man vara uppriktig och tydlig utan att vara otrevlig?

1) Var snäll, tänk på kunskapsnivån hos de utvecklare du talar med och sätt dig in i personens situation (annars vill de inte tala med dig)

2) Linda in budskapet något genom att vara medveten om detaljerna när du berättar hela bilden.Tala på rätt nivå om rätt saker.

3) Både i tal och skrift, tonen och presentationen. Konkreta detaljer väcker starka känslor, information på övergripande nivå skapar förståelse.

Talare: Matthew McCullough

Med tanke på att vi använder Sonar för kodanalys redan idag så lyssnade jag på Matthew och hans tankar kring hur man kan börja använda verktyget på ett inspirerande sätt. Matthew talade om Sonar som en verktygslåda som ger kvalitet under kontroll och visualiserar data både för management (grafer) och utvecklare (kod)

Quality Metrics
Sonar hjälper oss att ha rätt mål i sikte på en långsiktig basis, Det är bra att se verktyget som ett sätt till feedback och temperaturmätare av allt bra förbättringsarbete vi gör i teamen. Hur ofta analysen bör ske, på vad och när får vi prova oss fram till.

Varför behöver man då inspektera och mäta?
– Få ett visuellt beslutsunderlag mot beställare, varför vi bör avsätta mer tid till teknisk skuld.
– Vi kan agera på siffror, inte enbart på magkänsla och slumpvisa mål vid beslut om förändringar.
– Verktyget ger oss stöd hel vägen från visuella grafer ner till kodnivå, att förstå och visualisera data.
– Bra översikt och kategorisering av olika typer av data (The Metrics, Unit tests, Duplication, Code styling, FInd bugs)
– Sonar kan integreras med Eclips för att köra analysen inom Eclipse direkt på kodbasen för att göra det enklare att arbeta med dagligen.

Sonar ger oss möjlighet att se tydligare utfall i arbetet med att underhålla koden och se var och på vilken nivå vi kan göra våra insatser. Vi kommer kunna följa den positiva utvecklingen och se vad som händer med kodbasen när vi förändrar sättet vi arbetar på ex. sprintlängden, antal driftsättningar, tester, code review, unit tests, buggrättningar etc. Följ förbättringarna och analysera över tid så att vi behåller det som vi gör bra och får effekt.

Hur använder vi Sonar idag och på vilket sätt kan vi använda verktyget på avdelningen för att visualisera det vi är bra på och hitta mönster för vidare utveckling och förbättring?

Med Jim Webber.
DDD fokuserad crash course I Rest design. Jim går igenom best practices för att skapa ett fungerande API.
Använd länkar i responsen för att underlätta vidare navigering. Event feeds istället för bus eller kö infrastruktur. Sprids med fördel som atom-feeds. Passar inte så bra för realtids applikationer.

Mike Brittan berättar om hur Etsy tvingades att arbetar med flera olika verktyg och förbättrade processer i utvecklingsarbetet när teamet växte med 500% över 18 månader.

E-handlelssajten krävde enormt mycket snabbare och kvalitativ produktutveckling och Etsy hade behovet av att hantera snabbare deployer och minska riskerna.

Idag sker deploy till produktion (inkl. build to stage) via en enkel knapptryckning. Det krävdes för att man ska kunna göra ca 40 deployer /dagen som idag är snittet samt att alla på avdelningen (designer, backend och frontendutvecklare) kan utföra en deploy.

Less talk, more do
För att komma fram till den nya processen så pratade man i tydligare termer om att arbetet skulle fokuseras mer på att bygga mer kod och utvärdera arbetet i efterhand och faktiskt göra deployen. ”Always be shipping code” (även om det är din första dag), refakturera något releasebart varje vecka.

Förutsägbarhet
Problem uppstår alltid, det gäller bara att hantera riskerna. Då kan man vända risken till förutsägbarhet och tillit i systemen och applikationen ex. med monitorering på flera nivåer.
Om man uppmärksamma problem snabbt så att man kan agera direkt. Trygghet ger självförtroende.

Monitorera mera
Samla data för att visualisera och analysera arbetet i processen. Vad gör vi bra och vad gör vi mindre bra? Varje dag förändras allt i systemen, därför behövs en detaljerad monitorering och trendanalysvid dagliga deploys.

– Application metics: Hur mår applikationen, bildladdning etc.
– Business metrics: Hur ser trafiken ut, unika besökare, laddningstider, betalsystem, login etc
– System metrics: hur mår servrarna, databaserna, connections etc

Hantera risker
– Metrics (nyckeltal)
– Code reviews, storlek på ändring innan deploy
– Automatiserade tester, classer, unittests, selenium, funktionstester och integrationstester.
– Config Flags (enable and disable feautures quickly) sätt på/stäng av utan driftsättning på vilktiga core-funktioner
– Plus ”admin -Only”, procent ramp-up, A/B tesing, whitelist, blacklist etc.

Failure is inevitable – Visualisera
Bättre med flera små iterationer. Bryt ner alla problem och hantera dessa. Bättre med många små risker ofta än en stor. Operations och utvecklarna arbetar nära med produktutveckling, nya funktioner för att få förutsägbarhet i metrics.
Se det som en lärande process i misslyckande. Varför gick sajten ner, problem med databasen? Vad lärde vi oss av det och hur hanterar vi det i framtiden
Access, vad händer och hur ser det ut – visa med grafer på skärmar.

Övervakningsverktyg
Bygg upp monitoriering tillsammans med utvecklingsteam och operations.
Det är ett krav i Etsys team att metrics är en del av varje feautre samt configflags i alla releaser. Alla ska ha access till loggarna.

Verktyg som Etsy använder för monitorering:
Cacti (Nätverk)
Ganglia(Maskiner)
Graphite(Applikationer)
Splunk(Loganalys, Nightly report)
Nagios(Alerting)

Mer info
github.com/etsy
codeascraft.etsy.com

Visuell monitorering är alltid positivt och 40 deployer om dagen låter spontant mycket men med mer automatisering och förbättring av testprocesser med ex. selenium och verktyg för kodanalys så är vi en god bit på väg.

Talare: Avi Muchnick (Aviary, inc)

Communication is key
Prata med produktägare om förändring och kravställning. Ta reaktioner vidare för ändring och skapa tidslinjer. Informera alla i företaget om att arbetet pågår

Vad vill användaren ha? Fråga!
Användaren som stannar på nya sajten kommer att anpassa sig. Men det är viktigt att man får tid att experimentera med nya designen. Användaren behöver också full åtkomst till den gamla saiten utan restriktioner.

Checklista inför redesign

• 60-dagars transtionspersiod
• Side-by-side reviews
• Non-committal try before bying
• Social pressure – missar jag något?
• Incitament: badges
• Rollbackplan and capabilities

En smidig övergång är viktigare än en deadline! Lyssna på feedback från användaren
”Deadline can be deadly” – Håll tidsplaner flexibla för justeringar från användare.

Redesign i verklighenten
Avi visade några exempel på redesign av stora sajter och reflekterade över varför vissa lyckades bättre än andra.

Digg.com, Myspace.com, Worth 1000 är exempel på sajter som förlorade många besökare trots ganska små förändringar vid sitt senaste redesignarbete. Gemensamma faktorer som ex. begränsad feedback loop, borttagning av populära features och avsaknad rollbackplan gjorde att man tappade användarna under redesignarbetet.

Drudgereport.com är ett exempel där man tvärtom ökar trafiken utan att ändra designen på flera år.

Facebook har lyckats med kontinuerlig redesign när det gäller tänket ”Side by-side”. Som användare behöver man inte kommita sig direkt och anamma den nya desingen. Dessutom är det Avi kallar ”social pressure” och ”no choise in the matter” hög.

När är en redesign lämlig?
När det är designen som är trasig. Om den är trasig, se till att fixa den!

Talare: Phin Barnes (First Round Capital)
http://www.web2expo.com/webexny2011/public/schedule/detail/20778

”The question entrepreneurs and investors have to answer is no longer “can this be built and by who?” but, “should this be built and for who?”

”Problem solving is driven by insights and understanding, product testing through rapid prototyping and iteration, iteration, iteration.”

The web is waking up to design
Design driver finansiellla resultat. Förstå din användare och prioritera det i arbetet. Ändra mindset ”Customer first”.  Förut tävlade vi olika tekniker men nu är designprocessen eller så kallad Lean startup i agile utveckling den avgörande faktorn för att behålla användarna och klara konkurrensen i framtiden.

När building blocks och verktyg finns tillgängligt för alla så är det  designen som gör skillnaden. Quick builds! Vi använder fler färdiga tjänster (Saas, Paas, Iaas etc) vilket gör att vi behöver skilja ut oss i designen och inte enbart i tekniken.

Sätt användaren i fokus
Den som lyckas erbjuda den bästa lösningen och designen till kunden blir en vinnare.
Se till att vara nära dina användare och förstå behovet. Tillåt alla i organisationen att kunna förverkliga och genomföra ideer, de förstår sina användare. Bygg en kreativ och förlåtande kultur för att alla ska kunna genomföra sina idéer. Hylla hantverket som på ex. Etsy!

Collaboration: samarbeta kring ex. en träningsvideotjänst. Personlig tränare sitter tillsammans med utvecklarna och bygger den bästa upplevelsen.

 ”Design is the competivtive advantage”

Det förutsätter förstås att tekniken och tjänsterna( applikationen) fungerar i övrigt och här är det också den totala lösningen och upplevelsen som gör skillnad, inte enbart designen.

Presentationen börjar med en intressant bild över State of (mobile) web development 2011.

Javascript –  det är där det händer. Påminner om att vi måste satsa ännu mer på det området. Återigen hamras det in att mobilen kommer att gå om desktop inom några år. En annan trend är att HTML5 ökar i popularitet i förhållande till Objective-C.

Exempel på appar byggda i HTML5: Facebook, Netflix, Zynga, Sports Illustrated.

Några ord om Open Source: embrace (dont replace), contribute (dont fork) & promote (inga hemligheter).

Använd ramverk och bygg inte allt från början (JQuery, Dojo etc).

Apps vs Mobile webb?
Vi behöver både närvaro i appstore och ha en mobilsajt. Använd samma kodbas.

Sammanfattning i korthet: bygg app:ar i HTML5 och inte Native Apps.

Mer info
html5rocks.com
diveintohtml5.org 

Talare: Nate Bolt (Bolt|Peters)
http://www.web2expo.com/webexny2011/public/schedule/detail/21258

Hur bygger vi bra saker för våra användare? Nate pratar om enkelheten i att använda olika verktyg i researcharbetet för att få feedback och kommunicera med testgrupper och besökare i utvecklingsprocessen.

Research and Creativity
Det pratas ofta om research inom marknad men vi bör fokusera ännu mer på research inom User Experience. Det finn flera olika verktyg som hjälper oss i analysarbetet och dessa ger oss bättre beslutsunderlag i utvecklingsprocessen. Arbeta med prototyper, Wireframes & Sketches.

2 principer
#1 Kombinera online metoder – det finns många bra
#2 Tid är allt

Man kan skapa och mäta upplevelsen på olika sätt och med olika verktyg.
Insikt, statistik, betraktelse. Olika verktyg för olika syften. Definiera ditt behov! Heatmaps för att fånga beteenden kopplat till frågeformulär.

Vem testar vi på?
Hur hittar vi en grupp med personer som vi kan testa på i reseaarchsyfte?
– Någon utanför, vänner, riktiga kunder, panelundersökningar, gruppmaillistor
usertesting.com tillhandahåller testpersoner. Det finns många bra alternativ.

Hur kan vi använda det här?
Hitta ett verktyg som passar för behovet och börja testa det tidigt i planerings- och designfasen. Det kommer förhoppningsvis ge oss bättre beslutsunderlag och trygghet i att vi utvecklar applikationer som våra användare vill ha, förstår och kan använda.

Det här låter som ett intressant verktyg http://www.dscout.com/
Anpasssat för App driven research
”capture user experiences in context and in the moment, describe, design, invite”

Tips på fler verktyg: http://remoteresearch.ch/tools
Automatiserade remote research tools (Usabilla, Loop11, Plainframe)
Usability tests: Låt användaren klicka runt, mät, följ upp med heatmap. Verktygen tillåter feedback kopplat till händelser.

Kompenserade gårdagens kalla macka med en kvalitetslunch

Wikipedia om ”Sashimi” i Scrum (små bitar av komplett funktionalitet)
”Sashimi is a report that something is ”done”. The definition of ”done” may vary from one Scrum Team to another, but must be consistent within one team. ”
http://en.wikipedia.org/wiki/Scrum_(development)

Sam Ramji från Apigee höll en föreläsning om strategier för API:er. Många bra tankar.

RAMVERK FÖR API-STRATEGI (modifierad för att passa AB)
1. Vad vill vi uppnå? Motivera och förklara.
– effektiv utveckling av nya och befintliga tjänster
– leverera innehåll i fler kanaler
– publikt API (steg 2)

2. Target your Developers
Utvecklingsspråk: Facebook oväntat stora, PHP enormt stort, Javascript stort och ökande.

Publik eller privat – Öppet eller Stängt? Vi börjar privat och stängt.

3. Sätt mål, metrics och KPI:er
För internt API blir det en annan typ av mål än ett publikt. Exempel: antal app:ar, developer satisfaction, användning, antal anrop etc

4. Sätt en roadmap för utvecklingen
– vem gör vad?
– prioritering?
– tidsplan

5. Manage the API Program
– vem ansvarar för API:et?
– hur underhåller vi och utvecklar API:et?
– hur följer vi upp nyttjande?
– hur prioriterar vi utveckling av API:et?
– utbilda och motivera

Idé: API-team med övriga utvecklare som beställare.

Roller: Developer Envangelist (intern), Developer Advocate (hur ska vi bygga)

Men först: utred vilket eller vilka ramverk som passar oss bäst. Bygg inte saker som redan finns.

TO DO #1: Definiera hur vårt API ska se ut (behövs olika för artiklar och recensioner t ex)
TO DO #2: Inventera vilken information vi har
TO DO #3: Kolla upp Apigees tjänster och andra som t ex Mashery