Legacy Systems

I dagens Computer Sweden (27/2-08) så finns det en debattartikel om just det som vi håller på och skriver vår C-uppsats om. Nämligen problemet med legacy systems, och hur allt som uppfattas som gammalt blir totalt bortglömt trots att livslängden på de flesta system är relativt långa, och trots att COBOL inte på långa vägar dött ut.

Jag minns något år sen, när efter ett programrådsmöte, så var det en studentrepresentat som klagade på kursen vi hade i programmeringsspråket C. Han menade, att det är ju inga företag som använder ett så gammalt språk längre. Bortglömt och utdött, i princip. Nä, för det är Java man ska lära sig. Det är Java alla företag använder. Skulle man sagt "nej, det är COBOL vi borde lära oss för att få jobb efter examen" så hade ju ingen av de andra ens vetat vad jag pratade om.

Vi är för trendmedvetna, och universiteten är inte långsamma på att haka efter i förhoppningen om att det ska dra fler studenter. Men dessa trender tar lång tid innan de får ett grepp om den del av branschen som faktiskt måste använda sig av alla nya tekniker och metoder. De vet nämligen, att allt som är trendigt kommer inte överleva. Det gamla och beprövade, är just nämligen det, beprövat.

Så för att återgå till C-uppsatsen, titeln har kommit att bli: Modernisering av förlegade system - Processer och tekniker för att hantera det oundvikliga.

Vi hoppas att lära oss några nyttiga lärdomar av detta arbete, för det är onekligen ett intressant ämne. Och varför inte lära sig en gnutta COBOL samtidigt, kanske man blir ännu mer attraktiv sen i arbetslivet.

Spring

Såg att IDG hade en rätt bra artikel om Javaramverket Spring.

Lustigt detdär med ramverk. Det är så svårt att förklara egentligen vad det är. Ett antal färdiga komponenter, jojo.. Skrev faktiskt ett stycke om Spring i en rapport om Java EE 5. Dethär är vad det stod:

Spring är ett ramverk för Javaapplikationer. Men det säger inte så mycket för de flesta. Ordet ramverk kan betyda många olika saker, och sen kan det vara svårt att skilja mellan plattform, arkitektur och ramverk. Något förenklat så kan man se ett ramverk som en samling mjukvarukomponenter som är färdigbyggda för att förenkla utveckling av en applikation från noll. Man kan med hjälp av ett ramverk slippa lägga ner tid och resurser på att utveckla lågnivåfunktionalitet och på så sätt slippa uppfinna hjulet om på nytt. Utvecklaren kan då istället koncentrera sig på själva problemet.

Det finns ett flertal ramverk, och det kan vara ibland svårt att se nyttan med att det finns så många som det finns. Men de har alla sina tillämpningsområden och speciella kvalitéer. Och eftersom Spring är populärt idag så måste det ha någonting att tillföra. Spring är tänkt som en ersättare till Java EEs EJB-modell och utvecklarna av Spring försöker inte att konkurrera ut något av de andra ramverken som redan existerar om de inte själva tycker att det har någonting nytt att komma med.

Utvecklarna till Spring anser att Java EE borde vara enklare att använda, och försöker därmed inte att försvåra utvecklandet av applikationer utan tvärtom, förenkla. Man försöker dessutom att ”tvinga” utvecklare till att skriva välskriven programkod.
Spring är väldigt modulärt uppbyggt, så man behöver inte använda ramverket till allting. Till exempel kan man välja att endast använda Spring för att förenkla JDBC funktionalitet. I Spring har man dessutom lagt ner mycket möda på designa ramverket på så vis att det ´blir enklare att testa applikationer.