Feed: Informator-Bloggen - AggScore: 69.3

SM i SQL Server startar idag

---

Sommarkollo! Köp 2 kurser, få den 3e för halva priset!!

---

Nu har du en unik möjlighet att klara av tre viktiga utbildningar plus en certifiering under sommarmånaderna 2012. Alla sommarkollots kurser kommer garanterat att gå av stapeln och det spelar ingen roll på vilken av våra tre orter du befinner dig.
Är familjen i stugan på västkusten i sommar? Inga problem, din kurs i Malmö finns på plats i Stockholm och i Göteborg. Läraren befinner sig då på vårt utbildningscentra i Malmö, men du behöver bara ta dig till Stockholm eller Göteborg. Du deltar via vår Tandberg Remote-lösning.

Här kan du se vilka kurser det gäller

Klatschiga Closures

---

Betraktar man programspråkens utveckling över en längre tidsperiod kan man se hur de evolverat genom att plocka upp "bra idéer" från andra språk.

På 60-talet utvecklades stack-baserad exekvering, vilket banade väg för lokal variabler och rekursiva funktion. 70-talet var modulariseringens tidevarv med grupperingar av funktioner i syntaktiska moduler. På 80-talet evolverade detta till egen-definierade datatyper, som sedan tog nästa steg över till objekt-orientering under 90-talet.

Det är inte alltid ett begrepp får sitt stora genombrott bara för att det är "uppfunnet". Klass-begreppet var en fundamental del av språket SIMULA, vilket skapades redan på 60-talet, med det var först på 90-talet begreppet klasser fick sitt stora genombrott och har bildat programmeringsnorm sedan dess.

Closure och Lambda

Ett annat annat begrepp som tagit god tid på sig att "mogna" är begreppet closure, som daterar sig långt tillbaka i tiden. Faktiskt tillbaka till programspråkens barndom, men då inom mer akademiskt orienterade programspråk såsom LISP. Ursprunget till LISP är funktions-manipulerings-systemet lambda-kalkyl. Orden closure och lambda används ibland som synonymer. Men det är först under det senaste decenniet som closures har fått sitt stora genombrott och utgör ett av de viktigaste moderna programkontruktionsbegreppen. Det är en viktigt del av alla nya programspråk och införs "löpande" i en hel del gamla språk med.

Vad är en Closure?

Så vad i all världen är det då? Kort och gott, är en closure en anonym funktion. En C-programmerare kanske skulle fnysa "funktions-pekare", men det är inte hela sanningen. Utmärkande för en closure är följande

• Funktions uttryck
• En parameter-lista
• Värde-bindningar till fria variabler (icke-parameter) i funktionsuttrycket

Här är ett exempel:

int c = 3
def f = {a, b -> a**2 + b**2 - c**2}
println 'Result = ' + f(2, 5)

Variabeln f refererar en closure, som har en parameter-lista med a och b och ett funktionsuttryck som summerar kvadraterna på a och b, samt subtraherar den kvadraten på den fria variabeln c. På den tredje raden anropas f med argumenten 2 och 3, varpå resultatet 2**2 + 5**2 - 3**2 = 20 skrivs ut.

Closuren f kan skickas iväg till en funktion eller stoppas in i en tabell och exekveras någon gång senare. För att detta ska fungera måste den spara värdet av c (värdebindning), eftersom c kanske bara var en lokal variabel och är sedan länge borta när f så småningom anropas.

Kod-exemplet ovan är skrivet i JVM språket Groovy, men det finns många andra språk som har closures också. För språket Java införs closures (project Lambda) nästa år, i version 8.

Samma program, olika språk

Så, låt oss kika på lite olika closure variationer, genom att studera hur ett visst problem kan realiseras i olika programspråk. Många gånger vill man mäta tiden för att exekvera en funktion eller grupp av funktioner. Det innebär att läsa av aktuellt klockvärde, exekvera mål-uttrycket, läsa av klocka igen samt beräkna klockdifferensen. Det blir typiskt repetitiv kod, där det som skiljer sig mellan gångerna är vad som ska mätas. Det man vill är att bryta ut denna del så att resten av koden (boiler-plate code) kan återanvändas.

Groovy

Genom att definiera en funktion, som tar en closure som argument kan detta åstadkommas. Så här det ut i Groovy. Som test-funktion mäter vi tiden för att beräkna Fibonacci-talet 40, implementerat på klassiskt ineffektivt vis med dubbel-rekursion.

Funktionen elapsed() tar en led-text plus en closure som argument. Förutom att anropa closuren (i try-blocket) och returnerna resultatet, så beräknas åtgången tid som skriv ut. Själva anropet till funktionen elapsed() görs på rad 17, där den closure som skickas med innehåller det som ska mätas, dvs anropet till fibonacci(). Här använder vi oss av den fria variabeln n.

Java

Vill vi göra något liknade i Java, som ju än så länge saknar closures, så är anropet av elapsed() inuti main() betydligt mer komplicerat. Här måste vi gå via en anonym klass som implementerar gränssnittet Stmts.
Kompilering och exekvering av Java-programmet ser ut så här.

