ZX Spectrum, världens bästa hemdator?

I en annan av kartonger på vinden fanns min gamla Sinclair ZX Spectrum. Komplett med joystick, bandspelare och kopplingsdosa till TV.

Instruktionsböcker. Den bok jag lärde mig programmera Basic från.

Och spel så klart. På kassettband. Rymdspel...

Några konflikt- och karatespel.

Och en hel del sportspel.

En skeppsidentifikationskarta från Elite, men tyvärr varken spelet eller det coola hårdvarukopieringsskyddet.

Säkerhetsregler frångås ständigt

Att IT-säkerhet skulle segla upp som ett hett politiskt ämne var väl oväntat för alla. Men medan Transportstyrelsen, Fortifikationsverket och Dan Eliasson är på tapeten tänkte jag dela med mig av några egna erfarenheter om IT-säkerhet. Även om jag inte vet något speciellt om de tre nämnda fallen så arbetar jag till vardags med IT-säkerhet för Försvarsmakten och ser kanske lite annorlunda på vissa saker än den breda allmänheten. Framförallt gäller detta avsteg och avvikelser från säkerhetsregler. Detta förekommer alltid och överallt. För vårt säkerhetssystem börjar det redan i kravställningen: 

Funktionen för autentisering skall, där så är möjligt, utnyttja säkerhetsmekanismer som är godkända av Försvarsmakten.

Redan i "Skall"-kravet har alltså beställaren Försvarets Materielverk öppnat ett kryphål: "där så är möjligt". Naturligtvis måste det motiveras varför man inte utnyttjar godkända säkerhetsmekanismer men man kan låta bli. Och låta bli det gör vi. I vår dokumentation används följande standardtext om kryptering:

Enligt svensk försvarsterminologi får begreppet "kryptering" ("encryption") och "krypterad" ("encrypted") enbart användas för krypteringsteknik godkänd av Försvarsmakten. I detta dokument används begreppen "skydd" ("protection") och "skyddad" ("protected") för att beskriva krypteringsteknik som inte godkänts av Försvarsmakten. 

Eftersom det inte finns någon av Försvarsmakten godkänd lösning för kryptering av LAN, av den typ vi behöver, så erbjuder vi bara "network protection". Vi har i vårt system inte heller ett hårddiskkrypto utan en "full disk protection solution". Detta har godkänts, levererats och används idag.

Om säkerhetskraven på systemet verkar alltför inskränkande kan man också åberopa generalklausulen i avtalet:

Säkerhetsfunktioner och systemfunktioner i systemet får inte vara i konflikt med varandra och därigenom förhindra varandras avsedda funktion.

Om en sådan konflikt ändå uppstår så kan alltid en lokal befälhavare beordra undantag från gällande säkerhetsregler. Jag själv blev ganska förvånad när jag besökte en systeminstallation och noterade att användarnas långa och komplicerade lösenord satt fastklistrade på papperslappar på tangentborden och fick förklarat för mig att detta var ett legitimt sätt att använda systemet.

Augmented inte virtual reality

Det verkar som om virtual reality (VR) står inför (ännu) ett genombrott i det allmänna medvetandet: Obama testar det på en mässa, TV4s Nyhetsmorgon är det första svenska TV-programmet som gör detsamma och IKEA släpper en app.  Alltså är det dags att flytta blicken till en mer avancerad teknik som faktiskt är användbar.

På mitt företag har vi arbetat med VR i många år. Vi offererar och säljer regelbundet HMDs med en rörelsesensor för att låta användare ”kliva in” i vår virtuella värld. Fördelarna mot den traditionella tekniken på vårt område, projektorer och en dom (en krökt projiceringsvägg),  är flera:

• I princip 360 x 360 graders fri sikt
• Det låga priset (vi använder flera projektorer som kostar hundratusentals kronor styck och domer som tar dagar att bygga)
• Den lilla storleken (systemet blir, i princip, flyttbart)

Trots detta så överväger nackdelarna och HMDs har bara blivit ett komplement till den traditionella lösningen. Problemen är två. Det första är den dålig bildkvalité i existerande produkter, båda upplösning och, framförallt, field of view. Detta kommer säkert den tekniska utvecklingen att lösa.

