Som java konsult möter man ofta en utbredd uppfattning att det är affärslogiken och lagren därunder, ejb:er, databaser och integration som är svårt och komplext i en JEE applikation. Själva gui:t är något som är bäst lämnat åt långhåriga, coka-cola drickande, ”html hackande” ynglingar.

Den här uppfattningen är vanligast bland människor som är bra på andra saker än just utveckling, men den är olycklig då det ofta handlar om personer som är tongivande, både då det handlar om hur stor del av projektbudgeten som ska avsättas, liksom i skapandet av nya affärer inom området – och därigenom möjligheten till intressanta uppdrag.

I min värld är den kritiska massan kunskap som behövs för att göra ett markadsmässigt gui, ofta större än vad som behövs för de flesta omgivande delar sammantaget.

Detta är naturligtvis en sanning med modifikation; Inom forskning runt artificiell intelligens så kanske inte guit kommer i första rummet. I rena integrationsprojekt lever guin en ofta undanskymd tillvaro och visst kan klustring och paralell programmering bli väldigt komplicerat

Själv rör jag mig dock mestadels bland kommersiella/administrativa applikationer ämnade att hjälpa företag med försäljning, logistik, integration, finansiella tjänster el dyl.

Ex:

Databaser med sql och stored procedures kan vara komplexa, men det man behöver känna till för att framgångsrikt kunna använda tekniken är begränsat. Lägger man därtill ORM mappning med tex Hibernate eller JPA så kompliceras världen ytterligare. men det finns en väldigt finit kunskapsnivå när du behärskar detta, och det rör sig om en specifikation på några hundra sidor för respektive. Nämnda två ORM tekniker täcker dessutom större delen av marknaden Och är extremt lika.

Integration kan vara komplext för integratörer, men om vi begränsar oss till området täcks av java kontainern och låter någon kunnig person fundera ut “övergripande arkitekturella principer” för hur meddelanden ska propageras och annat fluff, handlar det främst om att validera och skyffla xml. Kunskapen som behövs för att uppnå gurustatus på området ryms i en 2,5 cm tjock bok. Sen kan man därtill lägga kunskap om separata ”produkter” som sorterar inom integrationsområdet – brokrar, mappningsverktyg etc, som i sig kan vara komplexa, men som kanske heller inte sorterar inom JEE. För applikatören gäller det att känna till vida begrepp som grundläggande SOA och kanske REST.

Säkerhet är ett område som pockar på uppmärksamhet och här gäller detsamma som för integration – Kunskap i guru klass ryms i en bok om några centimeter.

Bygge, deploy och infrastruktur är ett annat område som utvecklare helt enkelt ”måste” kunna. Området rymmer allt från konfigurering av miljöer, till ant/maven, olika “continous build” och “code coverage” lösningar samt paketering, tex OSGi som kommit starkt de sista åren.

Detta, draget till sin spets, kan bli väldigt omfattande, och visst finns det riktigt kunniga människor som specialicerar sig inom detta. Tyvvär är detta också ett ofta eftersatt område som det snålas in på då människor som sitter på pengarna ofta saknar insikter. Det ironiska är att investeringar i den här delen av applikationen ofta betalar sig mångdubbelt på några års sikt

Unittest är en nödvändighet att känna till idag, men även här uppnås en gångbar kunskapsnivå med ganska liten ansträngning.

Spring och Ejb30 är omfattande och komplexa ramverk (i alla fall Spring och det spänner dessutom över i princip alla områden som ytterligare ett abstraktionslager på JEE) och här finns i mitt tycke den största utmaningen utanför guit. Sen gäller det ju för utvecklare - i alla fall de som är konsulter - att vara pragmatiska framför allt. Hur komplext behöver saker egentligen vara - enkelhet är nästan alltid bäst om annan motivering saknas.

Java och JEE är förutsättningar för att verka i den här världen. Att arkitektur är ett pletantiöst begrepp som egentligen handlar om att kunna använda och identifiera något dussintal designmönster kanske är att dra det väl snävt - speciellt som det finns många “arkitekter” som inte skulle känna igen ett pattern från g4 om det hoppade upp och bet… Kort sagt; dimmigt område

Gui däremot, kan handla om något så enkelt som en servlet driven html-sida, men moderna gui:n omfattar webbramverk som spring-mvc/webflow eller JSF/Struts, som i sig är omfattande och där det dessutom finns en mängd olika alternativ. Till detta har man förmodligen någon form av ajax-ramverk som sköter asynkron kommunikation med webbsidan, html med css som är långt mycket mer komplicerad än för bara några år sedan. JavaScript ramverk som Dojo, eller åtmindstonde avancerade javascript som använder DOM ramverk. Förutom detta kommer naturligtvis grundläggande kunskaper om layout och kanske bildbehandling som man kan tänka sig att man kan lägga ut på lämplig webbyrå (coka-coladrickarna), tyvvär en lyx som det ofta inte finns budget för i mindre projekt. Dessutom har det halkat in ytterligare ett abstraktionslager i gui-utvecklingen på i form av portaler och portlets. Portlets - förvirrande lika servlets, är ändå en helt separat teknikgren att känna till.

Sammantaget, gui utveckling kan blir grymt utmanande och har den egenheten att slutresultatet blir märkbart bättre ju mer tid man lägger på det. Ett bra gui har dessutom ett starkt affärsvärde – fråga valfri säljare vilken del av en applikation han helst presenterar för kund!