C++

En av de stora nyheterna i språket C++, via nya standarden C++11, är closures. Dock kallas de för lambda. Så här kan kan samma problemställning se ut då.
Själva anropet av elapsed() på rad 13 utgörs av closure:n/lambda:n

[=](){ return fibonacci(n); }

Den första delen '[=]' anger att fria variabler (n) ska värde-anropas, den andra delen '()' är en tom parameter-lista samt den tredje och sista delen är själva funktions-uttrycket. Så här kompilerar och exekverar man C++ programmet. Jag kör med Cygwin och GCC version 4.5.3.

Erlang

Till sist, låt oss kika på hur det ser ut i språket Erlang, som jag ju skrev om tidigare i veckan. Dels, lite kod-exempel och dels om dess minst sagt guppiga historia. En closure i Erlang kallas kort och gott för anonym funktion, och anges med nyckelordet 'fun', vilket är kul.
En closure i Erlang definieras mellan nyckelorden 'fun' och 'end'. Efter 'fun' finns en i detta fall tom parameter-lista följt av en avskiljare '->'. Till höger om avskiljaren finns själva uttrycket, som även här använder sig av en fri variabel (N). Kompilering och exekvering av programmet görs med fördel inifrån 'werl'.

Källkod

Samtliga program-exempel finns i en ZIP-.fil här

• Informator-Bloggen_Closures_25-maj-2012.zip

Lite erlagd Erlang historia

---

Det inte ovanligt att bakgrunden till ett programmeringsspråk ibland rymmer en del motgångar. T.ex. språket Java uppstod som fågeln Fenix i askan efter Project Green, som bl.a. innehöll programspråket Oak. Det språket hade en för den tiden remarkabel egenskap, att kunna dynamiskt ladda in ny kod i ett exekverande system. Oak hade i sin tur inspirerats av ett annat system, som också hade blivit ett kommersiellt fiasko, nämligen det postscript-baserade fönstersystemet NeWS. Gemensamt för alla dessa var innovatören James Gosling. Under nedläggningsfesten i Colorado-bergen demonstrerade en utvecklare en webbläsare han utvecklat i Oak, som kunde ladda ned små Oak-fragment och animera saker-o-ting på webbsidan. Detta var 1994 och alla förstod att man skymtat framtiden. Resten är vad som kallas historia.

Men frågan är om inte Erlangs berg-o-dal-bane historia tar priset. Under slutet av 80-talet och början på 90-talet arbetade Joe Armstrong på Ericssons Datalogi labb i Älvsjö (söder om Stockholm) med utveckling av språket Erlang.

Den akademiska perioden

Till att börja med var detta ren forskning, men med inriktningen att identifiera ett lämpligt programspråk för nästa generations tele-växlar. Man byggde samma system i en rad olika programspråk, såsom Ada, Concurrent Pascal m.fl, utan att något av dem höll måttet. Dock blev Joe (och hans kolleger) intresserade av Prolog och mer specifikt Concurrent Prolog och dessa kusin Parlog. Både inspirerade av CSP, som var högsta akademiska mode just då. Detta ledde fram till ett samarbete mellan Ericsson, KTH-TDS och SICS, där man experimenterade fram ett nytt programspråk inom ramen för Prolog (meta-interpretator).

Med tiden så utkristalliserades ett programspråk som bar syntaxen av Prolog, men som exkverade mer som LISP och hade egenskaper hämtade från Actors-modellen. Man tyckte det var klart fyndigt att namnge språket som en hyllning till Agner Krarup Erlang, en matematiker som lade grunden för modern trafik-teori som används inom telecom-ssytem och att det samtidigt kunde uttydas som ERicsson LANGuage.

Under första halvan av 90-talet utvecklades språket och kapade banden till Prolog, med både egen virtuell maskin (JAM och senare BEAM) och kompilator skriven i språket själv (som sig bör). Det här var den akademiska perioden i Erlangs leverne.

Jag var vid denna tid adjunkt på KTH i Stockholm, och hade förmånen att umgås i samma forskarkretsar som Erlang-gänget. Vid denna tid var själv jag "fanatisk" C++ programmerare och ansåg att överlagring av komma-operator var nästan det bästa sedan skivat bröd :-) De gånger jag träffade Joe grälade vi mest om objekt-orienteringens förträfflighet eller fasa. Trots olika åsikter var jag ändå road av språket Erlang och när jag förde in språket i min undervisning om tråd-programmering på KTH 1991/1992, var det första gången som Erlang förekom i den vanliga akademiska undervisningen.

Erlang the Movie

Erlang hade egenskaper såsom fel-tolerans och möjlighet att dynamiskt ladda om kod i ett exekverande system. Detta demonstrerades förtjänstfullt av den video som spelades in, kallat Erlang the Movie. Missa inte detta tidsdokument.

Filmen inleds av Bjarne Däcker (chef för DL-Lab), följt av Joe Armstrong och Mike Williams (team lead) som introducerar språket. I filmen görs telefonsamtal över en fysisk tele-växel (MD-110), som hanteras av Erlang. Program-exekveringen förklaras av Robert Virding framför en SUN-3 workstation.