Det andra problemet är att man i VR bara ser den digitala världen. Det är i princip omöjligt att samarbeta på ett effektivt sätt om man antingen inte ser sina kollegor eller bara ser en digital representation av dem.  Samma sak för utrustning man vill använda. Om man inte kan se den så blir möjligheterna begränsade till rena handgrepp.

Därför är augmented reality av mycket stort intresse. Möjligheten att se sin verkliga omgivning mot en digital fond är precis vad som behövs. Och på detta område kommer det nu verkliga produkter, till exempel Google backade Magic Leap. Microsoft lanserar HoloLens där företag som Volvo

och SAAB medverkar som partners. Det är inom augmented reality det intressanta sker idag.

Att lära sig programmera med Minecraft

Mojang har i samarbete med ett projekt kallat Hour Of Code lanserat ett nytt verktyg (följaktligen kallat Minecraft Hour of Code) för att ge barn (och andra oinsatta) några insikter i hur programmering fungerar. Målet är att sätta samman små kodsnuttar för att därigenom styra en Minecraft-gubbe och lösa de uppsatta problemen. Man skriver inte koden utan fogar samman små "pusselbitar" med kommandon, precis som i språket Scratch (läs mer Att lära barn programmera).

Koden exekveras i spelvärlden till vänster i bilden ovan och sätts samman i ytan till höger . I detta fall en enkel kommandosekvens för att få karaktären att klippa ullen av de båda fåren.

Förutom grundkommandon (objekt-metoder) anpassade för det aktuella problemet finns det "for"-loopar. I det aktuella fallet har Alex byggt klart tre sidor av ett hus. Att nästla loopar är det svåraste problem spelaren ställs inför.

Verktyget har också en boolsk "if"-operator. Det finns flera bra saker med "Minecraft Hour of Code": hela spelet ser trevligt ut, att köra koden i en spelvärlden där figurer rör på sig och agerar gör det mycket konkret och lätt att felsöka och att det finns färdiga problem att lösa gör det lätt att komma igång. Det stora problemet är att det är för många användare nog är för lätt och för litet. Jag har testat det tillsammans med två barn. För tioåringen van vid Scratch (läs mer Vårt Scratch-projekt) krävdes det att man bara accepterade lösningar med minimalt antal block för att det skulle vara någon utmaning alls. För en sjuåring utan programmeringserfarenhet var problemen på bättre nivå men även då kändes spelet för kort.

Sammanfattningsvis: bra gjort, Mojang, med ge oss mer. Jag återkommer snart med ett mer komplett alternativ för att lära barn programmera i Minecraft: ComputerCraft. 

Historien om lilla ö

På mitt arbete har vi två nätverk. Ett allmänt för hela företaget och ett separat för min arbetsgrupp. Dessa är helt skilda, två domäner, där jag har två olika användar-id. Vi har internet i båda. Eftersom min käre arbetsgivare bekymrar sig för sina anställdas säkerhet har hen nu trappat upp projekt "Säker surf". Denna upptrappning innebär, bland annat, att om man nu besöker Google möts man av en varningsruta som förklarar att man besöker "internet" och att det kan vara farligt. För att försäkra sig om att ingen råkar illa ut har den käre arbetsgivare också beslutat att registrera all aktivitet på internet på alla olika nätverk. Dock stötte arbetet på problem: registreringen sker efter användar-id på det allmänna nätet så övervakningen av vårt särnät fungerade inte. Lösningen blev att tvinga oss att också logga in med vårt allmänna användare-id på särnätet. Detta fungerade bra för alla utom mig. Den tekniska lösning arbetsgivaren valt klarade nämligen bara användarnamn/lösenord  (borde säga lösenmening) som enbart innehåller ASCII-tecken. Alltså, i detta nådens år 2014 tvingades jag byta lösenord på jobbet för att kunna använda internet eftersom mitt lösenord innehöll "ö". WTF?! 

Vårt Scratch-projekt

