Agila Sverige 2013

No Gravatar

Sitter på tåget på väg hem från Agila Sverige 2013. Det har varit två underbara och uttröttande dagar, med mängder med trevligt, kompetent folk, bra blixttal och öppna, givande diskussioner och dialoger.

Egna insatsen

Fredrik Wendt: Coding Dojos för företag
Jag var först ut, hade inte presentatörsanteckningarna framför mig vilket var tvärtemot vad jag fick mail om dagen innan, men bortsett att det blev lite mindre fokuserat och tydlig röd tråd så tror jag att det viktigaste sades.

Open space-session på temat “Hur lär man ut TDD?”

(Kallas också rundabords-diskussioner, ofta utan bord.) Jag deltog i ett par open space (kallades open X)-sessioner men förde bara anteckningar från en där frågeställningen var Hur lär man ut TDD? Det var inte jag som som föreslog ämnet men deltog och försökte erbjuda så konkreta tips på idéer till den/de som sökte svar och inspiration eller bara nya (eller gamla) tankar.

  • + training, education
  • ? how do I get colleagues to see the benefit of it?
  • ! forced for a short period where you see the end of the period, one sprint/2 weeks
  • ! re-allocate some of the devs to a team where TDD is heavily used
  • ! move away from too simplistic katas, people have a too hard time transfering what they’ve seen/learned to production (Emily: this was NOT me saying this, brought up by someone else based on experiences from other teams and devs! :-)
  • ? hard to start when what you’re starting your journey from/off of/on/what you have is untestable legacy code
  • ! book: M Feather’s Working With Legacy Code
  • ? more on what’s the benefit of TDD in your view?
    I answered that almost everyone agree that pre-production tests, such as a unit test suite, is of great value.
    If you use TDD as means to get more readable, usable, understandable, maintainable code – then that’s your benefit. But it’s not the only way to get there, TDD is not the silver bullet solution to everything.
  • ? what are the arguments against TDD?
    Can’t use it blindly, might be hard transition/initially. Should/may not be used for spikes.
  • ! book: Kent Beck’s Test-Driven Development by Example

Övriga personliga diverse anteckningar och doodles

Ann-Louise Ulfsparre och Fredrik Josliden: Kommunikation mellan team, javisst! Men, hur då?
Story points samma mellan team? Grooming utan O? Slå ip team fungerade bra. Skall prövas!

Johan Dewe: Så fick vi alla att räcka upp handen
Om att rulla ut agil utvecklingsprocess utan att kalla den agil. “Roll your own vs try what’s been known to work”?
Rubrik “att få alla att räcka upp handen”, efter en egen introduktionskurs (liknande CSM dag 1, PSF, …) med folk från blandade verksamhetsfunktioner så fick alla frågan “Vilka håller på med systemutveckling?”. (Alla förstod sin del och att det var en del av det hela.)

Jonas Hermansson: Acceptanstest är töntigt
Acceptanstestare är ofta för välbekanta med testobjektet – fundera över vem som gör acceptanstestet och konsekvenser av det. Mycket humor, kul presenterat! En klar topp 3 för mig.

Kajsa Goffrich: RTFM – varför är vi så snåla med kunskap?
Vi håller inne med kunskap som Joakim von Anka håller sina pengar i sin pengabinge, varför? Agil metodik leder till att vi jobbar öppet och talar ut om “jag har kört fast, tar tid, har problem”, men hur bemöts det? Vilken inställningar har vi till detta? “Jag har blockering – skall givetvis ses som att det teamet som har en blockering, inte en individ”. “Jag är inte korkad, jag har bara inte lärt mig det än”.

Inga-Lill Holmqvist: Servant Leadership – passar bra ihop med Agile och Lean?
Att tänka “du är viktigare än jag”, som chef. Mät: “Växer personen som jag servar?”
Aktivt lyssnande; Empati; Läkande; Awareness (self, organizational); Bygga konsesus vs auktoritativ beslutsfattande; Foresight; Stewardship (översattes till förvaltarskap :-P ); Bygga gemenskap (community).
(Ja, allt detta passar mycket bra ihop med Lean och Agile.)