För min undervisning på KTH, hade vi fått låna en portabel MD-110 av Bjarne och eleverna hade som en av sina labbuppgifter uppgiften att programmera ett litet tele-system i Erlang. Först körde de i en grafisk simulator, jag utvecklat. När deras program fungerade, bokade de tid för att köra på den riktiga hårdvaran. Gissa om det var uppskattat att se sin kod fungera "live".

AXE-N Projektet

Utanför det labb Joe arbetade i, pågick något helt annat i resten av Ericsson (Telecom). Man arbetade med nästa generation av AXE växlar, kallat AXE-N. Önskan var att upprepa bedriften från 70-talet, när AXE-10 hade sopat mattan med konkurrenterna och lade grunden det världsomspännande företag som vi känner det idag. I detta mycket ambitiösa projekt fanns det två grundpelare, vad programutveckling beträffar, C++ och objekt-orienterad design. Emellertid, av outgrundliga skäl, saknades den tredje grundpelaren nämligen concurrent and real-time systems programming, eller rätt-o-slätt trådprogrammering.

Under denna tid ville man överhuvudtaget inte höra talas om Erlang. Man kan lugnt säga att Erlang-gänget var mobbade internt inom Ericsson, men mycket respekterade överallt annars.

Trots stora ambitioner och mycket satsade pengar, körde AXE-N projektet rätt in i bergväggen. Man kunde börja ana vartåt det lutade redan 1993, men det var först under 1994 som det stod klart för flertalet att AXE-N inte skulle lyfta. När väl slutet tillkännagavs, utsågs också en "syndabock". Det blev språket C++, som också bannlystes. Självfallet var det inte C++, som var grundproblemet men det var bekvämt att kunna skylla på något enkelt. Detta lade också grunden för en fördom/misstänksamhet mot C++, som fortfarande än i våra dagar florerar här-och-där inom Ericsson.

Guld-åren

AXE-N kraschen kom däremot att betyda jackpott för Erlang-gänget, eftersom språket nu plötsligt utsågs till att vara det stora framtidslöftet. Under åren 1995-1998, så var detta Erlangs guld-år. Både pengar och mycket folk styrdes om till att vidareutveckla Erlang. Det var bl.a. under denna tid som applikations-biblioteket OTP utvecklades.

Katastrof-året

Men, säg den lycka som varar för evigt. Katastrof-året 1998 inleddes med en rad internationella framgångar. Erlang-gruppen demonstrerade ett GPRS system vid GSM World Congress och CeBIT konferenserna och framtiden såg gnistrande ljus ut. Trodde man.

I lönndom hade en annan fraktion på Ericsson lyckats övertala ledningen att några egen-utvecklade "konstiga" språk, skulle man inte hålla på med. Framtiden skulle stavas Java i stället och programspråks-utveckling skulle skötas av aktörer utanför Ericsson.

Med omedelbar verkan så bannlystes språket Erlang inom Ericsson, våren 1998. Alla resurser, som pengar och folk, drogs bort och pågående Erlang-baserade projekt fick order om att implementeras om i något annat programspråk. Det säger sig självt att det inte går att oförhappandes skriva om all programkod och ändå hålla projektens tidsramar. Vissa fiffiga projekt-ledare kom på idén att replikera med att "vi håller inte på med Erlang, vi håller på med OTP". På så sätt kunde man köra vidare under radarn ett tag till. Så kom det sig att än i våra dagar kallas Erlang för OTP. Om du går till Erlangs nedladdningssida, så kan du se namngivningen som OTP Release 15.

En plan tar form

Givetvis var Erlang-teamet, med Joe i spetsen, förkrossade. Det stod helt klart att det inte fanns någon framtid för dem inom Ericsson. Då föddes tanken på en exit-strategi.

Joe lyckades övertala ledning att släppa språket fritt som open-source, eftersom företaget inte själva ville använda det. Sagt och gjort, efter den sedvanliga byråkratiska tiraden förklarades Erlang som open-source den 2  december 1998.

8 dagar senare, den 10 december 1998, slutade hela "kärn"-gänget kring Erlang. I hemlighet hade man skapat ett dot-com bolag med risk-kapital och hela baletten. Det nya företaget hette Blue-tail och blev mycket omskriven för sin spektakulära, fel-toleranta och skalbara mail-server skriven i Erlang.

Blue-tail gick upp i det blå

Strax efter millennieskiftet förvärvades bolaget av Alteon Web Systems och man "cash:ade in". Bara några dagar senare förvärvades Alteon av Nortel Networks. Nortel var vid denna tid Ericssons argaste konkurrent. Tja, så kan det gå.

Emellertid, så slog telecom-krisen till och alla aktörer drabbades hårt. Vem minns inte dåvarande Ericsson-chefens svar på en fråga från en reporter:  "Är det ljuset i tunneln nu?" och svaret "Nä, snarare ett tåg". Nortel drabbades hårdast och gick i konkurs, varpå det tidigare Erlang-teamet splittrades för vinden.

