Category: Diverse

munpack eml files

VIA Egencia skickar gärna sina biljettförslag som .eml-filer, vilket är ett påhitt från Microsoft. VIA Egencia har på senare tid börjat 64base-koda dem vilket gör att de inte längre är läsbara som klartext. Google mail-klienten klarar inte av att läsa/visa dessa filer alls, och även om Evoluion klarar av att läsa dem alldeles fint så är inte det inte alltid trivialt att få in mailen i Evolution. Hur som helst så kan man givetvis ordna detta på andra sätt. Här är två sådan sätt.

$ sudo aptitude install mpack
$ munpack -t file.eml
part1 (text/plain)
part2 (text/html)
$ cat part1
...
$ cp file.eml b64.txt
$ # ta bort mail headers, lägg hela base64-kodade materialet på en rad
$ $EDITOR b64.txt 
$ base64 -d b64.txt
...

Upgrading DokuWiki

DokuWiki is a really lightweight wiki which I’ve used since 2006. Today I decided it was time for an update and so these are the steps I followed.

cd /srv/www/dokuwiki
git commit
git push
wget http://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz
tar xzf dokuwiki-stable.tgz --strip-components=1
touch conf/local.php && rm -rf data/cache/*
rm dokuwiki-stable.tgz
grep -Ev '^($|#)' data/deleted.files | xargs -n 1 rm -vf
git add -A
git commit
git push

Notes:

  • the rm (xargs + grep) command removes unused files.
  • --strip-components removes path segments from the filename of the items in the tar ball.
  • Avoid getting the directory with cached content end up under git’s supervision.

Empirisk processkontroll

En hörnsten i Scrum är tillämpandet av en empirisk processkontroll – för den absoluta majoriteten av utvecklingsprojekt så är komplexiteten sådan att allt annat blir rena gissningsleken.

Lutningen av vagnarna på SJ:s X2000 (iaf det tågset jag reser med idag) har en prediktiv processkontroll. Sitter just nu ett par minuter utanför Göteborg och gungar av bara sjutton. Tåget går knappast snabbare än 40 km/h, men tågvagnen lutas som om vi rullade på i full fart. Resultat? Vi sitter alla och försöker motverka den överdrivna lutningen. Det ser lite lustigt ut, och det känns lite lustigt att vagnslutningen är så fyrkantig.

Puppet, VirtualBox and Interfaces

At work we’re using a small Python script to

  • do some sanity checking (hostname checks, acquiring IP address etc)
  • clone a VirtualBox machine (needs to be stopped because of Bug 9255)
  • modify machine to according # of CPUs and amount of RAM
  • mount the disk locally,
  • mount the disk’s first partition locally,
  • put SSH keys in place, used during initial provisioning,
  • update network setting files, including udev rules (/etc/udev/rules.d/70-persistent-net.rules) to get predictable network card names and being able to map them to IP addresses
  • unmount all above,
  • generate new DNS and basic Puppet manifest files, reload services (puppet),
  • boot it,
  • run puppet agent on the new machine to generate and push client signing request to puppetmaster
  • sign cert on puppetmaster,
  • run puppet to have the machine finish it’s provisioning (overwrites the SSH keys)

Done. :-)

To issue commands over SSH we’re using Fabric (and might, or might not, move to using Serf).

lightum

Jag har ett problem med min MacBook Air (5,2) – Ubuntu 13.04 introducerade en Linuxkärna som inte känner igen minidisplayport-till-VGA-adaptrar. HDMI-adaptrar fungerar fint.
Problemet är löst uppströms, dvs i en ren 3.12-kärna så är buggen bortstädad, men dessa kan jag inte köra då jag behöver drivrutiner som dessvärre inte bygger mot 3.12. Finns rapporterat på Launchpad

Lightum

En annan sak som stört mig lite är att varje gång jag startar om (eller loggar in och ut) så går tangentbordsupplysningen på max. Nu är det visserligen väldigt sällan jag bootar om eller loggar in och ut för den delen, men jag hittade iaf en liten programvara som sköter detta automagiskt, beroende på omgivningens ljusnivå.

Ett PPA var uppsatt av Pau Oliva, men dessvärre fungerar det inte längre. Så då är det ju bara att dra upp ärmarna och bygga själv:

git clone https://github.com/poliva/lightum
cd lightum
dpkg-checkbuilddeps
# installera det som behövs, i mitt fall:
sudo aptitude install debhelper autotools-dev pkg-config libdbus-1-dev libdbus-glib-1-dev libxss-dev
dpkg-buildpackage -b -us -uc

Stålmannens bäbis fyller 30!

GNU 30 år

Idag är det 30 år sedan Richard Stallman utropade starten på GNU-projektet. Det firas på olika sätt jorden runt. Free Software Foundation Europe skriver bl a:

Free Software[2] puts the control of electronic devices where it belongs: with the people who own them. Today, Free Software is everywhere. It powers the Internet, our mobile phones, televisions, cars, routers, and electronic devices of all sorts. Free Software has fundamentally changed the way people create software: instead of preventing people to adapt the software to their own needs, they invite people to participate in the development.

Nästa generations utvecklare förväntar sig att ta del av andras, och dela med sig av sina kunskaper. I Göteborg tycker jag mig se detta i en tydlig trend, t ex på det sätt som användarträffar på Meetup.com blomstrat senaste åren. Btw, FSCONS i år går av stapeln 8-10 november.

Den retoriska triaden

Fick bra text via reklam:

Ehtos, Logos och Pathos. […] Behaga, bevisa, beröra. Fråga dig alltid om din personlighet är sådan att du behagar (Ethos) de som lyssnar, att du har den kunskap som behövs för att bevisa (Logos), att du vet vad du pratar om och om du använder ord och meningar som berör (Pathos) motparten.

Jag kan tycka att det är konstigt att “kunskap […] för att bevisa (Logos)” och “vet vad du pratar om […] (Pathos)” inte hör ihop, men tolkningen av orden för mig är nog snarare:

Ethos – show, underhållning, entertainment. “Utstrålning i form av trygghet och lugn”, samt “person med hög moralisk resning med god etik”.
Logos – logiskt resonerande, röd tråd i argumenterande. “Logos vädjar till förnuft och fakta”
Pathos – förstår du mottagaren och problemet, och använder det ihop med/bygger upp pondus så att du blir trovärdig. (fel av mig – handlar mer om känsla och möjligen engagemang, pondus spänner nog över alla tre).

Och för fullständighet: varje tal bör innehålla följande aspekter:

  • Delectare – ”Att behaga”; talaren får lyssnaren välvilligt inställd genom sin personlighet och sin förtroendeingivande karaktär, sitt ethos.
  • Movere – ”Att röra”; talaren försöker väcka ”en känsla”, pathos hos lyssnaren.
  • Docere – ”Att undervisa”; talaren försöker vädja till lyssnarnas ”förnuft”, logos med hjälp av argument.

Samt

Tests – Silver Bullets?

A colleague wrote:

I have a client who needs to convince their old-school management that unit testing has value. I know. I know.

and he got some good material to work off. I myself recalled a very interesting session on CITCON in Budapest where a person playing the role as CTO asked us all to convince him that they needed pre-production tests (such as unit tests). Their (the company’s) experience was that they were doing absolutely fine without it, since they had close collaboration with the customer throughout the development process and lots of eye balls looking at hourly reports on how their web site(s) performed in terms of business.

In the rare cases where a bug went through and caused “damage”, the sales and support people had turned the unfortunate events (such as selling some Gucci or Versace type of bags for 1£ each, instead of 1000£ because of an unexpected comma (thousands delimiter) in the in-data file) to something positive and a marketing “event” kind of thing. These kinds of things, bugs/errors, didn’t happen very often at all and their customer base were actually mostly positive about when it did happen as they saw a company that in very short time responded to customer feedback, were open and honest about what they did to correct the situation etc. They had lots of in-production metrics/monitoring in place and people that closely monitored their systems. From a tech point of view, they seemed to have 0 issues. Business was happy with time-to-market etc.

The session was titled Do_we_need_tests_on_planet_retail? but no-one seems to have taken notes (or at least post them). Essentially, in this case we concluded that the only valid reasons to spend time writing pre-production tests were:

a) if the developers wanted to, then they should,
b) if the organization wanted to attract developers that wanted to write pre-production tests, then this could be encouraged by the organization as means of helping the recruitment of such individuals
c) if they started to get quality problems that they couldn’t sort out with whatever other means of quality improving measures they’d try (more code reviews, code analytics tools, …), then this is one route/option they could try out to see if it would help them fix that problem (but as of that day, they didn’t really have a quality problem)

We tried to pursue the argument that “tests/regression test suites” documents expected behavior of the system and helps people new to the code base not break features. Being strict with pair programming and not touching new areas without pairing with an “old timer” would ideally solve that too (and they didn’t have problems retaining their personnel). Risk obviously is a factor, “X people gets hit by a bus”-scenarios and such.

Teams of about 20 people in total doing development and ops. More people on community facing activities and sales. I understood they bought assets from companies that had gone bankrupt, and sold the stuff on-line. They’d been doing that for several years and were very profitable. Most of the work seemed to setup web sites and/or campaigns targeting certain audiences (high profile/expensive jewelery, football fans, 2013 Olympics Gadgets, …) and get statistics out of that to see how profitable the bought set of assets turned out to be. As such they monitored, from a businesses point of view, the system closely to see how the market responded to various on- and off-line activites and events.

I wouldn’t personally want to have my evenings with the kids depend on on that (systems with zero pre-production tests) but if/when what what you’re doing is mostly routine (similar things had been done many times) the value of writing the same tests over decreases as they become assertions of not typing the wrong thing. Good pair programming should save you from most of that.

TDD:ing in order to design the code, perhaps differently from previous iterations, is another subject. But in short – since the business was happy with what they were getting, and the developers lead happy lives too, it was hard to find reasons for them to have to change.

Försvinner utvecklingssamtalet i en agil organisation?

Läser med ett öga (barnpassning med det andra ögat) Peter Antmans “Riv pyramiderna igen”:

de agila värderingarna (teamet är ansvarigt, betoning av inre motivation, återkopplingar hela tiden, systemtänkande, vid behov) skar sig mot de värderingar som ligger bakom individuella utvecklingssamtal (bedömning, extern motivation, individinriktat, sällan förekommande, förutbestämt).

Spontant håller jag inte med. Möjligen (eller troligen) har vi olika bild av hur utvecklingssamtal genomförs och varför. Min erfarenhet säger mig att utbildningssamtal ger möjlighet till inspect & adapt.

Negativt?

“Bedömning”, ja mot egna uppsatta och antagna mål borde ju vara ett minimum. Vilken transparens har vi annars att jobba utifrån? Att få en extern vy på sina förehavanden och mål är sällan skadligt utan positivt – på samma sätt som att lära någon befäster sina egna kunskaper, att kunna visa och motivera sin bedömning för någon annan kan hjälpa till med att vässa sina argument och ställa djupare krav på eftertanke.

“Extern motivation”, detta ämne förstår jag inte.

“Individinriktat”, går visserligen bokstavligt stick i stäv med “teamet är ansvarigt” men inte bildligt. Det går inte att skapa grupper utan att ha individer. Att stötta individer till att växa och utvecklas borde göra teamet starkare.

“sällan förekommande”, detta håller jag med om. Min erfarenhet är att det sker sällan (varje kvartal). I för långa och för korta cykler är det svårt att se orsak och verkan.

“förutbestämt”, förstår inte riktigt vad Peter menar med detta. Förutbestämda datum behöver inte vara något negativt – i Scrum-ramverket ger det möjlighet till just att se orsak och verkan genom regelbunden inspektion. Ett metodiskt angrepp att försöka öka kontroll/riktning i en komplex miljö/omgivning/verklighet (och på så sätt reducera risken att komma ut i fel ände). Förutbestämd agenda kan vara jättebra för att komma igång, de flesta retrospectives jag deltagit i tror jag haft nytta av detta. Givetvis behöver man variera sig, men att ha något att börja titta på kan hjälpa till. Det kan också baseline:a och begränsa resultatet genom att det avgränsar tankerymden.

Positiva agila värden

“Teamet är ansvarigt” – vilket innebär personligt ansvar för den egna insatsen (inför teamet och sig själv).

“betoning av inre motivation” – kan man kanske se hänga ihop med Software Craftsmanship (för de som känner att det är vad de gör). En bra mentor/coach/chef bör kunna hjälpa till att hitta och formulera, och kanske även “maximera”, de aktiveter och den omgivning som stöttar en individs motivation. Att varje team skall bestå av personer vars innersta inre motivation kommer till fullt utlopp genom arbetsplatsens åtaganden känns eutopiskt.

“återkopplingar hela tiden” – instämmer att det traditionella utvecklingssamtalet är långt från tillräckligt här (samtidigt som viss ledtid måste finnas i “långa” processer)

“systemtänkande” – här tänker jag att utvecklingssamtalet inte bidrar till “systemtänkandet”, men inte heller skadar. Troligen optimerar man inte endast “flaskhalsen” genom att se till varje individ i teamet, vilket då skulle medföra “waste” i att se alla som inte är flaskhalsen. Jag skulle bli förvånad om det ändå är kostsamt att genomföra bra utvecklingssamtal, regelbundet.

“vid behov” – nja: visst som värde; nej som aktivitet för styrning. Om vi har komplex miljö vill vi göra kontinuerlig inspect & adapt, inte “vid behov”. I en enkel och repetitiv aktivitet vill vi minska waste, men att kalla individers utveckling inom arbetet för potentiell waste tror jag inte är lyckat. Det är antagligen inte heller vad Peter menar, så jag missförstår säkert hur utvecklingssamtalet “vid behov”.

Coach, mentor eller chef?

Givetvis får man kanske fundera över grundinställningen till utvecklingssamtalet. Om det är ett halvårsvis avstämningsmöte, eller förtäckt lönesamtal så är det väl tveksamma incitament för transparens etc.

Kanske Peter förtydligar sina tankar senare i boken.

Agila Sverige 2013

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.