Matti Klasson: DevOps – ett sätt att samverka inte en jobbtitel!
Mixade team, praktisera i annan roll. Automatisering och verktyg är inte lösningen – lösningen är samverkande människor.

Annica Söder och Anna Forss: Hur vi undvek att bygga Dödsstjärnan
Jämförde Star wars- och Star Trek-stil, dvs magi, hjältar och ikoner med vetenskapliga teorier, samverkan och team.
10000 stormtroopers vs teamet “on the bridge”; Yoda vs Spock (mer vetenskapligt); dödsstjärnan vs enterprise (doable scope); mötet där Darth nästan stryper en amiral vs star trek-öl i restaurangen på skeppet (refletion meetings)
Seldon plan.

Thomas Nilsson: 13 steg mot Kanban Kaizen
Kändes lite för basic, men passade säkert många andra. Bra take away: se till att välja ord – det är lättare att “genomföra ett litet experiment under 2 veckor” vs “nu skall vi förändra våra arbetsmetoder”.

Annika Widmark: Om att lösa komplexa problem med enkla bilder
Storytelling, visualisera förändringsarbetet. Gather facts, group facts, imagine goal, show/visualize/draw. En av flera presentationer som tycker att tre kugghjul visar på något som snurrar (tre kugghjul som rör varandra kan aldrig snurra).
Glömde fråga om de foldrar som tagits fram hos Arbetsförmedlingen om erfarenheter om bra metoder/framgångar från projekt har lämnats ut publikt (tillbaka till skattebetalarna).
Bok: Back of the napkin, Dan Roam

Daniel Fröding: Continuous Delivery – On the road to a true agile company
itrevolution.com. Bra budskap. Använde karaktären Mr Business som gav beståeende men/intryck ;-)

Labbet – Continuous Delivery Pipeline

Andra halvan av dag ett var open X och jag valde att spendera tid i “labbet” med bl a Mattias Karlsson, Mikael Sennerholm och Johan Elmström från Avega Group (Enzo). De hade med ett par saker in, dvs förberett ett par saker såsom CI-, test- och prod-VM:ar, (Jenkins, Tomcat, Puppet, GitHub) men framför allt härlig öppenhet och vilja att lyckas utan att ta för mycket fula genvägar.

I korthet så fick vi något som fungerade, men ingen av oss helt “färdiga” (uppstädning) och ej heller helt nöjda med teknikstacken. Jag skall kanske inte tala för de andra men Jenkins och sina plugins (jag läste källkod också för att fixa en bugg) lyste inte direkt upp tillvaron, erhöll glada tillrop eller större uppskattning. Inte direkt någon överraskning för någon av oss, men nu är det iaf gjort en gång så det kommer från erfarenhet! :-)

Dag 2

Andra dagen förde jag inte anteckningar då jag hoppade fram och tillbaka mellan blixttal och labbet där vi fick den enkla Continuous Delivery-pipeline att snurra (Spring Petclinic, Puppet, Fabric, Razor, VMware, Python/bash, Jenkins). Bamboo, Go och Team City plus en mindre hög andra saker att kika på eller göra bättre fanns på ena kylskåpsdörren (bra yta för statisk plast = mobil whiteboard).

Gabriel Falkenberg: Jakrakning på rätt sätt
Mycket underhållande och träffsäkert. Om du skall raka jak, raka rätt jak, raka den rätt, … Klart topp 3 även denna.

Adam Killander: Fundamentalistisk förvaltning
Bra teatralisk berättandestil om förvirringen kring nyproduktion vs förvaltning. (Nyproduktion kanske finns första sprinten på ett nytt projekt, men inte efter det.)

Någon gång under dagarna gjordes en jämförelse mellan Legacy inom och utanför mjukvaruvärlden – i det ena en tillgång med värde, i det andra ses det mer som en belastning och kostnad.