Erlang - Borta med vinden

Efter telecom-kraschen var Erlang i praktiken dött. Det levde vidare dock i en del system som fanns i produktion och givetvis i sinnet hos de forna hjältarna.

Erlang - Återkomsten

Med idogt folkbildnings-arbete på otaliga internationella konferenser och med lyckosam kombination av Internets framväxt och åtföljande krav på skalbarhet, så återhämtade sig Erlang under andra hälften av 00-talet. Många företag hade börjat leta efter ett språk som bättre kunde hantera ett mycket stort antal samtidiga operationer och kommunikations-konversationer. Erlang var svaret på många böner.

När sen självaste Facebook tillkännagav 2007 att deras nya chat-system var utvecklat i Erlang, blev intresset glödhett. Amazon utvecklade en NoSQL databas för sitt moln AWS, kallat SimpleDB. Damien Katz utecklade en egen NoSQL database kallat CouchDB. Här på hemmaplan grundlades företaget Kreditor (numera Klarna) av tre Handels-studenter och med hjälp av KTH-kompisar implementerades hela deras system i Erlang. Även aktie-mäklaren NordNet utvecklade vissa del-system i Erlang.

Erlang vs. Java - Hur det kunde ha varit

Under 90-talet utvecklades två programspråk, vilka har fler likheter än skillnader. Java av James Gosling och Erlang av Joe Armstrong. Båda språken exekveras med en virtuell maskin, JVM respektive BEAM (Bogdan's Erlang Abstract Machine, efter Bogumil Hausman som först skapade Turbo Erlang). Båda språken var ursprungligtvis tänkta för inbyggda system, telecom för Erlang och konsument-elektronik för Oak (Java's föregångare). Båda hade stöd för att dynamiskt ladda in kod i ett exekverande program. Båda hade stöd för feltolerans. Båda hade ett stort standard-bibliotek. Båda hade direkt stöd för såväl tråd-programmering som TCP kommunikations-programmering.

Men det fanns en avgörande skillnad i hur deras omgivning behandlade dem. Java, kan man säga, var ett älskat barn, medan Erlang var det oönskade och förskjutna barnet. Tänk, rent hypotetiskt, om Ericsson hade varit lika generösa med stöd och support för Erlang, som SUN Microsystem var för Java. Ja, då hade vi alla programmerat i Erlang i stället och implementerar webbsystem i E2EE.

Länkar

• Informator-kursen: Erlang Basics
• Erlang historia av mig
• Erlang historia av Joe
• Erlang historia av Bjarne

NU KÖR VI! 50% på hela 75 kurser!

---

Kasta dig på telefonen och boka utbildning till halva priset! Endast idag onsdag 23 maj 9.30 - 11.30!

Hur kapar jag en utbildning?
TELEFONBOKNING Ring Informators pirater så snabbt du kan!
Stockholm: 08-587 116 10
Göteborg 031-773 07 90
Malmö 040-66 22 060

ERicsson LANGuage

---

Om du idag googlar runt på (programmeringsspråket) Erlang, så upptäcker du snabbt att det är ett av de mest hetaste (på svengelska coolaste) språken och att det finns en hel del andra som gärna drar nytta på att förknippas med Erlang teknologi. Så vad motiverar det stora intresset? Kort sagt; molnet! Lite längre sagt, så menas egenskapen att hantera ett mycket, mycket stort antal samtidiga konversationer/transaktioner/operationer.

Ett av de riktigt svåra problem med fler-trådad (multi-threaded) programmering är att hantera uppdateringar av gemensamma data, eller mer precist uttryckt Shared Mutual State. Det klassiska sättet är att omge operationerna med mutex-lås (MUTual EXclusion), så att högst en tråd kan accessa data i taget. Detta är i regel ett nödvändigt men icke tillräckligt krav för att hantera mer komplexa interaktioner. Dessutom behövs villkorsvariabler (condition variables), som modellerar ett önskat sub-system tillstånd. T.ex. "vänta här brevlådan är tom". Det finns tre villkor för att problem med gemensamt data ska uppstå:

1. En icke-atomär sekvens av READ, MODIFY, WRITE på ett data-element.
2. Mer än 1 tråd som accessar datat.
3. Tråd-växling inuti kod-sekvensen.

Erlang gör rent hus med detta, genom att det inte är möjligt att skapa globala data. I stället kapslar man in data i en Erlang tråd (aka Erlang process) och sen får nyttjare skicka asynkrona meddelanden till tråden i fråga, som sedan behandlar meddelanden ett-i-taget. Det här är kärnan i den s.k. Actors-modellen, som på senare tid har blivit kolossalt populär i språk som Groovy-GPars och Scala-Akka.

En Erlang process, är ett slags mellanting mellan objekt och tråd. Objekt såtillvida att dess tillstånd är inkapslat och tråd såtillvida att den exekverar samtidigt med andra. Ett Erlang program kan sägas bestå av en soppa av Erlang processer som simmar omkring och kastar asynkrona meddelanden på varandra. Mellan processerna, finns ingenting.

