Det poppar ständigt upp nya tekniker för utvecklare att förkovra sig i. Vid sidan av det nya blir också många tekniker och språk bortglömda och klassade som uträknade och föråldrade. Ola Rende har hittat guldkornen i mossan och listar nedan fyra tekniker och språk som funnits länge men som fortfarande är både aktuella och värdefulla.
XPath (1999)
Först ut i listan är ett 17-årigt frågespråk framtaget för att utvinna data ur XML-träd. Markup-språket XML har ryktet att vara särskilt skrymmande och kan med sin enorma specifikation knappast lyftas fram som en förebild av god design. Faktum är att vi troligen är fast med XML ett antal år till, så varför inte göra tillvaron lite lättare för oss?
XPath är ett språk som påminner om både CSS-selektorer och regular expressions. Syntaxen kan vid en första anblick kännas väldigt abstrakt och oförståelig men det är relativt enkelt att bena ut vad som pågår. Låt oss gå igenom ett exempel med följande XML-dokument:
<?xml version="1.0" encoding="utf-8"?>
<catalog>
<books>
<book id="bk101">
<author>Gambardella, Matthew</author>
<title>XML Developer's Guide</title>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications with XML.</description>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<title>Midnight Rain</title>
<genre>Fantasy</genre>
<price>5.95</price>
<publish_date>2000-12-16</publish_date>
<description>A former architect battles corporate zombies, an evil sorceress, and her own childhood to become queenof the world.</description>
</book>
</books>
</catalog>
Om vi nu ur detta dokument vill utvinna böckernas ID:n (lagrat i attributet id) på samtliga book-element, skulle vi kunna använda en regular expression. Men om det skulle finnas id-attribut på andra element eller om vi vill ha den första eller sista boken kommer vårt reguljära uttryck tvingas att växa i längd och komplexitet.
Vi kan dock få ut samma information med en relativt enkel XPath-fråga:
/catalog/books/book/@id
Denna fråga ger då resultatet “bk101” och “bk102”. Om vi lägger till tre tecken:
/catalog/books/book[1]/@id
så får vi istället ut endast det första elementet i listans ID. Vi kan även filtrera på innehållet i element och attribut, enligt följande:
/catalog/books/book[@id="bk101"]
Denna fråga ger oss endast projekt-element med ID:t bk101.
Som synes kan XPath-frågor med väldigt liten möda svara på frågor som med en fullfjädrad XML-parser skulle kräva en hel del kod att besvara. Det eleganta XPath-språket är dock inte längre begränsat till XML, då utvecklare på senare år även tagit med sig idéerna och skapat motsvarande lösningar för andra språk. Ett exempel är JSONPath som använder i stort sett samma frågesyntax för att utvinna data ur JSON-dokument.
SQL (1986)
Relationsdatabaser är en teknik som i skrivande stund funnits i över 30 år. Trots tappra försök från såväl objektdatabaser som NoSQL-databaser så har de inte puttats ner från databastronen. Så ser det ut att forsätta den närmaste framtiden. Därför är relationsdatabasernas egna frågespråk, SQL, ett språk som är mödan värd att investera tid i. Tack vare att språket har standardiserats (se ISO-standarderna SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2006, SQL:2008 samt SQL:2011) så kan vi som utvecklare och databasadministratörer röra oss mellan olika databaser och ställa dem våra frågor utan större svårigheter.
Jag har i tidigare artiklar gått in i närmare detalj på vad man kan åstadkomma med SQL och tänker därför inte upprepa mig i denna. Vad som är värt att tänka på, är att olika databaser trots standardisering innehåller en del olikheter orsakade av meningsskiljaktigheter vid tolkingen av standarderna. Det är också är skälet till att vi talar om de olika databasernas frågespråk som “SQL-dialekter”.
På en punkt blir skillnaderna i dialekterna särskilt tydliga: lagrade procedurer. I detta hörn av SQL är det inte mycket som är likt mellan databaserna. Många avvikande, leverantörsspecifika samt patentskyddade tillägg förekommer även, vilket är varför jag inte kan rekommendera fullt lika djupa studier i denna typ av SQL.
Shellscript (1971)
Linux och Unix har ett järngrepp om servermarknaden och visar inga tecken på att mattas av. Som backendutvecklare är det av största vikt att kunna sätta upp, konfigurera och underhålla *nix-servrar. Till vår hjälp har vi dock en massiv verktygslåda av program, små som stora, som utvecklats för ändamålet sen Unix begynnelse.
Med det sagt menar jag inte att du ska sträva efter total kunskap om Unix/Linux biblioteken. Däremot vill jag visa hur mycket man kan åstadkomma genom att kombinera många småprogram som vart och ett gör en enda sak och gör den bra.
Föreställ er exempelvis att vi har ett API som exponerar en väderleksrapport i ett format där veckodagarna kommer på den första raden följt av deras temperaturer på den andra raden:
mon tue wed thu fri sat sun 13 12 8 14 17 16 18
Vi kan nu skriva en one-liner för att plocka ut temperaturen för exempelvis tisdagen:
curl http://example.com/weather | cut -f2 -d ' ' | tail -1
Resultatet blir då, rätt och slätt, 12. Med | (pipe) tar vi strömmen av tecken och skickar den vidare som input till andra program som gör sina operationer och i sin tur skickar den vidare.
Vi kan även omdirigera om datat vi får ut från kommandot till en fil:
curl http://api.example.com/weather | cut -f2 -d ' ' | tail -1 >> weather.log
eller använda en fil som input till ett kommando:
sort -n -r < weather.log
En långsam operation kan göras till ett icke-blockerade bakgrundsjobb enbart med ett &-tecken:
curl http://api.slow-server.com/long-running-request -o outputfile &
Här har jag ändå bara skrapat på ytan av vad som är möjligt med bash och shellscripts. Utöver detta finns det stöd för variabler, loopar, villkor, schemaläggning, aritmetik, kommandosubstitution, alias, listor, funktioner etc.
Rätt använt kan shellscript användas för att automatisera stora delar av ditt arbete för att spara tid och minska risken för misstag vid manuell hantering. Ett varningens ord dock: håll skripten korta och frångå inte de principer om god kod som du skulle applicera på andra, mer fulländade, programmeringsspråk. Det finns många fall där små vackra shellscript vuxit till enorma monstrositeter som skulle ha varit mycket lättare att underhålla om de skrivits i “riktiga” programmeringsspråk.
Regular Expressions (1968)
Äldst av alla tekniker och språk på min lista kommer regular expressions (ofta förkortat regexp eller regex, i plural regexes) eller på svenska ofta kallade reguljära uttryck. Med sina 48 år på nacken härstammar dem från datorernas begynnelse (nåja, ENIAC utannonserades 1946) men är kanske ändå den av listans tekniker som är mest livskraftig och svårast att ersätta. Samtidigt är dess användningsområde enkelt att beskriva. Föreställ er följande dokument:
Alice was beginning to get very tired of sitting by her sister on the bank,
and of having nothing to do: once or twice she had peeped into the book her
sister was reading, but it had no pictures or conversations in it,
“and what is the use of a book,” thought Alice, “without pictures or conversations?”
So she was considering in her own mind, (as well as she could, for the hot day made
her feel very sleepy and stupid,) whether the pleasure of making a daisy-chain would
be worth the trouble of getting up and picking the daisies, when suddenly a
white rabbit with pink eyes ran close by her.
Regexes ger oss verktyg för att hitta texter där vi inte ens är säkra på de exakta innehållet, med hjälp av wildcards:
prefix.*suffix
I ovanstående text hade vi kanske velat hitta alla ord som börjar på “dais”. För detta kan vi skriva en regex likt följande:
dais.*
Detta ger för vår text resultaten “daisy-chain” och “daisies”. I denna regex innebär punkten “matcha alla typer av tecken” och asterisken innebär “matcha föregående teckenklass noll eller flera gånger”. Vi kan även ersätta asterisken med + (matcha minst en gång) eller {2,3} där tvåan och trean bestämmer hur många av den föregående tecken-klassen som måste finnas för att en match ska hittas, i detta fall mellan 2 och 3 stycken. Dessutom finns den något udda operatorn ? som innebär att det föregående elementet matchar noll eller en gång.
Vidare kan punkten ersättas med en mängd olika teckenklasser, bland annat W (alfanumeriska tecken), w (icke-alfanumeriska tecken), d (numeriska tecken) eller [xyz] vilket enbart matchar bokstäverna x, y och z i godtycklig ordning.
Vi kan även gruppera mindre delar av den text som matchats med hjälp av så kallade “capture groups”. Exempelvis då vi har en lista på URL:er och enbart vill plocka ut protokolldelen. Vi vet med oss att protokollet måste vara i början av URL:en, brukar bestå enbart av en eller flera bokstäver samt följas av ett kolon och två snedstreck. Detta kan vi uttrycka med följande regex:
^(w+)://.*
Många programmeringsspråks implementationer av regexar returnerar i detta fall en lista av de delar av texten som matchats.
Även detta är endast ett litet urval av allt som ingår i reguljära uttryck, men förhoppningsvis har det visat på kraften i att behärska dessa. Syntaxen är inte lättläst och den inbyggda tendensen att försöka matcha så mycket av en sträng som möjligt kan leda till en del bekymmer. Detta kan oftast kompenseras genom att följa upp sina regexar med förklarande kommentarer.
Tidlösa – inte uträknade och föråldrade
Teknikerna jag demonstrerat ovan är än idag allestädes närvarande och att kalla dem föråldrade eller uträknade är att göra dem en otjänst. Tidlösa är ett mycket mer passande uttryck. Om det är några av dem som saknas i din verktygslåda så rekommenderar jag varmt att förkovra dig i dem.