dev:mobile 2013

No Gravatar

Tillsammans med Göteborgs utvecklarcommunity  arrangerar Squeed för andra året mobilutvecklingskonferensen dev:mobile. Årets konferens bjuder på inte mindre än 12 presentationer samt keynoten “Panel reflection about the future of mobile platforms from a developers perspective”.

Flera kända företag kommer och håller presentation som bla Spotify, Microsoft, IBM, Opera mfl.

Och det bästa av allt med en konferens som arrangerar av användargrupperna i Göteborg är att det är helt kostnadsfritt att delta! Anmäla och mer information finns här.

Se Google I/O Extended med Squeed

No Gravatar

Squeed bjuder in till Google I/O Extended i Göteborg


Om du inte har möjlighet att åka till San Francisco för Google I/O så är det här chansen för dig att vara med på distans. Vi kommer att äta lite mat och titta på keynoteen från Google I/O. Vi håller till i Squeeds lokaler på Södra Larmgatan 4 Karta

Agenda

17:00-18:00 Öl och pizza och mingel
18:00-20:30 Google I/O Keynote (streamad från USA)

Anmälan via Javaforum

Code review? (nforum 23 April – Göteborg)

No Gravatar

Har du länge drömt mardrömmar om din kod? Eller kanske du är en av dem som önskar att Code Review var en del av er arbetsprocess? Kanske du redan har sådan process? Mattias Jiderhamn från B2B företaget Expert Systems i Alingsås kommer och gästar nforum den 23 april och delar med sig av sina idéer och tankar kring just detta ämne.

Personligen är jag förvånad över att det är så få företag som lägger energi på att införa alla dessa mjuka ting i sina arbetsprocesser. TDD, Code Review, Acceptans Review m.m. Oftast brukar det bero på att de som bestämmer inte själva vart kodare och eller så finns det brister i förståelse för vad en bra process faktiskt innebär.

Jag kan förstå denna sits samtidigt som jag är stor motståndare här. I min värld har jag alltid strävat efter att det inte finns något som heter övertid, det finns inget som heter buggar m.m. Vi vet alla att det visst finns det men om du envist inte vill tillåta dem för dig själv och samtidigt även vill kunna utföra ett bra jobb kommer du automatiskt som programmerare hela tiden tvinga dig själv att hitta de effektiva och smarta vägarna att gå för att just slippa sitta över, slippa buggar m.m. Du nyttjar TDD, du tänker en extra gång innan du hackar din kod. Du bollar idéer med dina kollegor, du ber någon kollega i smyg kolla på din kod m.m. Vi brukar oftast bli kallade de Pragmatiska utvecklarna. Tycker dock det är synd att det inte direkt ligger lika mycket fokus på de Pragmatiska säljarna, de pragmatiska kunderna mot utvecklarna.
Många processer försöker men allt för många förstår inte processerna i sig. De tror oftast det bara är för utvecklarna skall hinna göra med features och missar att de själva egentligen också ingår i processen.
Känslan på en bra konferens brukar i många fall vara ”Det är fel folk som sitter här, vi kan detta, synd våra chefer inte är här och lyssnar på detta, det är de som behöver denna kunskap inte vi…” Du känner igen dig va? Tänkte väl det.

Jag fick höra en skrämmande historia en gång.
Köparen: Vad är detta? Test 40timmar? Code Review 10h? Det har jag aldrig betalt för förut, stryk det.
Säljaren: Ok.

Ta ansvar, stå på dig, kan du inte övertala din överman, gör bevis på att dina idéer faktiskt ger värde.
För så länge du kan leverera lufttid och inte siffror är du oftast rätt rökt. Dvs. kan du inte bevisa att det ger effektivitet kommer du heller inte få till det, då extra arbete (som de ser det) ökar bara deras siffra med den tid som redan finns, de ser sällan att tillägg drar av tid.