Utmärkande för Erlang är också single-assignment property. Detta innebär att en variabel är antingen obunden eller bunden (för tid-och-evighet) till ett visst värde. M.a.o. bryter vi mot villkor 1ovan. En konsekvens är att man inte kan ha traditionella (for-) loopar, med en loop-variabel som stegas igenom. I stället används genomgående rekursion som upprepnings-mekanism i språket. Här förutsätter det att kompilatorn gör s.k. svans-rekursions-optimering (tail-recursion optimization).

Nå, låt oss kika på lite programkod. Så här kan vi representera ett enkelt bank-konto, som en Erlang tråd.

account_new() ->
  spawn(?MODULE, account_body, [0]).

account_body(Balance) ->
  receive
    {balance, Amount, Sender} ->
      BalanceNew = Balance + Amount,
      Sender ! BalanceNew,
      account_body(BalanceNew);
    stop -> ok
  end.

Function account_new() -kontruktor- skapar en ny tråd mha den inbyggda funktionen spawn(). Själva tråd-kroppen loopar via rekursion och innehåller trådens inkapslade tillstånd (state) som parameter. Tråden ligger och väntar på ett inkommande meddelande och uppdaterar sedan saldot, samt skickar detta tillbaka till sändare. Här kan man se Erlangs typiska send-operator '!', hämtad från CSP. För att läsa och ändra saldo har jag lagt till följande funktion, som skickar ett meddelande och sen väntar på ett svar (extended rendezvous).

account_balance(Account, Amount) ->
  Account ! {balance, Amount, self()},
  receive
    BalanceNew -> BalanceNew
  end.

En uppdateringstråd loppar ett visst antal gånger och sätter in 100, samt loopar lika många gånger och tar ut 100. Netto-resultat är alltså 0, vilket är förväntat resultat av programmet. Så här ser uppdateraren ut.

updater_new(Id, Account, NumTransactions, Bank) ->
  spawn(?MODULE, updater_body, [Id, Account, NumTransactions, Bank]).
 
updater_body(Id, Account, NumTransactions, Bank) ->
  repeat(NumTransactions, fun() -> account_balance(Account, +100) end),
  repeat(NumTransactions, fun() -> account_balance(Account, -100) end),
  Bank ! Id.

repeat(N, _) when N = ok;
repeat(N, Stmt) when N > 0 -> 
  Stmt(),
  repeat(N-1, Stmt).

Konstruktorn skapar en ny tråd och skickar med info om id till kontot och antal transaktioner att utföra. Tråd-kroppen loopar mha funktion repeat() som tar ett heltal plus en closure, i vilken kontot uppdateras.
Huvudprogrammet skapar först kontot och sen önskat antal uppdaterare. Sen ligger det och väntar på att dessa är klar, samt hämtar slutsaldot och avslutar kontot.

start() -> 
  start(10, 1000).
start(NumUpdaters, NumTransactions) ->
  Account = account_new(),
  [updater_new(Id, Account, NumTransactions, self()) || Id <- lists:seq(1,NumUpdaters)],
  repeat(NumUpdaters, fun() -> 
    receive 
      Id when is_integer(Id) -> ok
    end 
  end),
  FinalBalance = account_balance(Account, 0),
  Account ! stop,
  {final_balance, FinalBalance}.

Uppdaterarna skapas med en liten finess som kallas list-comprehension och kan väl lite (mycket) slarvigt sägas vara en for-loop. Till höger om '||' finns en lista med talen [1,2,..,N] och en lopp-variabel (Id). Denna används till vänster om avdelaren i ett list-element-konstruktions-uttryck (oj, långt sammansatt ord), som skapar en ny uppdaterar-tråd. Sen väntar vi på att alla uppdaterare har terminerat. Efter det hämtas saldot och vi är klara. Så här kan en körning se ut.
Här kan du se att jag först kompilerar programmet (bank.erl) och sen kör det med 100 uppdaterare och 100.000 transaktioner. Programkoden i sin helhet har jag lagt upp här:

• bank.erl

Verkar Erlang intressant? Kolla då in kursen:

• Erlang Basics

50 % på massa kurser!

---

Informator-piraterna är tillbaka! Imorgon 9.30 - 11.30 kapar de priserna på mitten på hela 75 kurser. Du som läser vår blogg kan redan idag gå in och tjuvkika på utbudet.
Här hittar du alla kurser erbjudandet gäller:

Det här kan DU skapa efter att ha gått Wordpress-kurs hos oss!

---

Efter att ha gått vår kurs i Wordpress kan du bygga en sida liknande denna själv;

• Introduktion till PHP och CMS
• Installera WAMP-server
• Wordpress "Interface"
• Skapa sidor och länkar
• Inlägg och "blogg"-funktioner
• Plugins och fomulär
• Sökmotor optimering
• Widgets och Menyer i Wordpress
• Templates
• Koppla Dreamweaver till Wordpress
• Redigera utseende i Wordpress med Dreamweaver
• Video och Flash i Wordpress
• m.m.

I samarbete med Black Eye Media

Läs Boostkod!

---