Nio månader efter första inlägget om mitt och min dotters programmeringsprojekt (Att lära barn programmera) i Scratch är det nu dags för en offentlig alpha-version. Målet är alltså att återskapa ett klassiskt "Space Invaders"-spel. Största problemet var att få kollisionerna mellan projektil (a.k.a tennisboll) och monster att fungera. Det mest naturliga borde vara att låta monstret ansvara för dessa men det fungerade inte, monstret har för dålig uppfattning om var tennisbollen befinner sig. Istället fick tennisbollen ta ansvar för detta och skicka ett meddelande till monstret när kollision inträffade.

Nästa problem uppstod hos monstret. Det visade sig att alla monster-kloner tog emot "Du är träffad"-meddelandet. Så om man reagerade på detta genom att radera sig själv, så försvann alla monster om man träffade ett. Lösningen blev att skicka koordinaterna för kollisionen (som de globala variabler BollensPositionX, BollensPositionY) och låta monstret bestämma om hen är tillräckligt nära för att påverkas av bollträffen.

Nästa steg i utvecklingen blir att klona tennisbollar istället för att återanvända samma boll hela tiden. Sen får man väl titta på stegrad svårighetsgrad allt eftersom poängen ökar med mera.

Att lära barn programmera

Intresset för att lära barn programmera verkar vara stort för tillfället (se till exempel NyTeknik, ComputerSweden, Tekniska Museet, Sveriges Radio). Jag och min åttaåriga dotter har ett programmeringsprojekt tillsammans. Vi använder Scratch, ett grattis, webb-baserat programmeringsspråk från MIT. Vi försöker göra ett enkelt SpaceInvaders-spel av klassisk modell.

Språket baseras på sprites, ikoner. Dessa hämtas från ett bibliotek eller laddas upp. Till vårt spel har vi tre sprites: ett monster som anfaller, en stridsvagn som försvarar genom att skjuta tennisbollar.

Varje sprite har ett eller flera script kopplat till sig. Stridsvagnen har tre script: när man trycker ner höger-pil så flyttas vagnen tio steg till höger och vänster-pil ger tio steg till vänster. När man startat spelet (den gröna flaggan) kommer stridsvagnen om den träffas av ett monster att spela ett ljud samt försvinna. Spelet är slut.

Script byggs ihop av förutbestämda pusselbitar av olika typer. Dessa är färgkodade för lättare översikt och går inte heller att bygga ihop hur som helst. Ett script kan startas med en Händelse. Här finns också möjlighet att skicka meddelanden mellan sprites för mer komplicerade händelser. Att göra det är dock inte okomplicerat och flera scripts har krävt ganska mycket testning för att få att fungera.

Bland Kontroll-bitarna finns olika loop-konstruktioner och if-then-else.

Språket stödjer även att man definierar och använder lokala variabler. Monstret har bland annat scriptet nedan. Vi använder variabeln y för att få den typiska nedåtgående rörelsen för den invaderande monster-flottan. Annars är klon-hanteringen (för att få till en hel flotta) en av de delar som ännu inte fungerar i vårt program.

På Scratch-hemsida betonas också andra aspekter av den rådande kulturen inom programmeringsvärlden. Användare uppmuntras att dela sina projekt med andra och att använda andras projekt för att skapa något nytt. På den centrala frågan om huruvida min dotter lär sig programmera av detta har jag ännu inget svar. Hon tycker att det är roligt att hålla på med Scratch och blir väldigt glad när vi löser ett problem och går framåt. Men hur mycket hon skulle klara själv vet jag inte, det är nog bara tiden som kan svara på av vilken nytta detta är.

Hur man inte bör specificera en standard, exemplet Link 16

Link 16 är en militär kommunikationsstandard som används av USA, NATO och andra. Specifikationen finns publicerad som STANAG (NATO STANDARDIZATION AGREEMENT) 5516 inom NATO (i flera olika utgåvor) och i USA som MIL-STD-6016. Standarden är inte hemlig men den är, som man säger, inte offentlig. Det innebär att man kan be USA eller NATO om att få tillgång till den och om man anses vara betrodd får man det. Som svensk är det naturligtvis inget problem, vi är ju en "coalition partner" (se mer här).