Andra ämnen vi tar upp på nforum den 23 April är TypeScript med John Tjust från oss på Squeed.
Även Filip Ekberg gästar oss med att prata om Async i C#.

Vi ses, anmäl dig på nforums egna sida.
www.nforum.se

Mvh Johan

Continuous Delivery

No Gravatar

Fredrik Normén på Squeed kommer den 30:e April att prata om Continuous Delivery och hans erfarenheter kring området i det projekt han sitter i just nu för ett finansbolag. Ni kommer att få grundläggande förståelse kring begreppet Continuous Delivery, samt hur Fredrik och hans team har valt att lösa vissa problem i sitt utvecklingsteam, allt från process, källkodshantering, branchning, automatisering etc,  detta med hjälp av Microsoft Team Foundation Server 2012 och NuGet samt andra verktyg och hack!

Detta är ett event via Swenug som sponsras av Squeed AB.

Anmäl er här:

http://www.swenug.se/events/gbg-continuous-delivery

Global Windows Azure Bootcamp på Squeed HQ

No Gravatar

Lördagen den 27:e Apirl kommer Global Windows Azure Bootcamp att genomföras runt om i världen, över 90 st platser. Vi på Squeed tillsammans med SweNug har valt att sponsra och vara med och arrangera denna bootcamp i Göteborg. Det blir en dag med labbar, så ni som är nyfikna på Windows Azure så är detta är ett bra tillfälle att få möjlighet att testa på och labba med Microsoft cloud services.

Vi börjar kl 10:00 och håller på fram till kl 15:00.

Det finns dock bara 20 platser, så försten till kvarn.

http://www.swenug.se/events/global-windows-azure-bootcamp

TDD-kurs, våren 2013

No Gravatar

Squeed bjuder in till en ny omgång av kursen i testdriven utveckling (TDD). Denna omgång av kursen vänder sig till dig som är Java-utvecklare och nybörjare inom TDD-området. Kursen omfattar fem tillfällen om ca två timmar där du kommer få praktisk erfarenhet av att utveckla kod testdrivet.

Upplägget med datum (spikat) och ämnen (lite mer rörligt) ser ut så här:

tors 25 april, kl 16-18: TDD, basics
mån 13 maj, kl 16-18: TDD, test backlog och “enough upfront design”
tors 23 maj, kl 16-18: TDD + OO, classical approach
ons 5 juni, kl 16-18: TDD + OO with mock framework
tors 20 juni, kl 16-18: [något av: Clean Code, Mockist approach, BDD, three-clause style, Refactoring]

Kursen, som är gratis och har plats för 10 deltagare kommer hållas på svenska och leds av Fredrik Wendt, Niclas Åstrand och Peter Kristoffersson. Vi ger förtur för nya deltagare och du kan anmäla ditt intresse genom att fylla i ett enkelt formulär för intressanmälan.

Strategy X vs Y

No Gravatar

X vs Y

Skrev nyss om agila affärer och länkade till Thoughtworks sida där de beskrev hur de lämnat det så organisatoriskt skadande sales commission-tänket. Av en händelse läste jag idag två X vs Y-inlägg hos Fog Creek (folket bakom Trello, Stackoverflow, “Joel on Software” etc) och det första var på just ämnet “Why do we pay sales commision“. De drar slutsatsen att det kommer från två olika synsätt på sina anställda:

Theory X which assumes that people are lazy, want to avoid work and need to be controlled, coerced, punished, and lavishly rewarded in order to perform.

Theory Y which assumes that people are self-motivated, derive satisfaction from their work, are creative, and thrive when given autonomy.

Gillar åsikten om konsekvensen av X:

Theory X demands a lot of managerial control and tends to demotivate, generate hostility, and generally make people into sour pusses.

Git vs Mercurial