Boost-biblioteket är allt man behöver för att nå absolut nördnivå. Varje engagerad C++-utvecklare bör hålla koll på www.boost.org och livets högsta mål är att ha en eller flera egna klasser upptagna i det biblioteket och att ha fått ett idiom uppkallat efter sig. Det motsvarar katolska kyrkans helgonförklaring.

Det speciella med Boost är att biblioteket utvecklas enligt den akademiska traditionen med peer reviewing. Många andra öppna bibliotek och sajter med kod från kreti och pleti kan visst ofta vara användbara, men koden i Boost har alltså stötts och blötts av all världens gnälligaste sakkunniga innan den officiellt får ingå i biblioteket. Det ger en helt annan kvalitetsnivå.

Dessa sakkunniga är dessutom inte vilka gnällspikar som helst, utan i stor utsträckning samma personer som deltar i standardiseringsarbetet för språket C++. Släktskapet mellan Boost och språkstandarden är alltså starkt och syns direkt i att en stor del av den nya klasserna i nya språkstandarden C++11 är tagna direkt från Boost.

Boost är dessutom mycket fritt att använda. Till skillnad från GNU-licensen behöver man inte göra sin egen kod öppen, det går bra för vem som helst att använda Boost-koden i egna applikationer med vissa smärre krav. Men mitt skäl för att dra fram Boost i detta sammanhang är ett annat, dess pedagogiska värde:

Var och en som jobbar med C++ har antingen passerat eller inte passerat den tröskel det innebär att förstå att C++ har två stora grenar när det gäller hur språket används i objektorienterad design. Den ena är den numera helt dominerande i alla sammanhang, nämligen arv plus dynamisk bindning plus abstrakta basklasser och interface. Sedan tjugo år är det gällande statsreligion inom alla stora språk och lärs ut på all högskolenivå. Känns igen från Java, .Net/C# m.fl.

Den andra är policyobjekt plus typparameterisering och, när det gäller samlingar, iteratorer. Det är det speciella med C++ på högre nivå (dit vi når ungefär mitt i kursen Avancerad C++, dvs i dag). Vanligen kombinerar man inte de två designtraditionerna i samma bibliotek. STL-biblioteket med ursprung hos HP ingår i denna tradition - och ingår i språkstandarden sedan tidigare. Många tycker det är krångligt och underligt. Boost är alltså också ett bibliotek i denna tradition. När man börjar fatta skönheten i STL går man vidare till att studera Boost och når nördnivå.

Dessutom kan det tänkas att man hittar klasser som man genast kan använda. Ifall man kanske måste producera lite till vardags också.

MFC alive and almost kicking

---

Kurser om Microsoft Foundation Classes (MFC) är det inte många som frågar efter numera. Det var Microsofts stora klassbibliotek i C++ på 90-talet. Föregångaren till .Net-biblioteket. Första versionen avsedd för Windows 3. Man kan gissa att hela Officepaketet utvecklades i MFC, och i ATL - det andra stora klassbiblioteket fast med inriktning på utveckling av COM-komponenter. MFC är främst ett bibliotek för fönsterprogrammering. Visual Studio har fullt stöd för MFC-utveckling och klassbiblioteket befinner sig i version 10 med vidareutveckling i VS2012.

Därför var det kul när det oväntat dök upp inte mindre än fyra livs levande kursdeltagare för några veckor sedan som ville ha en T323 - MFC-kursen. Det var min huvudsysselsättning under 90-talet. Jag skrev applikationer för redaktionell produktion, främst för dagstidningar, i MFC och höll fram till .Net-genomslaget 2002-2003 MFC-kurserna. Jag skrev i själva verket det mesta av kurspärmen. Men nu hade jag inte hållit den på åtskilliga år och var glad att jag alls hade kurspärmen kvar. Jag tror inte någon kurs med det innehållet körts i detta land alls på de senaste åren.

Efter 2002 blev det både för mig och resten av windowsvärlden mest .Net och C#, men MFC-kurserna klingade av ganska långsamt eftersom åtskilliga organisationer lagt stora resurser i egna MFC-applikationer som inte lät sig porteras i en handvändning.

MFC-kursen var under de första åren på 2000-talet mycket tacksam att hålla. Den typiske deltagaren kom ganska färsk från universitetet och hade använt Java eller .Net, möjligen med en liten C++-kurs och därefter kastats in i MFC-kod. Det är inte kul.

Många vittnade om att de efter veckors möda och självstudier kommit fram till att de var sällsynt dumma i huvudet som inte kunde begripa hur det var tänkt. Då kunde jag trösta och meddela att det är helt normalt. MFC har den särskilda egenskapen att vara obegripligt. Ett särskilt skäl till det är att biblioteket utvecklades till stor del innan språket C++ ens var standardiserat - vilket som alla vet skedde först 1998.

Nu var det alltså läge att läsa på lite i den kurspärm jag själv skrivit. Det är oerhört irriterande att inte komma ihåg och inte omedelbart begripa det man själv skrivit. Man blir mycket missnöjd med sin hjärna. "Jag har fotografiskt minne men lite trubbel med framkallningen" kan man säga.

