Category: Diverse

Datorn – han eller hon?

En språklärare på högstadiet, diskuterade det här med “kön” med sina
elever.

T ex – sa läraren – benämns oftast båtar, flygplan och orkaner som “hon”. En av eleverna undrade då vilket kön i så fall en dator skulle vara. Läraren gjorde då detta till en gruppuppgift och delade upp klassen i två grupper – killar för sig och tjejer för sig. Uppgiften var att ge datorn ett kön och motivera varför.

Tjejerna kom fram till att en dator definitivt är en “han” eftersom:

  1. Han kan en hel del, men vet sällan hur han skall använda sin talang utan att få instruktioner.
  2. Det är meningen att han skall hjälpa till att lösa dina problem, men hälften av tiden är han själv det största problemet.
  3. För att få hans uppmärksamhet måste du först sätta på honom.
  4. Så fort du skaffat dig en, vet du att om du bara hade väntat litet längre skulle du kunna hittat en bättre modell.

Killarna, å andra sidan, ansåg att en dator är en “hon” eftersom:

  1. Ingen, utom hennes skapare, kan förstå den inbyggda logiken.
  2. Det språk en dator använder för att kommunicera med en annan dator är obegripligt för alla som inte är datorer.
  3. Minsta lilla misstag lagras i ett långtidsminne och kommer att ställa
    till problem långt efteråt.
  4. Så fort du har fastnat för en, kommer du tvingas att spendera halva lönen på mer eller mindre nödvändiga tillbehör.

PyUseCase för ExtJS

Häromdagen var jag på GothPy-möte och fick se och testa på PyUseCase. Efteråt funderade jag på det 18-månadersprojekt (~8 utvecklare) jag nyss avslutat där ExtJS varit GUI-ramverket i applikationen (dvs en Rich Internet Application).

PyUseCase för ExtJS

  1. Det hade varit väldigt användbart.
  2. Jag har inte sett något liknande för webb.
  3. Jag tror inte att det är omöjligt …
  4. … men det kan kräva en hel del kunskap (om Selenium IDE) och kod att få till. :/

Jag har ännu inte kollat på Selenium 2. Jag har inte testkört Bromine utan bara tittat på dess screencast. ** I början av projektet jag satt på pratade vi dock om att det hade varit fint att ta oss till den nivån att man hade selenium-test som verifierade use case. Det närmaste jag såg ett verktyg som skulle kunna stödja det var STIQ, men organisationen ville inte testa detta – att använda Selenium var tillräcklig risk i projektet tyckte man.

** “Management can look at the icons ” 7 minuter in i filmen :)

Versionshantering

Varken STIQ eller Bromine verkar dock versionshantera testen, eller gruppera dem i “detta är use-casen för sprint 10”, och det är något jag känner att jag saknar. Under de 18 månader vi jobbade så byggdes flera funktioner om, så i sprint 10 kanske vi stödde 15 Use case, medan sprint 11 bara klarade 12 eftersom 3 skrevs om.

Sättet vi hanterade det på var att kommentera bort test case från testsviten. Inte snyggt, men eftersom Hudson mailade oss varje gång testen inte fungerade var vi nästan tvungna …

Avslutande tankar

  • Det jag gillar med Bromine är kopplingen till krav/use case.
  • Det jag gillar med STIQ är wiki-hanteringen och att man försöker abstrahera testen till logiska enheter/interaktionssteg.
  • Det jag gillar med PyUseCase (för GTK) är hur inspelningen mappar till logisk enhet/interaktionssteg. Separationen med texttest är inte dum, eftersom valideringsbiten faller bort från stegen som behövs för att utföra use caset. Att ha två representationer av GUI:t (en ASCII-art och en verklig) är dock inte intuitivt för mig och känns som ren duplicering. Kanske är det ett nödvändigt ont man får acceptera för att få rena “use case test”?
  • Med ett UI-ramverk som ExtJS borde man kunna lyssna på komponenter på samma sätt som PyUseCase gör med PyGTK. ASCII-art-rendreringen server side (eller iaf någon logg) är jag tveksam till.

JSConf.eu-sammanfattning på dotNetForum

Fick glädjande nog til minuter på dagens dotNetForum till att presentera konferensen JSConf.eu. Tio minuter är väldigt lite tid, speciellt när projektorn och min dator inte är överens (fick lösas med att starta om X, varpå gconf kände igen “skärmarna” och använda rätt inställning direkt).

Fler personer än väntat kom fram efteråt och hade bra frågor – riktigt kul! Förhoppningsvis får jag komma tillbaka och prata mer om hur man optimerar webbplatser – det var detta ämne som verkade väckt störst intresse. :)

Presentationen (PDF)

Presentation (ODP)

Alienated DVD

Skulle idag spela upp en DVD-skiva jag köpt (Alien-kvadrologin) men det står något skumt om att den inte kunde läsa skivan. Alla som känner till problemet vet att det handlar om ett “skydd” mot “oavsedd” uppspelning – skivan är regionsskyddad och “krypterad”. Ganska svagt dock.

