Agila Sverige 2013

Posted on 2013-05-21 by Fredrik Wendt

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 ); 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

Posted on 2013-05-17 by Rikard Thulin

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

Posted on 2013-05-02 by tomas.trolltoft@squeed.com

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)

Posted on 2013-04-18 by johan.normen@squeed.com

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

Posted on 2013-04-11 by Fredrik Normén

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

TDD-kurs, våren 2013

Posted on 2013-04-10 by Fredrik Wendt

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.

Devoxx UK 2013

Posted on 2013-03-28 by Fredrik Wendt

Den stora (Java-)konferensen Devoxx har ynglat av sig till Frankrike tidigare och i år har även UK/London (och Belgien) fått sig en lokal avstickare. Jag deltog tyvärr bara på en mindre del av konferensen, och fick i sista stund reda på att jag var tvungen att ändra slides till “det obligatoriska formatet” (som det visade sig att ingen förutom Oracle-anställda egentligen brydde sig om) så jag blev inte så mycket deltagare som jag hoppats. Hur som helst – jag pratade om Business Environment Coding Dojos, dvs delgav en del erfarenheter om vad jag sett fungerat och inte fungerat, samt vad jag tror är nyckelfaktorer till att företagsinterna dojos är framgångsrika. Med framgångsrik menar jag att de uppnått ett mål som ger affärsvärde – allt som oftast har det varit att få till en beteendeförändring, t ex större testfokus, “bry sig om hur bygget går” eller lyckas tillämpa nya kunskaper i dagliga arbetet. Om de nya “färdigheterna” inte används i det dagliga arbetet ser jag det alltså som en mindre lyckad investering.

Devoxx UK 2013 (med slogan “Mind the Geek”) uppskattade jag hade någonstans mellan 400-500 besökare, två “vanliga” dagar med föredrag med parallella hands-on labs “en trappa upp”. Lokalerna var kanon (allt hängde ihop smidigt och labdelen var inte “remote” på något sätt utan ett naturligt ställe att gå till), tekniken kanon (nej, det fanns ingen VGA-sladd så långt ögat nådde), mingelarean lagom stor och perfekt uppblandad med uställare som “omringade” ett öppet golv. Maten var kanske något sämre än väntat (smörgåsar – japp, England i ett nötskal?) men som tur var fanns trevligt folk som kompenserade det hela.

Av det jag lyssnade på tyckte jag Attilla Szegedi om Nashorn var mest intressant för mig: en “native”-implementation av ECMAScript som skeppas med JVM:en. Det fanns några mindre delar kvar att önska (prestanda inte minst), men en riktigt rolig grej var att de uppe på JVM-teamet i Stockholm har en “port” av Node.js där man bytt ut all C-kod mot att istället använda vanliga Java SE-paket. Klart intressant och de räknar med att kunna dela med sig av källkoden snart. (Grizzly för nonblocking IO.)
Bindningar av variabler mellan ECMAScript och Java-koden är ju intressant, men känns också som något man generellt sett skall undvika så mycket som möjligt.

Jag ser iaf fram emot att kunna labba med en variant av Node.js på min JVM. Prestandan är inte i närheten av V8 (och kommer antagligen aldrig kunna komma ikapp heller, det är inget mål), men just Nashorn är lite “äta sin egen hundmat” – första gången som de faktiskt använder invokedynamic – utöver för lambdas givetvis, men även det kommer ju först i version 8 som är planerad att släppas i höst.

Det var en hel del om just lambdas, hur man kan jobba bra och effektivt med dem, hur de fungerar, hur man ska tänka, hur standard API:er utökas (stream-ifieras). Mycket snack om fork-join-pooler och konfig av dem, men också JavaFX och givetvis fanns Raspberry Pi:s lite varstans.

Oavsett, Jeff Attwoods (Coding Horror-människan) regel verkar stämma och Oracle vill gärna att JVM:en hjälper till: “any application that can be written in JavaScript will eventually be written in JavaScript”.
(Btw, Jeff är ju en .Net-älskare men skrev nyligen öppet om varför/när han väljer bort det, och sticker ut hakan med “If you squint your eyes a little, I think you can see a future not too far in the distance where .NET is a specialized niche outside the mainstream”).

Sammanfattning: välorganiserat, snyggt skött, trevliga, välfungerande lokaler. Inte lika stort som JFokus. Få vågade sitta i Oracles beanbags.

Strategy X vs Y

Posted on 2013-03-14 by Fredrik Wendt

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 …

London Style TDD aka Mockist Approach

Posted on 2013-02-22 by Fredrik Wendt

Igår huserade Göteborgs Python-användargrupp, GothPy, i Squeeds lokaler och temat för kvällen var “London Style TDD“. En annan term som också använts för samma(?) stil eller variant av TDD är Mockist approach. För dem av som sitter i en statiskt/starkt typad, kompilerad miljö, tycker jag att detta är en teknik man skall förstå och gärna behärska – för varje software craftsman (eller kanske software crafts-hen) så bör detta vara en teknik eller ett verktyg bland flera, det är ett ganska tydligt tillvägagångssätt som används för att mejsla fram mjukvara.

Vi var dryga dussinet, åt många ovanligt små pizzor från Pizza Hut och hade oväntat mycket diskussioner kring mycket: jag hade väntat mig mindre diskussion och mer kodande. Jag tyckte dock det var mycket hög nivå på diskussionerna och många bra sidor och argument lyftes fram, vilket jag tror hela gruppen upplevde eftersom det var få som uttryckte någon önskan att “de ville gå vidare”. Lite oväntat för mig var den klart intressanta och underhållande dissektionen av klassificering av Test Doubles (alltså vad är egentligen dummies, stubs, fakes, spies, mocks?). Utan att gå in på detaljer så tog jag med mig en något rubbad uppfattning om klassisk TDD jämfört med mockbaserad TDD (classic vs stubborn).