Men det var också fascinerande att efter tio år med .Net åter tvingas in i MFC. Det fascinerande är att se hur utvecklingen ofta går med stormsteg - fram och tillbaka.

I MFC är ett dokument i en windowsapplikation tre objekt: ett ramfönster, ett vyfönster, visuellt inuti ramfönstret, och ett dokumentobjekt. Det kallas document-view-architecture De tre objekten skapas av en objektfabrik kallad document template och kopplas samman. Därmed kan man ganska lätt bygga ut arkitekturen så att man har flera dokumentklasser som hanterar data på olika sätt, man kan koppla flera vyobjekt som visar samma dataobjekt på olika sätt, göra splitviews etc. Det är en listig och framsynt design, en variant av det sedermera klassiska designmönstret model-view-controller med rötter i GOF-mönstret Observer.

I .Net kom Windows Forms. Ett fönsterobjekt är ett fönster och man kan både rita i det och möblera det med kontroller. Kontrollerna genererar events (finns inte i MFC) som hanteras i fönsterklassen. Datat som ska visas läggs direkt i fönsterobjektet. Inte tillstymmelse till model-view-controller. För web kom ASP.Net Web Forms där formulärklassen både genererar HTML, hanterar events och innehåller datat. Inget model-view-controller.

Sedan kom nya modeflugan MVC, model-view-controller...

Ett exempel till: I Windows3-applikationer (ja jag vet, det är längesedan) gjorde man med MFC INI-filer. Textfiler med sparade inställningar enligt ett textformat som lätt kunde editeras manuellt. I Windows 95 blev det bannlyst. Inställningar ska sparas i registryt och inte editeras manuellt. MFC införde klasser för ändamålet.

Numera sparar vi inställningar i XML-filer. Textfiler enligt ett standardformat, som lätt kan editeras manuellt...

Okänd Informatorhistorik

---

Mats och Katarina hette Informators grundare och det var år 1990. 1996 höll jag min första kurs åt dem - Grundkursen i C-programmering. Är jag därmed möjligen den slitstarkaste kursledaren hittills? (Det går att kommentera nedan.)

Kurserna hölls då huvudsakligen i hotell Morningtons konferenslokaler på Nybrogatan, i källaren. En enda tekniker skötte all prep av salarna, och all annan teknik, och hade ett förrådsrum i samma källare, fullt av datorer. Låt oss kalla honom J. Möjligen fanns det någon lägenhet någonstans i de yttre förorterna men J bodde framförallt på en luftmadrass i sitt förråd. Eftersom han hade jobb dygnet runt och dessutom var intresserad av att dricka whisky (det är jag också) så var det mera praktiskt med luftmadrassen, några steg från baren.

Kurslokaler, hotellrum för lärare, bar, restaurang och ett levande whiskyintresse fanns därmed under samma tak och det var en trevlig kombination. Man behövde strängt taget aldrig lämna hotellet. Alla lärare och en och annan kursdeltagare blev oftast kvar åtminstone en stund efter kursdagarna. När man slutligen gick ut på fredagseftermiddagen slog dagsljuset emot en som en fotoblixt.

J slutade någon gång i slutet av 90-talet och anställdes på FRA. Det hindrade inte att han dök upp i baren på Mornington då och då för att prova någon liten whisky. Vi andra var då förstås nyfikna på om han kunde berätta hemligheter från FRA.

Man ska minnas att den nu helt dominerande lösningen på krypteringsproblemet - asynkrona nycklar och RSA-kryptering blev dominerande i den vevan. Det är fascinerande att själva den geniala idén att ha två nycklar, private och public, kläcktes först i slutet av 1970-talet och patenterades först 1983. Den sortens geniala idéer är annars ofta hundratals eller tusentals år gamla. Engelska säkerhetstjänsten lär ha haft idén långt tidigare, men där var allting så superhemligt att den aldrig kom till användning.

Under hela andra världskriget använde man synkron nyckel, dvs samma nyckel för kryptering och dekryptering, vilket ju skapar ett oerhört problem med distributionen av nycklar. Då kunde FRA framgångsrikt dekryptera den radio- och telegramtrafik de snappade upp. Kanske kom de ibland också över skarpa nycklar. Så var det fram till 1990-talet.

Vi undrade alltså hur det nu går för stackars FRA att dekryptera RSA med 128-bitars asynkrona nycklar. Går det bra? Är regeringen nöjd? Får ni fortsatta anslag? J teg som en mussla. Låt oss bjuda på en whisky! Det lossar tungans band.

Vi insåg förstås att han skulle drabbas av gruvliga straff om han bröt mot sekretessen. Men vilket kunde då detta gruvliga straff vara? J teg som en mussla också om det.

Så fick han en och annan gratis whisky.

Nästa veckas gästbloggare: Anders Forsberg, expert på C++

---

ITIL – varför heter det så?

---

Helkväll i .NET med Dino Esposito

---