När man får tillgång till standarden så är det första man reagerar på att den är 4848 sidor. Detta trots att dokumentet bara innehåller beskrivningar av de meddelanden som skickas och i stort sett ingenting om den omkringliggande infrastrukturen (tekniska detaljer finns i bilagor som publicerats separat). Det andra man reagerar på (om man inte sett det tidigare) är den mycket noggranna hanteringen av blanka sidor i dokumentet (motsvarande "This Page Intentionally Left Blank").

Link 16 beskriver ett sextiotal olika meddelanden, där de flesta finns i några olika varianter. Sammanlagt är det alltså ungefär tvåhundra meddelanden som ska beskrivas. De flesta meddelanden kan beskrivas på några få sidor, så hur hamnar dokumentet då på sammanlagt nästan 5000 sidor? Jo, genom införandet av en egenskap som kallas"Specific Type". Som exempel tittar vi på meddelande J3.3 "Surface Track". Ett enkelt meddelande för att förmedla positionen hos ett fartyg (farkost på vatten) man har observerat. Man skickar ett id och en position, kurs och fart. Man kan ange vilken typ av fartyg det är (det finns 34 fyra typer att välja på) och vad det eventuellt håller på med (det finns också 34 aktiviteter att välja på). Sedan går man in i den 45-sidiga listan (mer än 3000 typer) över "Specific Types" för detta meddelande, utdrag nedan (sidan 15):

Vad betyder listan? Jo, om fartyget du observerat var det svenska minfartyget "Älvsborg" anger du 899 i fältet för "specific type" men om det istället var stabs- och ledningsfartyget "Carlkrona" anger du 901. Men det kanske var tyska "Sachsenwald"? Då ska du ange 910. Motsvarande listor finns för flygplan, markfordon, ubåtar, kryssningsmissiler med mera. I slutet av 1990-talet när man arbetade fram standarden valde man alltså att i standarden hårdkoda värden för alla då existerande militära fartyg, flygplansmodeller med mera. Naturligtvis blev standarden på detta sätt nästan ögonblickligen inaktuell. Till exempel såldes "Älvsborg" 1997 till Chile där hon nu mer går under namnet "Almirante José Toribio Merino Castro". Av svenska flygplan så finns till exempel J-35 Draken (typnummer 21, 28, 277, 564 eller 801 beroende på modell)  och J-37 Viggen (31, 281, 800 eller 802)  representerade men ingen JAS Gripen. Om man ska skapa en applikation för att skicka Link 16-meddelanden bör man alltså, enligt standardförfarandet, implementera drop-down menyer (eller motsvarande) med fler än 3000 namn på fartyg att välja på för att skicka ett J3.3. Detta är inte det sätt man bör specifiera en standard på.   

Dokumentation i verkligheten

Jag säger "Som utvecklare är det viktigt att man dokumenterar det man gör. Speciellt på en arbetsplats med stor kodbas och gott om konsulter som kommer in och petar i den."

Snorvalpen: "Äh, bra kod dokumenterar sig själv."

Jag: "Sätt dig ner unge man, så ska jag berätta för dig om dokumentation i verkligheten"

Det som ska dokumenteras är inte i första hand koden själv. Istället dokumenterar man till exempel arkitekturen:

En kund använder version 4.2 av plattformen. De vill nu ha funktionaliteten APA. Att lyfta kunden till version 5.X är uteslutet av kostnadsskäl. Versioner 4.5 och 4.7-9 har bra stöd för APA men av dessa går 4.7-9 inte att kombinera med kundens databaslösning. Alltså måste vi lyfta kunden till 4.5 och inget annat. Hur vi håller reda på detta? Genom dokumentation. 

Man vill också dokumentera funktionalitet:

Den senaste releasen till kund var en katastrof och fick rullas tillbaka. För att upprätthålla förtroendet hos kunden satsas hårt på att den nya versionen ska vara klockren. Dock uppstår ett problem: ingen vet exakt hur systemet fungerar hos kund. I vissa tveksamma fall får utvecklingsgruppen rösta för att avgöra om något ska betecknas som "bug or feature". Därför dokumenterar vi funktionalitet.

Vi dokumenterar interaktioner med kunden:

