Apropå JavaForum ämnet ”Våga vägra XML”
- tor 22 maj, 2008 kl 11:06
- 5 kommentarer
- Java
Rikard Thulin (IBS JavaSolutions) har tagit upp ämnet på Javaforum-mötet i Göteborg (2008-05-21). Mycket roligt och bra sammanfattning av en del problem kring olika ramverk och teknologier där XML filer används. Visst skulle allt blir enklare om man kunde slippa allt onödigt och krångligt. Tyvärr fanns det inte mycket tid för diskussioner kring dessa frågor trots att jag tycker att dessa frågor är väldigt centrala för kommande åren inom mjukvaruutveckling särskild bland java utvecklarna. Samtidigt som Rickard tog upp dessa frågor, hörde vi andra talare hur bra det är att använda andra ramverk och språk (typ Scala, Grails, Groovy). Att det finns just nu så många olika ramverk och språk intygar att vi försöker lösa ett antal problem utan att komma något vart (värd att läsa inlägget från Ola Berg om EJB). Enligt min åsikt, vi försöker att hitta generella lösningar för diverse problem. Iden är bra men att verkställa det verkar vara omöjligt.
Poängen i det hela är att vi måste utgå från krav tillsammans med ”ekonomiska och tekniska/arkitekturella aspekter”. Utifrån system/funktion krav tar vi fram ett ösningsförslag, där arkitekturella aspekter (såsom anträffbarhet, flexibilitet, användarvänlighet, förvaltning och underhåll, skalbarhet, säkerhet med flera) tillsammans med övriga ekonomiska aspekter (budget, time to market med mera) skall listas ner och prioriteras. Dvs. det räcker inte enbart med en lista av aspekter, utan dessa skall prioritera. Det är just denna prioritering som kan förhoppningsvis stödja oss med valet av ramverk/teknologi med mera. Att använda mer eller mindre XML, annotation eller kod-rader (en av motiveringar varför man skall använda dessa TYPADE språk som Scala) är i sig en aspekt men man skall överväga det mot andra aspekter. Jämför EJB3.0 och EJB2.0, där viktiga aspekter i själva ramverket är framför allt ”enkelhet och utvecklarvänlighet”, dvs. mer annotation men mindre XML fast man kan fortfarande använda XML om man vill. Eller Struts2.0 vs. Struts 1.x. I exempelvis Spring, prioriterar man upp aspekten Dependency Injection (för att avlägsna – De-Couple – objekt från varandra), där användning av XML tycks inte vara krångligt för utvecklarna (fast man kan göra en del ”auto” bindningar med mera som kan vara bra för attskriva mindre antal rader i XML filer).
Mjukvaruutveckling är som en konst, där olika konstnärer (utvecklarna) försöker måla så bra som möjligt en och samma motiv (applikation, ramverk), fast på olika sätt (olika verktyg). Som vanligt väljer/beställer åskådare (kunden) den tavla/konst (applikation, ramverk) som uppfyller hans/hennes smak (viktiga aspekter) och plånbok!
Sammanfattningsvis tycker jag att det känns helt ok att finns olika alternativ/ramverk som tillåter utveckling av olika system med olika aspekter/krav. Annars vore hemskt!
Jag tyckte Rikard gjorde en utmärkt presentation. Jag delar hans idéer. Kanske vore en presentation om domain specific languages nåt för nästa forum?
Jag tycker inte att man skall generalisera och att säga att XML tex är dåligt för användaren utan att mer anpassa gränsnittet baserat på kompetensen hos användaren. För en programmerare så funkar kanske XML bättre i vissa fall och men för en ekonom så behövs det ett grafiskt gränssnitt.
Om man tar EJB2 fallet så tycker jag att det går bra mycket fortare att jobba med XML’n än dom grafiska gränssnitten som kommer med dom olika applikations servrarna. Vissa saker blir inte bättre med en massa grafik.. om det vpre så, så hade vi ju kanske suttit och programerat i ett grafiskt programerings språk och dragit pilar mellan boxar för att representera interraktioner men det har ju aldrig slagit igenom ordentligt.
Ett annat exempel är AutoCad som har (iaf hadde) ett gränssnitt som var helt fullplottrat med ikoner som man som nybörjar tyckte var väldigt förvirrande men som sen blev till en fördel när man blev bättre.
Jag tycker att man inte skall vägra något utan titta på målgruppen och se vad dom har för behov och kunskap och sedan välja ett gränssnitt som passar dom bäst. Precis som i överig programvarutveckling så får man göra en massa tradeoffs även när man skapar grännsnitt tex: enkelhet kan dra ner på produktiviteten osv..
Men i grund och botten så är det väl så att XML främst är avsett för strukturerad informationsöverföring och sub-optimalt för läsning av människor?!? Ikoner är bra för att människor lätt tar in bilder och associerar till dem.
@Mikael: Jag tror att det är en kompromiss människa v.s dator läsbarhet för annars skulle dom inte ha valt ett textbaserat format utan ett helt binärt om det bara var för datorer. Jag föredrar i många fall att använda GUI:n men det finns en del fall då text är mer produktivt.
En väl strukturerad xml fil med syntax highlighting och validering av dtd/xsd är ganska lätt att jobba med.
Men som sagt det gäller att bedömma utefter behovet och kunskapen hos användaren..
Jag menar att det är en kognitionspsykologisk fråga. I hjärnan finns olika mekanismer för att representera verkligheten. Mekanismerna har olika inriktning: spatiella, procedurella, symboliska osv.
Olika människor är olika bra på dessa mekanismer. Själv kan jag till exempel enkelt skanna stora mängder text och hitta stavfel och meningsbyggnadsfel. I mina ögon står dessa saker ut från texten, de riktigt lyser. I min hjärna avbildas texten som begreppsliga symboler och strukturer snarare än som bokstäver, om inte bokstäverna står i fel ordning. Andra, t ex dyslektiker, ser det inte på det sättet. De måste hela tiden tänka på om bokstäverna står rätt eller fel.
Däremot kan jag ha väldigt svårt att läsa piktogram automatiskt, eller hitta föremål i en låda. Jag måste ta en sekund för varje föremål och tänka efter.
Naturligtvis har jag, med den utrustningen, mycket lätt för att läsa kod och konfigurationsfiler och använda konsollbaserade gränssnitt, men däremot lite svårt för peka-och-klicka.
Så vad vill jag säga? Don efter person.
Och jag vet att vi för länge sedan har lämnat Rickards föredrag.