Mars 2010 Krogvakter och övervakningskameror.
Att dra likheter mellan den binära och verkliga världen kan vara roande.
I Erlang finns ett begrepp, guard, som är väldigt fyndigt.
Du skyddar din funktion, procedur, metod med en if sats, en guard, för att slippa
ovälkommen data - precis som en krogvakt motar bort ovälkomna gäster.
Om du väl kommit in på en krog, flygplats... så används övervakningskameror för
att checka av att alla beter sig normalt. Termen övervakningskod existerar mig veterligen
icke, men du skriver den omedvetet. T.ex. om din kod skall uppdatera en databastabell.
Då kan det ibland vara vettigt att göra en läsning mot databasen först, bara för för att
verifiera att nätet är uppe, att en ev. nyckel inte redan existerar ..., dvs en övervakning om att
allt verkar fungera normalt.
Om en övervakningskamera skulle fånga något onormalt, då är det högst troligt att
en eller flera vakter skickas dit för att reda upp situationen. I din kod kan du använda try/catch
som övervakningskamera. Try fångar upp onormala händelser och catch försöker reda upp situationen.
Så en bit kod kan vara en spegel av livet själv - om man har lite fantasi.
I den bistra verkligheten eskalerar behovet av vakter och övervakningskameror.
Är det samma i den binära världen. Naturligtvis är det så. Jobbar du i den öppna
internet världen, då kan du vara säker på att någon vill lura din kod.
Tänk bara på det hemska sql injection, burr och fy.
KISS från DAP
December 2009 Programmeringsspråket XML!?
XML är ungefär som en struct i C. Man skapar en karta som kan läggas över ett antal
bytes, som sedan kan tolkas på ett intelligent sätt. Skillnaden är egentligen bara
att XML använder vanlig läsbar text för att beskriva data, medans man i en C struct
använder ett lite mer kryptiskt sätt.
Den som arbetar med structar har egentligen aldrig några bekymmer med att förstå
och hantera dem, och det borde väl inte den som använder XML heller ha. Tvärt
om, det känns som att XML borde vara lättare, det skrivs ju med "human readable" syntax.
MEN, den som ger sig in i XML världens terminologi, blir milt uttryckt konfunderad.
Det börjar med SGML, forsätter med tolkar, mallar, scheman ......
Det skrivs böcker alá tegelstenar om XML. Om structar skrivs det ett kapitel i
en programmeringsbok.
Någonstans i XMLs historia måste det gått totalt fel. Det är så mycket inverterad
KISS det bara kan bli. Kanske man låste in ett antal teoretiker med noll
verklighetsförankring i ett rum, eller drack för mycket sprit, vad vet jag.
Totalhaveriet för mitt XML förtroende är att man i platsannonser
ofta kräver att man skall kunna XML. Har du sett en platsannons som kräver att
man skall kunna hantera structar. Knappast! Men XML anses vara så komplext att man
upphöjer det till samma nivå som ett programmeringsspråk.
Vart gick det fel?
KISS från DAP
November 2009 PI faktorn
Det finns en bra regel för att tidsuppskatta hur lång tid det tar att bygga
en NY mjukvaruapplikation. Multiplicera den tid du tror det tar med PI, då hamnar
du på en realistiskt tidsplan.
Formeln verkar fungera bra på det mesta.
Skall du bygga ett program från scratch, då är det först när du skrivit om koden tre
gånger som den blir riktigt bra. Snygg, optimerad, kommentarsatt, minimalt med exit
och return, alla villkor har en default utgång, bra felhantering... Listan
kan göras lång.
Skall du modellera en databas från scratch, samma sak här. Du tror att du klurat ut
den slutgiltiga designen, men du kommer att få tänka om minst två
gånger till innan du fått en anständig lösningen.
Till och med vid namnsättning av variabler, databasfält och tabeller,
klasser och metoder, så brukar rätt namn dyka upp efter en sådär tre försök.
Talet 3 är tydligen lite magiskt. Tredje gången gillt, alla goda ting är tre,
de tre vise männen.... Till och med företag kallar sig rätt och slätt för 3.
I den onda verkligheten, där får man inte alltid tid att göra tre försök.
Stöter du på kod med tomma kommentarblock, då har programmeraren
blivit bortjagad - kanske till och med bortskrämd från kodandet redan efter varv 1.
Om du nu inte är en UBP (Usain Bolt Programmerare), dvs från en annan planet,
och accepterar tanken att det inte går att skriva den ultimata koden direkt.
Då kommer du att bygga robustare kod, som tål tidens tand bättre - om du itererar
minst tre gånger. Hellre tre snabba varv än ett enda långsamt varv.
( Det verkar änna som att vi hamnade i det Agila till slut ).
KISS från DAP
Augusti 2009 Framtidens programmeringsspråk - hmmm, tungt ämne
När kommer det ett nytt revolutionerande programmeringsspråk,
ett som ruskar om hela programmeringshantverket. Vi har levt med
true eller false sedan urminnes tider, så det börjar kännas lite enformigt att
if:a, while:a och for:a hela dagen lång.
Vad är det som bromsar upp utvecklingen?
Vi gör ett försök att tänka utanför ramarna!?
Trä är ett material med en massa bra egenskaper. Konstruktörer har under årens lopp
lärt sig bemästra dess egenskaper och skapat fantastiska konstruktioner, tänk bara på
ett vikingaskepp. Trät ersätts många gånger av plast, ett material med ännu
fler bra egenskaper. Med plast kan konstruktörer bygga nästan vad som helst.
Vad har mjukvarukonstruktörens material för egenskaper? En endaste liten fjuttig
egenskap - att anta värdet noll och ett. Hoppsan, det kan förklara en del.
Att överhuvudtaget skapa något ur ett sådant enfaldigt material är klart häftigt,
och klart begränsande. Så då är vi tillbaka där vi började. Det revolutionerande
programmeringsspråket ligger långt borta i tiden, först måste vi få ett "grundämne"
med fler och bättre egenskaper. Det tror i alla fall DAP.
KISS från DAP
Maj 2009 Till minne av web.sql
Då var den gjord då, den första kompletta PHP applikationen.
Det gick relativt lätt, precis lika lätt som det gjorde runt mitten på 1990 talet?
Vadå, då fanns väl inte PHP. Nej, helt rätt, men det fanns en produkt med namnet web.sql
skapad av databasföretaget SYBASE. Arkitekturen och tankarna var identiska och DAP älskade den.
MEN, "farbröder i kavaj" dödade produkten. Den var för simpel, Java med Applet skulle det vara,
det var riktiga grejer det. Så SYBASE slutade att supporta produkten = en säker död.
MEN, det var (och är fortfarande) ett härkejobb att bygga webb applikationer
med Java eller .NET - så reaktionen blev verktyg som PHP.
PHP skapades i Danmark. Som brukligt i databranschen så tar man ett gammalt koncept,
skruvar lite på det och ger det ett nytt namn = vi har skapat en helt NY produkt.
MEN, danskarna har gjort ett väldigt bra jobb så ingen skugga falla över dem.
MEN, konceptet föddes som så mycket annat i Silicon Valley, så kanske kan
vi lite skadeglatt kasta lite skugga över Danskarna ändå.
KISS från DAP
Mars 2009 Kodsnobberi?
En programmerare har två kunder, Användaren och andra programmerare.
Användaren struntar högaktningsfullt hur programmet är skrivet, bara det fungerar bra.
Andra programmerare är däremot väldigt intresserade av att programmet är välskrivet,
för de måste förstå koden när den behöver uppdateras.
Nu följer en lite utvikning, obs indenteringen.
DAP följde en tråd på Computer Swedens nyhetsbrev. Någon/några ansåg att det händer
för lite med Java språket och det som händer, det händer för långsamt.
Nu följer ytterligare en lite utvikning, obs indenteringen.
DAP har med jämna mellanrum kommit i kontakt med relationsdatabaser.
Och det som fascinerar i sammanhanget är - det händer väldigt lite med språket.
En SQL sats ser ut som den alltid gjort och samma termer används.
'Vafför det är på detta vise' kan man ju fundera över,
men ett är säkert - det är väldigt trevligt att känna igen sig och att förstå
SQL koden utan större mankemang.
Ett programmeringsspråk består av de tre komponenter sekvens, iteration och selektion.
That's it. Språket i sig är därför relativt ointressant, det är omgivningen typ
klassbibliotek, kodstöd, dokumentation osv. som är intressant att förädla.
Så varför överhuvudtaget fundera över att införa nya språkkomponenter?
Den nya FOR loopen som kom i Java är visserligen elegant, men tillför knappast något.
Nej tack, inga obehagliga överraskningar när koden skall rättas, det är stressigt nog ändå.
Koncentrera er på att skriva KISS (Keep It Simple, Stupid) kod istället.
KISS från DAP
Februari 2009 - Vi kommenderar dig, var kreativ!
DAP läste en intressant artikel om det anti-kreativa med centralisering. Tanken for genast
iväg till de "Kreativitetsdagar" DAP genomlidit. Minnen om föreläsare som lovat att lära
oss Morse alfabetet på en kvart, brainstopping möten, förlåt brainstormingsmöten med gula
lappar, verbala föreläsare som för stunden kan få precis vad som helst att låta djupt.
Kanske beror det på otur, ointelligens eller något annat som börjar på o, men ingen
"Kreativitetsdag" har efterlämnat någon som helst kreativ tanke i DAPs hjärna.
Nej, iden med att centralisera avdelningen eller hela företaget för en dag i kreativitetens
tecken är nog lika fel som att försöka få en lergök gala.
Nej, gör så här istället. Bjud hem folk med höga bas-kunskaper i företagets kärnverksamhet,
t.ex. mjukvara. Vi kan kalla dem coach-pedagoger. Låt dem helt anspråkslöst gå runt och
diskutera med medarbetarna. Var noga med att medarbetarna förstår att coacherna är där för
att höja kompetensen inom företaget. Vitsen är att bollen nu ligger hos medarbetarna. De som
blir intresserade av att knyta en mer varaktig relation med en coach, skall i fortsättningen
få möjlighet att träffa coachen regelbundet- det blir en slags michmatch av
terapi/utbildning/kreativitet.
Den här iden har fungerat mycket bra hos några mjukvaruföretag i Japan...
Nej, DAP skojar bara. Detta är fria fantasier, men iden verkar bra och
att arbeta som coach-pedagog verkar lockande.
Kanske värt ett försök, någon som är intresserad? Hoer af Eder!
KISS från DAP
Januari 2009 - Goa Buggar!
När man hör ordet bugg, då tänker man intuitivt på logiska fel. Programmeraren har
tänkt tokigt, inte förstått, slarvat eller helt enkelt inte fått rätt underlag.
Men även programmeringsspråket i sig kan orsaka buggar.
Många nyare språk har lånat sin syntax från gamla hederliga (?) C, som såg livets ljus
redan på 1970-talet. Lite konstigt att en så gammal syntax lever vidare kanske, men det för
ju i vilket fall med sig att det är lättare att lära sig ett "nytt" språk.
Hur som helst så finns där en del "mörka hörn".
Nollräkning vid indexering i fält, vektorer eller arrayer, kärt barn har många namn, har kostat
mycket genom åren. Undrar hur mycket driftsatt programvara som hoppar över första/sista
fält-elementet. Hoppas att inga kärnkraftverk är inblandade.
En annan goding är if( myVar = anotherVar ). Den ÄR lömsk!! och har garanterat drabbat alla.
Om man copy/paste programmerar mycket, och vem gör inte det. Då dyker den här fulingen upp.
for( int i = 0; i < 10; i++ );{
Har aldrig förstått riktigt varför, men så är det.
Skillnaden mellan a++ och ++a är verkligen lurig och jag har aldrig fattat vitsen med att
att de skall bete sig olika.
Vem har inte skrivit följande kod när man vill jämföra två strängar.
if( string1 == string2 )
Funkar kanske i en del skript språk, men är en given bugg i exempelvis Java.
Pekare-programmering är lurig, exempelvis så beter sig *ptr+1 och *(ptr+1) helt olika,
men pekare är ärliga, dvs det är lätt att upptäcka fel då resultatet oftast blir KATASTROF.
Summa summarum så gäller det att ha alerta programmerare.
KISS från DAP
December 2008 - Var tog alla intuitiva GUI:n vägen?
Gamla övervintrande GUI-designers, hur mår ni nuförtiden?
Ni som vaktade över rena, funktionella och framförallt intuitiva
grafiska gränssnitt. Ni måste gråta inombords när ni sätts framför
ett GUI a´la 2000-tal. Fullknökat är ordet, sa Bull.
Email program får bli representant för nya djärva GUI:n.
DAP har drabbats i tur och ordning av, First Class, Lotus Notes och Outlook.
Email program är egentligen fel beteckning, fullknökade program är ordet, sa Bull.
Huvudanledningen till att installeras är dock att man skall kunna skicka och ta emot Email.
Och hur svårt kan det vara att få ett program att hantera små textdokument intuitivt.
Tydligen svårt, sa Bull.
First Class hade den egenheten att folk ofta skickade sitt svar till
alla mottagare av brevet. Väldigt roligt för alla utan den som drabbats.
Webbvarianten av programmet var helt avskyvärd, ångestframkallande, sa Bull.
Lotus Notes är nog det värsta program rent GUI mässigt som DAP stött på.
Att stänga ner ett fönster av misstag drev fram många fiktiva svordomar.
Det kunde ta tid innan man hittat den väl dolda hemligheten igen.
Att byta tids-vy i kalendern, frustrerande sa Bill. Att bifoga ett dokument
var en väl förborgad hemlighet, panikframkallande sa Bull.
Outlook ser snyggt ut. Första brevet gick dock iväg i tre exemplar, skämmigt sa Bill.
För DAP eller GUI-ansvarige, båda sa Bull.
Några Outlook data: 87 kommandon under 8 verktygsfält.
GUIt är uppdelat i 6 delfönster och det finns 37 snabbval ...... fullknökat, sa Bill.
Hoppas att trenden vänder snart. Program som lider av Elefantasis har åtminstone DAP
fått nog av. Men betänk - först i version 2007 blev Elefantasis:ornas Elefantasis,
Microsoft Office användarvänligt, och det tog vääääääldigt lång tid.
KISS från DAP
November 2008 - En KodTalliban (eKTb) vet alltid bäst.
Det börjar redan i kodskrivandet. En måsvinge MÅSTE stå på samma rad som villkoret.
Den editor som eKTb använder är den enda riktiga. För att inte tala om programspråk - "C med printf"
är ofta det enda sanna. UNIX-script gurus blir med tiden garanterat eKTb och fnyser åt allt
som har med GUI att göra. Samma sak med databasadministratörer, allt görs från prompten.
OS skapar ofta eKTb. Där brukar Linux utmärka sig. Microsoft har sina hängivna supportrar men
denne utvecklas sällan till eKTb. Microsoftshataren utvecklas dock ofta till eKTb.
Open Source anhängaren blir med automatik eKTb.
Sålunda, eKTb kan med sin arrogans och trångsynthet vara verkligt påfrestande, och de finns på de
flesta arbetsplatser. Men har man varit med ett tag, då vet man att man skall vårda eKTb-kontakt ömt.
När "stora obegripliga felet" dyker upp klocka halv fem, eller installationen av senaste rättningspaketet
vägrar fungera timmarna innan deadline - just precis då är en KodTalliban av rätt sort precis rätt person
att hålla i handen.
KISS från DAP
Oktober 2008 - VVW, Våga Vägra Webbläsaren
Att driva saker för lång är vi bra på, vi människor. Vi har ett slags pendel-beteende.
Det är först när ett ändläge uppnåtts och vi tvingas byta riktning, som det sker en förändring.
Bolånekrisen och IT-bubblan och är några grandiosa exempel.
Undrar om inte den underbara och dyrkade webbläsaren börjar nå sitt ändläge.
Allt försöker vi tränga in i den gamle käre HTML-visaren. Nya script-språk, ramverk och
strategier dyker upp i något som liknar en slags tävling i att dölja dess begränsningar.
Nej, VVW och tänk i nya/gamla banor. Ge oss smarta, snabba applikationer som jobbar direkt
mot nätet utan att behöva ta hänsyn till en gammal HTML-visare. Det är ett direkt hot mot
folkhälsan att tvinga oss att trycka på samma gamla fossila knappar - om och om igen. För att sedan
få uppleva lååånga blodtryckshöjande svarstider.
För övrigt så har Word i Office 2007 blivit otroligt mycket bättre.
KISS från DAP
September 2008 - KnappTryckningsUtrotning
Hur många meter rullar din mus på en dag?
Eller hur många knapptryckningar gör du på din dator under en dag?
Förmodligen vet du inte svaret, men ett är säkert - musen har rullat långt
och knapptryckningarna har varit många.
DAP tänkte därför puscha för två favoriter när det gäller att utrota
knapptryckningar, inkrementell sökning och färgmarkering av text.
Med inkrementell sökning menas att sökningen börjar redan när först
tecknet har angetts. Sökningen förfinas sedan allteftersom ytterligare
tecken anges. När man är nöjd med sin förfining, (det räcker ofta med 3-4 tecken)
söker man bara vidare i texten via Enter knappen.
"Vanlig" sökning däremot, där man först anger hela texten för att därefter
starta sökningen, den känns både som gårdagens nyheter och mindre intelligent.
Jämför gärna CTRL+F funktionen i Firefox och Internet Explorer.
Funktionen "Färgmarkering av text" (typ överstryckningpenna) finns i en del program,
men att den används till textsökning är ganska ovanligt.
Det fungerar så att man anger vilken text som skall färgläggas och får som svar
hur många färgläggningar som gjorts. Sedan kan man scrolla igenom hela text-massan
och låta ögat fånga upp de ställen som färglagts. Det är mycket effektivt.
Word i Office 2007 har funktionen, men den är lite svår att hitta.
I CommanDOS, NoteMyJava och HideMyText har du möjlighet att testa funtionerna,
och som sagts tidigare - när man väl vant sig vid dessa två sök-metoder,
då är det en pina när de saknas.
KISS från DAP
Augusti 2008 - iPhone och lergöken
Nu har även DAP provat en iPhone. Den var superb!!!
När gitarrhjälten Eric Clapton spelade i Stockholm med sitt band Cream första gången,
så intervjuades en svensk gitarrist om vad han tyckte.
Han svarade ungefär "Efter att ha sett Eric spela, så funderar jag på att gå över till lergök istället".
Ungefär så borde GUI skaparna för mobiletelefoner, GPS:er .... känna sig. Totalt utskåpade alltså.
Men det går ju förstås att bli inspirerad!
KISS från DAP
Juli 2008 - Skynda er på med kodandet så vi kan börja testa!
Så löd orden från projektledaren. Tänk om vi istället fått höra: Ta god tid på er med kodandet så att vi slipper testa!
Man hade nog undrat om man hört rätt, både en och två gånger.
En bilfabrik hade en gång för länge sedan en efterjusterings-avdelning. Den tog hand om missarna som uppstod när
bilen sattes ihop. Det var sista anhalten för många bilar, innan de kunde levereras till kund.
Avdelningen sysselsatte många och var nog riktigt trevlig att arbeta på. Sedan tänkte någon efter.
Kanske det är bättre att bygga bilen med så bra kvalite som det bara går - från början. ( Det kan ha varit en japan! )
Många mjukvaruprojekt har nog inte testat den tanken ännu, utan "test-bygger" fram den slutliga leveransen till kund.
En form av efterjusterings-avdelning alltså.
För övrigt tänkte de som tog fram JUnit väldigt bra.
KISS från DAP
Juni 2008 - Keep It Simple, Stupid - KISS!
Vet inte var begreppet kommer ifrån, kanske det inte ens uppstod inom mjukvarubranchen.
Om det härstammar från de "mjuka människorna" kan jag lätt framkalla en bild i huvudet där
en uttröttad kollega förtvivlat reser sig bakom sin bildskärm, resignerat slår ut med armarna
och låter DE orden komma över läpparna. Eller kanske en luttrad projektledare som med
bedjande ögon vädjar till teamet inför projektstarten med DE orden, det sista uttalar han nog inte.
Hur som helst så är det en vacker regel som borde genomsyra mycket av det vi gör.
Här kommer några andra varianter:
- Keep it as usual (för den late),
- Keep it in time (för controllern),
- Keep it my way (stora egot),
- Keep it ??? (novisen).
De får representera det "onda", det som gör det svårt för oss att följa den vackra regeln.
Av dessa onda ting, så är nog "stora egot" den svåraste motståndaren. Det är oftast han/hon
som drar upp riktlinjerna eller kommer med självsäkra uttalanden om det förträffliga med just DET ramverket.
DAP misstänker att "stora egot" ofta gömmer sig bakom en grupp av människor. Ett aktuellt
exemplet är de som bygger ramverk för att "förenkla" sättet att bygga icke Webb applikationer.
Vi skall tydligen bygga dem på samma produktiva!! sätt som man bygger en Webb-applikation.
Man blir misstänksam, det luktar KITS, Keep It To Simple. Ett speciellt kännetecken på KITS är lager på lager på lager på lagret.....
Vi avslutar med en alldeles ny regel, BD (Behövs/Duger regeln) som DAP bjuder på.
Den kan förhoppningsvis leda dig in på ett enklare spår i stunder av tvivel.
(Förkortningen är även nationalitetsbeteckningen för motorfordon från Bangladesh).
- Behövs XML eller duger vanliga textfiler?.
- Behövs det en databasmotor eller duger det med sekventiella filer?
- Behövs det en länkad lista eller duger det med en array?
- Behövs det lite systemering eller skall vi tuta och köra?
- Behövs chefen eller duger det med en kalender?
KISS från DAP