En upprörd kund hör av sig och klagar på att funktionalitet BEPA, som de betalat dyra pengar för, slutat fungera. Efter en kort kodgranskning visar det sig bero på att någon för ett och ett halvt år sedan gjorde BEPA konfigurerbar och därefter stängde av den. Den upprörde kunden undrar varför. Eftersom någon inte längre finns kvar på företaget blir svaret "Förhoppningsvis för att någon från er bad om det". Därför dokumenteras kund-kontakter.

Ibland dokumenterar vi också den kod vi skriver:

Det är lätt att förstå vad värdet av konstanten m_dDelayStartupSec används till. Det är svårare att förstå varför den har värdet 4.0. Det är helt omöjligt att veta att om vi ändrar värdet på m_dDelayStartupSec här i applikation X, så måste vi också ändra motsvarande konstant i applikation Y annars kommer systemet att krascha vid start. Därför dokumenterar vi ibland även kod.

IT-branschen - detta är ett problem

Jag arbetar som systemutvecklare. Det har jag gjort i snart tio år, hälften av tiden som konsult. Jag har arbetat med skarpa system inom bland annat finans- och försvarssektorn med mycket höga kvalitetskrav. Jag har en mycket kvalificerad universitetsutbildning med matematik som huvudämne. Om jag idag skulle söka en utlyst tjänst inom IT-branschen skulle jag säkert vara en intressant kandidat. Men, jag klarar i alla fall inte de programmeringstester som görs i första sållningen på många företag.

Mitt huvudämne på universitetet var matematisk logik, jag förstår hur pekare fungerar. Det betyder inte att jag inte kan bli lurad av krånglig pekararitmetik. Jag har aldrig arbetat med C och förstår inte poängen med att kompaktifiera kod tills den blir krånglig. I mitt arbete skapar jag nya klasser i C++ högst en gång i månaden och håller inte reda protected, virtual och abstract till vardags.

Den grundläggande orsaken till detta är att jag aldrig lärt mig programmera. De få programmeringskurser jag läst gavs tidigt 90-tal med Pascal som huvudspråk. Jag trodde nog att jag efter snart tio års arbete som programmerare skulle ha lärt mig dessa saker, i alla fall tillräckligt bra för att klara ett grundläggande programmeringstest, men det har jag inte. Under mitt arbetsliv har jag arbetat i Linux- och Windows-miljö. Jag har programmerat i C++, C#, Delphi, Python och PostScript, plus lite annat gott och blandat. Jag har tvingats fuska lite i webbprogrammering, hanterat databaser i MSSQL och MySQL, beblandat mig med Word och Excel. Både jag och mina arbetsgivare anser att jag utan problem klarat av att utföra mitt arbete.

Det har aldrig funnits några begränsningar av typen "det där är för komplicerad/viktig kod för dig att arbeta med". Slutsatsen blir: dessa tester speglar inte förmågan att göra ett bra jobb som systemutvecklare. För att tydliggöra problemet: jag är en etniskt svensk man, med svensk universitetsutbildning i matematik och stor arbetslivserfarenhet av programmering. Ändå passar jag inte in i mallen för hur en programmerare ska vara. Hur olik mallen jag varit om jag istället hade haft biologi som huvudämne, vill jag inte tänka på. Eller haft en universitetsutbildning i datavetenskap men från ett land där man gör saker på ett lite annorlunda sätt.

För att försöka sluta lite konstruktivt kommer här några förslag på vad vi kan göra åt detta:

• Inse att klassiska programmeringstester mäter hur lik en stereotyp datavetare någon är, inte hur bra de kan utföra arbetet.
• Dessa tester är oftast bara till för att sålla ut de omöjliga. Fråga något annat: matematiska problem, NOG-delen från ett högskoleprov eller algoritmer beskrivna med naturligt språk.
• Ge människor chansen. Om det finns en möjlighet ta in ovanliga med intressanta kandidater som prov- eller projektanställda och ge dem en möjlighet att bevisa sin förmåga eller potential.

Thente har fel, fel, fel