På X vs Y-temat har Fog Creekarna klämt ur sig en ny version av Kiln, nu med Harmony där man helt enkelt lyckats – mer eller mindre – transparent få ett repo att agera så att man kan interagera med det från både git och mercurial utan att bry sig om vad det “egentligen” är på andra sidan. (hg bookmarks för git branches, och git refs för hg branches – ja, det finns antagligen fler problemområden de varit lite olika kreativ att kringgå.)

Java vs Java?

En helt annan reflektion – jag såg två helt olika annonser som skulle locka “Java-folk”. Det finns väldigt mycket som snurrar på JVM:en och detta ämne blir dagens avslutande X vs Y, eller är det möjligen bara en vanlig Feature Envy?

Java X: JSP, JSF, CDI (inte DCI), JEE, EJB, JPA, JAX-*, WS-*, Spring-*, …

Java Y: Scala, Clojure, JQuery, Event Sourcing, Concurrency, Distributed Computing/P2P, Scrum, Cloud, NoSql, REST, CQRS, DevOps, AWS, EC2, Android, HTML5, MongoDB, Functional programming, Mule, DCI, BigData/Hadoop, JRuby, Akka, Neo4j, Qi4j …

Snabbkok: Jenkins och Sonar

No Gravatar

Fråga: Hur lång tid tar det att sätta upp Continuous Integration, om man har lite bråttom? (Jag var iväg på en utbildning och den virtuella maskinen som skulle användas för koddelning och CI var trasig på flera sätt.)

  1. Starta virtuell maskin (Amazon i detta fall, valde en m1.large), Ubuntu Server 12.10. Lägg till portar 8080 och 9000 i den Security Group som används.
  2. ssh -i pem ubutu@machine-at-amazon
  3. sudo -s
  4. aptitude install openjdk-7-jdk git
  5. wget http://updates.jenkins-ci.org/latest/jenkins.war; java -jar jenkins.war &
  6. wget http://dist.sonar.codehaus.org/sonar-3.4.1.zip; unzip *.zip; ./sonar-3.4.1/bin/linux-x86-64/sonar.sh start
  7. http://machine-at-amazon:8080/pluginManager – installera “Jenkins GIT plugin”, “Jenkins Sonar plugin”
  8. http://machine-at-amazon:8080/configure
    1. JVM: /usr/lib/jvm/java-7-openjdk-amd64
    2. Sonar Runner: Install from Codehaus
    3. Maven: Install from Apache
    4. Sonar: Add Sonar
  9. Skapa repo på Github, peta in en pom.xml, kopiera URL (HTTP, read only) till repot.
  10. http://machine-at-amazon:8080/view/All/newJob – ange ett namn, Maven 2/3-projekt. Peta in URLen till Github-repot, välj “Sonar” som Post-build step (längst längst ner)***
  11. Tryck på Play-(bygg-)knappen – kontrollera att allt fungerar. Högerklicka på Play-knappen och kopiera länken
  12. Under Settings på Github-repot, gå till Service Hooks, Webhook URLs och klistra in URL:en från Play-knappen på Jenkins
  13. Peta på en fil i projektet lokalt (t ex stega nummer i pom.xml), git commit, git push. Kontrollera att Jenkins startar automatiskt (webhook från Github), att informationen trycks över till Sonar (http://machine-at-amazon:9000/).

Resultat

Komplett miljö igång på under 15 minuter. Användes i fyra dagar – kostnad: ~20 USD.

Ett par brasklappar

*** Gällande aktivering av Sonar som ett post-build step – detta gör ju att feedbackloopen blir långsammare för happy path: dvs om bygget går bra kommer analysen Sonar utför göra att det tar längre tid innan man får “grön flagg”. Om bygget däremot är trasigt är feedbackloopens längd oförändrad.

CloudBees är ju också ett givet alternativ och ännu roligare ihop med Sauce Labs om man t ex behöver Selenium WebDriver.

Både Jenkins och Sonar kan givetvis installeras som vanliga Ubuntu/Debian-paket istället, vilket är mer lämpligt för en permanent lösning (troligen vill man då fundera över databas och konfiguration till Sonar, kanske autentisering osv).