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.

Bok: The Phoenix Project

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Jag har läst The Phoenix Projectbook-cover-phoenix i sommar. Jag läser långsamt och det tog mig 10 timmar att läsa ungefär (enligt Amazon).
Det är en kort berättelse om den förändring vår bransch går igenom och tar upp waterfail, lite kanban, mycket lite agile men mängder med Lean. Detta utan att kräva några förkunskaper och utan att vara snustorr – den är återgiven som en “vanlig” skönlitterär berättelse men förklarar ändå (genom tankar och dialoger med olika personer i boken) varför industrin ser ut som den gör, vilka förändringar som susar genom IT, teorier och principer bakom och varför det gamla inte fungerar och hur det nya fungerar.
Det var riktigt skön läsning och jag rekommenderar den varmt till alla som kommer i kontakt med IT i sin arbetsvardag. Denna bok önskar jag att alla kunder (inköpare) jag möter skall ha läst, och överväger att dela ut den till de som inte har läst den.