När jag lästa rubriken på Jonas Thentes krönika i Dagens Nyheter i morse ("Matematik som huvudämne tillhör dåtiden - politikerna bör satsa framåt") var det nära att jag bokstavligen satte kaffet i vrångstrupen. När jag sedan läste krönikan bekräftades min förskräckelse. Thente har nämligen fel i nästan alla delar av sitt resonemang:
Thente berör Wireds kolumn "Japaness scholgirl watch" och menar att man också i ett land som Sverige skulle kunna se på ungdomen för att lära känna framtiden. Men Thente missar att de japanska skolflickor studerades i egenskap av avantgarde konsumenter. Visserligen bör skolan utbilda unga till att bli medvetna och kritiska konsumenter men skolpolitiken bör i första hand tillgodose Sveriges behov av framtida producenter. Det är ju på producentsidan som jobben finns.

Thente säger att om man behärskar språk så har man ett redskap för att lära sig saker men om man behärskar matematik så kan man (bara) matematik. Thente missar att det är just för att det också är ett redskap som matematik så tydligt lyfts fram av pedagoger. Om man behärskar matematik så behärskar man ett sätt att resonera och angripa problem som man har nytta av på alla områden, till exempel för att förstå samhället eller inom kulturen. Ens förmåga till kritiskt granskande stärks av att kunna analysera sammanhang stringent.

Thente säger att de unga i framtiden kommer att jobba på internet, nåt med media. Thente missar att internet, även sociala media, inte i första hand är en skapalse av språk utan av matematik (läs programmering). Även om det inte är så att den eventuella framgången hos ett internetfenomen är avhängigt av den tekniska kvalitén, så är god programmering den grund framgångsrika aktörer står på. Google, Faceboook och Twitter är ingenjörsprojekt, inte skapade av folk som vill jobba inom nåt med media.

Thente påstår också att det hittills varit så att svaret på skolans "vad vill du bli?"-enkäter väl har speglat den framtida arbetsmarknaden. Är det verkligen sant?

Det finns bara en punkt där jag vill ge Thente rätt: syftet med matematikundervisningen (och alla annan undervisning) bör inte vara att klara sig bra i internationella mätningar. I skolan har man under lång tid kämpat med att få eleverna att förstå att de ska lära sig för framtiden och inte för prov, att ledande skolpolitiker i dag inte kan förstå skillnaden är ett oerhört bakslag.

Vad betyder "+1" och "Like"?