Missa inte en helkväll i .NET arrangerad av Swenug  och sponsrat av Informator.
Föredragshållare är Dino Esposito och ämnet för kvällen är "Stop Giving Others a Hard Time Reading your Code". 
Datum: 7 maj
Tid: 18-21
Plats: Informator, Karlavägen 108, Stockholm

Läs mer om innehållet och anmäl dig här

SharePoint 2010 för Utvecklaren: Att tänka på performance!

---

Introduktion

Att tänka på performance och skalbarhet är otroligt viktigt i de flesta projekt idag, inte minst när vi pratar om projekt som levereras på SharePoint-plattformen. I det här inlägget tipsar jag lite om vad man som utvecklare bör tänka på när man tar fram lösningar baserat på SharePoint 2010.

Några nyckelord att luta sig mot

Developer Dashboard

För att få en liten koll på hur din SharePoint-lösning mår, både i form av effektivitet och hur mycket systemresurser den kommer att sluka så finns det I SharePoint 2010 ett utmärkt verktyg som heter Developer Dashboard som kommer väl till hands. Är du utvecklare och behöver säkerställa att din lösning inte tar för många resurser eller om den orsakar långa fördröjningar i din portal så är det ett utmärkt tillfälle att slå igång Dev Dashboard.
Läs mer här om Developer Dashboard och hur du kommer igång!

SPMonitoredScope

Om du har följt det första tipset om Developer Dashboard, så bör du fortsätta och kika på SPMonitoredScope som är ett bra alternativ om man vill övervaka anrop som sker I koden och kunna mäta hur lång tid de tar på sig att exekvera. Det här är ett perfekt hjälpmedel som utvecklare för att kunna få en indikation på om vi bör förbättra någonting innan deployment till produktion.
Läs mer här om SPMonitoredScope!

Logga till ULS

Ett av mina nyckeltips när jag utbildar folk I SharePoint 2010 är att alltid logga till ULS! Om vi skickar upp information om vår lösning till ULS loggen, inte minst när vi får felmeddelanden, så ökar vi chanserna för administratörer att kunna hitta vad som gått fel även i produktionsmiljöer. För SharePoint specialister finns det ganska bra verktyg både för att läsa loggarna och för att skriva till loggarna.
Läs mer här om hur Logging funkar i SharePoint 2010!

Disposal patterns

Ni har hört det förr, och ni får höra det igen. Glöm inte att göra Dispose på era objekt!. Många undrar varför man måste göra en Dispose manuellt på t.ex. SPWeb och SPSite objekten i SharePoints API - ett av svaren är att de objekten lutar sig mot en del unmanaged code som alltså ligger utanför .NET motorn - detta innebär att vår kompis Garbage Collectorn inte förstår vad den ska göra med objekten, och således inte gör en automatisk dispose. Det finns så klart många tricks till hur man kan lösa de "problem" som uppstår med detta.
Läs mer här om hur du börjar tänka i rätt banor gällande Disposing i SharePoint!

Fundera över att använda CSS sprites för att minska datamängden mellan klient och server

En alltför sällan benyttjad funktionalitet i många webb-projekt idag är så kallade CSS sprites. Vad det här innebär är att med CSS sprites så lägger man ihop många bildfiler till en enda fil och använder CSS för att tala om för vår markup vilken del av bilden den ska visa när man gör en request. Fördelen med den här approachen är så klart att istället för att ladda ner 200 olika bildfiler för din applikation så laddar man bara ner 1 bild, och därtill så klart CSS-filerna som behövs. Detta medför ofta en snabbare överföring mellan server och klient och kan på ett trevligt sätt skapa en aningen snabbare svarstid.
Läs mer om CSS sprites här!

Minifierade script-filer gör också load-times snabbare

Ibland undrar man varför vissa jQuery eller JavaScript filer ser så svårlästa ut - t.ex. när man öppnar en .js fil och hela scriptet ligger på en enda lång rad. Anledningen till det här kallas minifiering av script, det vill säga möjligheten att ta bort onödika mellanslag, line breaks etc. Detta medför att filen blir aningen mindre och att överföringen mellan klient och server blir snabbare även här. Detta används flititigt i SharePoint 2010, och bör absolut övervägas i dina projekt.
Läs mer här om hur du kan minifiera dina script!

Tänk på hur stor din viewstate blir!

Ett vanligt förekommande problem på en del webbsiter är att utvecklare sällan reflekterar över hur stor ViewState blir. Ett tips är så klart: Tänk på hur ni gör med er ViewState.
Läs mer här om ViewState och SharePoint 2010!

Summering

Att tänka på performance är så klart väldigt viktigt I alla projekt, men tänk på att det måste finnas en balans mellan affärsnytta och performance också - man kan skruva på SharePoint väldigt länge och på väldigt många sätt för att få ut bättre prestanda ur sin farm, men ibland är det läge att överväga om vi låter tekniken ta över affärsvärdet. Ofta har det hänt att man blir efterklok och börjar skruva på prestandan efter man produktionssatt en lösning, men det bästa är att ha allt detta i åtanke redan innan projektet sjösätts. Men vi vet väl alla att det är ganska enkelt att vara efterklok.

Happy Coding :-)