En norrman löste detta “problem” för ett tag sedan och satte innehållet fritt så att jag som köpt min skiva i Sverige, avsedd att spelas upp i Sverige, med en dator köpt i Sverige, skall kunna se på filmen …

Detta är dock tvivelaktigt, lagligt sett. Visst är det skumt? Så vitt jag vet har jag gjort allt jag ska – köpt rätt hårdvara, betalat för plastbiten som filmen levereras på. Ah – windowsskatten … Det framgår dock inte av DVD-boxen att man måste köpa ett operativsystem från USA-baserade företag för att kunna spela upp filmen.

Under Ubuntu 9.04 får man installera libdvdread4 och sedan kör

sudo /usr/share/doc/libdvdread4/install-css.sh

Därefter funkar allt som det ska (fick skicka ut skivan och köra in den igen bara).

Python and Maemo, where’s that N900

Work in progress! :)

Väntar tålmodigt på att Nokia Online Store skall skicka mig meddelande om att “nu är din beställning skickad” – i Italien verkar utrullningen vara i full gång, i Sverige har den inte börjat ännu. Senaste budet är att i vecka 50 kommer de första beställningarna skickas ut. Vet inte om jag ligger med bland dem.

Nåväl. Jag har jobbat på att få till en applikation som kan visa avgångar och resvägar inom Göteborg med hjälp av Västtrafiks web services. Det har tagit ungefär så lång tid som jag förävntat mig och följande var utmaningarna.