Rekommendationstjänster för länkar ("social bookmarking") har funnits under lång tid (Delicious 2003, StumbleUpon 2004 och så vidare). Så när Facebook introducerade sitt öppna API för "Like" (som gör att alla sidor kan ha en "Like"-knapp) och Google "+1" så kan det verka som en naturlig fortsättning. Och visst, ett syfte bakom tjänsterna är säkert att förbättra användarupplevelsen för användare av Facebook och (kanske) Google+ (mer om Google+ på ComputerSweden, DN, SvD. Att hålla kvar människor på sina sidor har ett egenvärde för företagen (ökad exponering för reklam). Men det finns en annan sida av dessa rekommendationstjänster som kan vara värd att peka ut.

Sedan Google exploderade på sökmotorsmarknaden så har det huvudsakliga datamaterialet som de olika sökmotorerna analyserat varit länkar (mer om detta i det inlägg om PageRank som jag kommer att skriva någon gång). Och länkar är ett "öppet" datamaterial, det vill säga alla sökmotorer har haft samma möjlighet att skaffa sig data genom att "spindla" nätet. Utan att ta till överord som "demokratiskt" eller "rättvist" så kan vi konstatera att alla seriösa sökmotorer i princip haft tillgång till samma datamaterial och att det varit kvalitén hos de algoritmer de använt för att organisera materialet som varit avgörande för tjänstens användbarhet.

Det är detta grundläggande tillstånd som "Like" och "+1" ändrar eftersom det datamaterial som dessa funktioner genererar är "slutet", ägs av företagen. Google kan inte använda ditt mönster av "Like"-tryckningar för att förbättra sina sökresultat och om "+1" blir populärt som kommer det att ytterligare stärka Googles grepp över sökmarknaden. Detta gäller alltså inte bara frågan om att göra sökresultaten mer personliga utan datamaterialet kan också användas för att förbättra resultaten för användare som aldrig använt Facebook eller Google+. Förutom enkla popularitetsmätningar (användare som har angivit intresset hundar tycker att sida 1 är tre gånger bättre än sida 2) kan man också hitta mönster i preferenser (användare som gillar sida 1, 2 och 3 gillar oftast också sida 4) med mera.

Detta är inte huvudsakligen en appell mot användandet av "Like" och "+1" men om det blir populärt kommer det att få konsekvenser för hur nätet kommer att se ut i framtiden.

passphrase, inte lösenord

På många engelskspråkiga sidor på nätet ser man ofta idag ordet "passphrase" istället för "password". Jag har tänkt att det är ett utslag av amerikansk "political correctness" där man lägger stor vikt vid vilka ord man använder för att beskriva en företeelse. Men det verkar som om det skulle vara bra att prata om lösenmening och inte lösenord på svenska.
Företaget jag arbetar för just nu har skärpt sin IT-säkerhetspolicy (på grund av en olycklig incident där denna jättelika amerikanska militärindustriella koncern råkat smuggla militärt material till Kina). Som en del av detta krävdes att alla bytte lösenord till nya med minst 12 tecken (varav minst en siffra och versal). Detta gav upphov till stort huvudbry hos de personer som sitter bredvid mig i det öppna kontorslandskapet. Anledningen: det var så svårt att komma på ord som har minst 12 bokstäver. Ett lösenord är i första hand ett ord.

Excel är värst

Många människor i databranschen klagar på Microsoft och deras produkter. De klagar på hela Windows eller på enskilda program. Jag instämmer och skulle vilja argumentera för att Excel är värst av Microsofts produkter.

I mitt nuvarande projekt tvingas jag interagera en hel del med Excel. För att fylla en databas sitter jag vid en dator med Microsoft Windows och importerar data från Microsoft Excel in i en databas av typen Microsoft SQL Server. Det fungerar nästan aldrig. Och med "fungerar inte" menar jag inte att SQL Servern vägrar att importera något och ger ett felmeddelande. Jag menar inte heller att den importerar data och sen ger ifrån sig en varning om att det kanske inte gått så bra. Vad jag menar med inte fungera är att den säger att allt gått bra men sen har den låtit bli att ta med godtyckligt mycket av innehållet i Excel-arket.

Vad som händer är detta: Excel bestämmer sig för att på egen hand gissa vilka typ av data en kolumn innehåller (siffror eller text). Gissningen verkar basera sig på typ de första 20 raderna i arket. Därefter håller Excel fast vid denna gissning även om jag manuellt går in och "typar om" kolumnen, till exempel från siffror till text. När jag importerar berättar Excel för SQL Server att det är siffor i en viss kolumn. Men SQL Server märker att det inte är sant, även om de första 20 raderna bara har siffror i kolumnen "Ålder"så har inte alla rader det (en del har texten "Inget att tala om"). SQL Server har redan skapat en kolumn för siffror att lägga datat i och där passar inte text in. Alltså bestämmer sig SQL Server för att strunta i alla fält med text och, utan att berätta det, lämnar kolumnen tom i tabellen. Eftersom detta fel har inträffat för nästan alla de filer jag försökt importera använder jag nu omvägen via text, från Excel till CSV till SQL Server.

Men det är inte detta fel som gör att jag menar att Excel är värst utan de konsekvenser det kan medföra. Om en annan person har problem med Word är det värsta som kan hända mig att jag får ett dokument som är svårt att läsa. Men jag är rädd för att en massa för mig viktig data förvaras och behandlas i Excel. Den lön jag får kan nog ha Excel-behandlats. Om jag har gjort en ansökan om något bidrag (a-kassa eller föräldraförsäkring) som behandlas av en tjänsteman så är Excel säkert inblandat. Överhuvudtaget finns nog en mycket stor andel av all aktiv data i samhället i Excel-ark. Därför har Excel en mycket större makt att förstöra mitt liv än vad till exempel Word har.

(Medan jag skrev detta kommer jag på att med samma argument som ovan så är nog kanske Windows ännu värre. All data i Excel-ark finns ju dessutom i osäkra och instabila Windows-system.)