Före

Mina två huvudsakliga åsikter som jag hade med mig in i rummet var de följande.

Klassisk = tillståndsbaserad testning, Mockbaserad = beteendebaserad

Jag är av uppfattningen att mängden testkod i ett icke-trivialt system kommer vara lika stor oavsett om man kör klassisk eller mockbaserad stil.

Den “stora” skillnaden är att fake-implementationerna behöver vara tillräckligt tillståndsfulla för att tillåta inspection så att man kan stämma av tillstånd i testens assertions. Dessutom behöver fake-implementationerna uppfylla beteendedelen av de kontrakt som finns. I starkt typade språk (Java) innebär det inte sällan komplicerade implementationer för att kunna nå gränsfall, eller multipla fake-implementationer.

Med mockbaserade test-doubles är tillstånd aldrig intressant och därför har man “bara” en aspekt att bry sig om när man skriver sina test doubles – beteende-/kontraktsaspekten.

Detta blir intressant i fallet när kodbasen rör på sig, gränssnitt och beteenden förändras. Med fake-implementationer behöver man ändra beteenden + sin tillstånds-implementation (som behövs för att kunna göra asserts på sluttillstånd) så att den fortfarande matchar originalets beteende. Med mock-implementationer behöver man “bara” ändra beteenden.

(Borde det inte kunna bli mindre kod rent av med mockning då, om man nu inte behöver lagra state någonstans? Jo, det kan man ju tycka från argumentationen ovan, men det inte var jag har kunnat se. Radmässigt blir möjligen testen i klassisk stil något kortare (man behöver inte välja mockarnas beteenden – fake-implementationernas default-beteenden är nog för de flesta test), men å andra sidan hamnar mer kod i test double-implementationerna.

Självklart underhåller man sin testkod med samma kärlek och omsorg som produktionskod, vilket gör att stubbning av mockobjekt – i större system – hamnar i “MockFactories” där man placerar återanvänd kod. Jag förordar inte stilen där varje mocks beteende skall uttryckas explicit i varje test – “self containing test”. Jag ser inte varför man skall lita mer på kod som ligger i test doubles av typen fake, jämfört med av typen mock. (Det argumentet låter som skrock och rädsla för det okända: “jag litar mer på min kod i min fake, än på mockito-ramverket” t ex.

I Python är behovet av mockramverk mycket litet

Min bild har varit att eftersom alla objekt är “kontraktslösa”, i meningen att allt är löst typat (Duck typing), därför gör det billigt* att skapa test doubles av olika slag, när de behövs, där de behövs och på det sätt de behövs.
I Java-språket med stark typning måste man skicka objekt som uppfyller kontrakt, medan enhetstest sällan har behov av fullvärdiga implementationer och än mindre utnyttjar enheten under test (SUT) hela, eller ens stora delar av, kontrakten från sina collaborators i enskilda test.

Efter

Ett bra argument jag själv helt förbisett (vilket är en klar hint om hur ofta jag jobbar med Python) är att ett bra mockramverk kan ge bra feedback när man utvecklar (“Expected %s invocations of %s, got %s”) vilket ju rättfärdigar nyttan med ett mockningsramverk.

Stubbar man mockobjekt, eller definierar man kontraktuella beteenden hos sina collaborators under viss interaktion (ett tests livscykel) med följande kod:

when(collaboratorA.reserveSeats(10)).thenThrow(new RuntimeException("database is down"));
// or
when(collaboratorA.cancelReservation("1234")).thenReturn(new ReservationCancellation());

En terminologigrej tror jag – jag har inte använt ordet stub utan använt andra formuleringar (förbereder, “berättar för mockobjektet hur det ska bete sig” t ex).

Jämför med BDDMockito-smaken:

given(collaboratorA.reserveSeats(10)).willThrow(...);
// or
given(collaboratorA.cancelReservation("1234")).willReturn(...);

En annan sak jag vill fundera mer på var rekommendationen att inte mocka 3pp, “don’t mock what you don’t own” tror jag var originalfraseringen. Den diskussionen gick lite för fort för mig och ambitionen att “bara lägga på ett till lager” mellan plattformens eller 3pp-ramverkets API:er och det man själv vill använda minimerar möjligen kontaktytan (och framtvingar ett mer explicit ställningstagande i hur beroende man vill vara av 3pp-saken), men flyttar i viss mån bara runt problemet till det nya lagret.

Bevis

Nej, det finns givetvis inte. Kod är i stora delar ett hantverk och då är världen sällan skalan svart eller vit.

Jag började för ett litet tag försöka skriva ett exempel på hur kod kan se ut med mockbaserad teststil, jämte klassisk stil. Dock inte i Python. Jag är en bit från “klar”, exemplet är inte heller perfekt men jag tror intentionerna synas i det som finns där nu. https://github.com/FredrikWendt/tdd-classic-vs-mockist/tree/master/src/test/java/se/wendt/tdd

Slutsats

GothPy är en härlig samling med trevliga och mycket kompetenta människor från ganska varierande och olika bakgrund. Mixen är klockren och ger alltid härligt nyanserade diskussioner med högt i tak och genuin vilja att utforska olika riktningar och synsätt.

Pga denna gruppdynamik kände jag att det fanns mycket mer att fundera kring, testa (koda) och gräva i på detta ämne och jag åkte hem på vagnen utan att känna mig riktigt “färdig”!

* Billig kod är lätt att läsa, förstå (lagom kort och koncis) och underhålla. Den kräver också mycket lite kognitiv belastning hos läsaren.

Squeed Team Blog

Category Archives: Community