[flashvideo file=http://wendt.se/misc/maemo-vasttrafik-091203-a.flv width=400 height=286 /]

Python

Jag är inte överens om att block-level avgörs av indentering – vilket företag vill betala utvecklare för att sitta och flytta kod till vänster och höger? Jag programmerar mycket hellre med {} och låter ett verktyg formatera koden “vackert”.

IDE – här har jag dock varit lat. PyEclipse skall tydligen vara rätt bra och ge bra stöd (hoppas det finns code completion-stöd för gtk.* med signaler och annat?)

PyGtk (API)

Väldokumenterat. Ihop med GTK+-dokumentationen måste jag säga att det är komplett. Widget-galleriet är också kanon att kunna snegla på.

PyMaemo och Hildon

(API) Hildon C-API

Detta upplever jag vara den svagaste länken i kedjan. Att jobba med en touch-applikation är nytt för mig, och jag gissar att det gäller många andra också, och då behövs vägledning, widget gallerier och tonvis med exempel så att man kan få en känsla för hur man bör bygga bra GUI:n.

Lite vägledning finns (plus Nokias UI guide lines och usability-dokument), men widget galleri och tonvis med exempel saknas – det finns ett tiotal exempel som visar lika många widgets, men inte ett enda “riktigt” program.

Py* för Web Services

Efter att ha prövat ett par bibliotek, alla med olika tillkortakommanden (schematolkning, teckenkodning, …), så stötte jag på suds som fungerar utmärkt om man bara vill ha en väl fungerande klientdel.

PS

Screen captures with XVidCap, konverterat med

ffmpeg -y -i test-0000.mpeg -qscale 5 -an -s 400x240 -f flv test.flv

[flashvideo file=http://wendt.se/misc/maemo-vasttrafik-091203-b.flv width=400 height=286 /]

Gemensamt tal

När Johanna och Niclas gifte sig (070707) så höll alla middagsgästerna ett gemensamt tal:

På toastmasterna signal, gör följande:

Klinga i glaset och ställ dig upp. När alla har rest sig, harkla dig tydligt och vänd blicken mot brudparet. Börja tala.

Kära brudpar!

Inte för att vi är några talare (hosta lätt), men vi vill ändå säga några väl valda ord denna högtidsdag.

(väg på tårna) Det är en stor glädje att dela er glädje (skratta lite lätt) denna högtidsdag (skratta generat).

(titta menande på brudparet) Vi har ju känt varandra ett tag och vi har upplevt många fina stunder tillsammans (skratta finurligt) och därför känns det extra roligt att få vara med här (slå ut med handen) bland era närmaste denna stora dag.

DU, Niclas (titta på Niclas), kan skatta dig lycklig som funnit en så yppi… (säg: eeee) ypperligt charmig, glad och (paus) huslig hustru. Och du Johanna (titta på Johanna) har lagt vantarna på en verkligt genomtrevlig och händig karlakarl (smila brett).

Som sagt (pausa) … Vi tycker att det är fantastikt att få vara med idag när ni knyter äktenskapets band (pausa. harkla dig. klia dig på valfritt ställe.)

Må alla lycka följa er på livets stig!

Vi vill nu passa på att utbringa, ett rungande fyrfaldigt leve för brudparet: De leve!

Hurra!
Hurra!
Hurra!
Hurra!

(höj glaset i en skål) Skål!

Infrarött

Skärm vid skärm
Skärm vid skärm

Har en liten skön installation här hemma där en dator driver en skärm som står bredvid TV:n. Och detta är problemen:

  • Ubuntu skickar med modulerna som behövs för lirc (Linux Infrared Remote Control)
  • Debian skickar inte med modulerna, utan dess behöver byggas själv. Paketet heter lirc-modules-source

För instruktioner om hur man bygger det binära modulpaketet för Debian, läs: /usr/share/doc/lirc-modules-source/README.Debian

Man skall köra

dpkg-reconfigure lirc-modules-source # för att markera vad som behöver byggas (lirc_imon)
m-a prepare  # för att förbereda modulbygget (module-assistant)
m-a a-i lirc #

Sedan behöver man bara set till att modulerna laddas (modprobe manuellt):

echo "lirc_imon" >> /etc/modules

Lite mer än man önskar. Efter omstart visas

stereo:~# lsmod | grep lirc
lirc_imon              11348  0
lirc_dev               10196  1 lirc_imon
usbcore               125484  4 lirc_imon,uhci_hcd,ehci_hcd

och sedan fick jag justera /etc/init.d/lirc manuellt – argumenten till lircd (-d /dev/lirc0) sattes inte upp ordentligt. Och jag valde att starta irexec från /home/browser/.xsession istället för en systemspecifik.

unclutter plockar bort markören från X efter en sekund eller två.

Efter att ha mailat Enrico Zini fick jag tips om nodm som gör just det som önskades åstadkomma ovan – dvs en Display Manager som “bara” kan logga in en specifik användare och starta en Xsession. Utmärkt för en “kiosk”-lösning alltså.

För att få Firefox (Iceweasel under Debian) att öppna alla anrop från irexec i en och samma flik och fönster så behöver browser.link.open_newwindow sättas till 1 (via about:config).

Utvecklingsstack – för Java

Jag har funderat lite på vilken stack jag föredrar och nu såhär sent på kvällen skriver jag ihop:

  • JIRA
  • DokuWiki
  • Hudson
  • Sonar
  • Nexus / Archiva
  • Git

Egentligen behövs två kategorier: en fri (gratis) och en betalvariant. Tanken väcktes av att jag såg Markus M. May paketera sin favoritstack för ArchLinux (tidigare Ubuntu, men gav upp detta). Det händer ju ett par gånger om året att just detta behöver sättas upp för ett projekt – att ha en färdig “blob” att bara slänga igång hade ju inte varit fel. Kanske en Xen image (Gandi hosting om man inte vill köra AMI/Amazon) eller bara en stor zip klar att sparkas igång med ett bash-script, …

Projekt- och ärendehantering

JIRA – en klassiker som fungerar även i större sammanhang. Kan knytas in till confluence. Projekt, komponenter, milstolpar, olika flöden, watchers, voters, rapporter, ärende-relationer, … Icke-gratis och icke-fri.

Mingle är en vacker produkt som jag inte är övertygad vara värd sin kostnad. Mest web 2.0-ig av alla och mest planeringsvänlig (dra-och-släpp med bäst översikt av tillgängligt material). Icke-gratis och icke-fri.

VersionOne – otestad.

BugZilla – klassiker som är för enkel för min smak.

RedMine – tyvärr otestad ruby-historia som ser kompetent ut på pappret. Verkar sakna ärende-relationer såsom liknar, ersätter, beror på, …

Trac – ärendehanteringen i trac är kass och för enkel.

Wiki

DokuWiki – enklast, snabbast, smidigast, rättframmast. Gör jobbet och det är trevligt att jobba med.

Trac – wikin i Trac fungerar ok. Trevligt när man kan länka till kod så lätt.

MediaWiki – no no.

Confluence – hat-kärlek. Ingen redigering av stycken, editorn buggig och saknar en hel del av TinyMCE:s “kraft”.

Källkodrepositorie

Git – har inte varit fri från strul, och strulet har inte varit helt idiotsäkert att fixa till. Men distribuerat, snabbt och enkelt att komma igång.

Mercurial (hg) – otestat, skall kunna mäta sig med git och till och med vara “finare” i vissa avseenden, t ex hur lång livslängden på en branch är.

SVN, CVS – klassiker som trots allt fungerar ganska långt för mindre team.

Mavenbibliotek

Archiva – trotjänare som trots allt fungerat stabilt under långa perioder. En aning gammalmodig med lösenordspenalism t ex.

Nexus – otestad, men vacker i publika installationer och på pappret. Mindre minnesavtryck (memory footprint) är ju inte fel.

Bygg- och CI-motor

Hudson – en klar favorit.

Continuum, Cruise Control – är lite samma sak för mig: en hög XML och inget som inte Hudson har. (Var länge sedan jag körde dessa dock.)

Övriga verktyg

Sonar – alla rapporter som kan genereras automatiskt bör genereras. När man får upp farten gäller det att hålla kurs så man inte hamnar i dolda teknisk skuld-fällor.