Source and tutorial (in english)

De fleste Java utviklere kjenner til Eclipse som en utviklingsplattform med mange verktøy og hjelpemidler. Eclipse IDE har faktisk blitt så omfattende at de færreste har full oversikt over alle de muligheter man har tilgjenngelig. Mye av årsaken til dette mangfoldet i funksjonalitet i Eclipse er den plug-in baserte arkitekturen. I prinsippet kan en hver utvikler utvide/endre hvilken som helst funksjonalitet i Eclipse, ved å skrive en ny plug-in. Men først må man over en liten kneik for å komme inn i Eclipse plug-in tankegang.

Jeg har skrevet en enkel liten refactoring plug-in som gir utvikleren mulighet til å endre typen på en klassevariabel og tilhørende getter/setter ved en liten wizard. Kilde koden for denne plug-in’en sammen med en liten tutorial for hvordan man kan lage egne refactoring plug-ins kan du finne her.

Tutorialen er skrevet med tanke på utviklere som ikke har utviklet plug-ins for Eclipse og går dermed ikke dypt ned i materien. For mer om plug-in utvikling så er det en god start med JDT Plug-in Developer Guide og PDE Does Plug-in. For grundigere og mer utfyllende om eclipse refactoring rammeverket så finner man forklaring og eksempler i Unleashing the Power of Refactoring og Automated Refactorings in Eclipse-based IDEs. Sistnevnte bruker eksempel fra renaming i properties filer. Og for de som er interessert i å lære mer om det mektige AST (AbstractSyntaxTree) så er dette en fin plass å begynne.

Når skapets posisjon skal diskuteres er det noen man skal lytte til mer enn andre. Når skapet heter webapplikasjoner og webteknologi så hører jeg etter når Martin Fowler og David Heinemeier Hansson snakker. Når ovenfornevnte størrelser snakker sammen og moderator heter Scott Hanselman, da setter jeg iTunes på repeat.
Read more »

Jeg leser nettopp i en interessant rapport fra Butler Group om Rich Internet Applications. Rapporten omtaler diverse Ajax toolkits / frameworks, samt plug-ins til nettleseren som Flash og Silverlight.En av konklusjonene er at det ikke er anbefalt å utvikle Ajax-applikasjoner fra bunnen av. Det er heller ikke anbefalt å lage dem basert på Ajax toolkits. Man bør basere seg på Ajax frameworks eller enda heftigere saker. Dette på grunn av at det er unødvendig å finne opp hjulet på nytt, og at kunnskapsterskelen når det gjelder JavaScript og håndtering av forskjellige nettlesere er høy.

Dette er jeg litt uenig i. Rammeverk har ofte mye i seg som man ikke trenger, og de binder deg også til å gjøre ting på en spesiell måte. Det kan være en rask måte å komme igang på, med en lav kunnskapsterskel, og dette kan virke fristende fra et kostnadsperspektiv. Men når løsningen skal videreutvikles, og når det dukker opp bugs som er vanskelige å finne, så kan rammeverkene komme i veien. Da hadde det vært bedre om du hadde full kontroll på all koden din.

At rammeverk lar deg slippe unna med lite kunnskap synes jeg ikke er noe argument. Du vil få problemer med å finne feil og forstå hvordan ting virker hvis du ikke kjenner teknologien godt. Først lærer du deg den grunnleggende teknologien, så kan du vurdere om et rammeverk bør brukes eller ikke.Til sist har vi spørsmålet om ytelse. Skal du laste ned mange JavaScript-biblioteker til nettleseren fordi rammeverket krever det, selv om de ikke trengs? Hva om du skal lage verdens raskeste Ajax-applikasjon og blir nødt til å tune applikasjonen kraftig for å nå kravene? Igjen mener jeg at et rammeverk kan komme i veien.

Kanskje det er fordi jeg startet min karriere med å programmere 8086-assemblykode, men likevel…

Joel Spolsky skriver om hvordan man kan bruke menneskers innebygde instinkt for å irritere seg over selv den minste detalj, til noe positivt. Ihvertfall når det gjelder å lage fantastisk programvare. Det gjelder å bygge 2,54-centimeter for 2,54-centimeter (han er imperialist av avstamning, den gode Spolsky) og når man har rettet nok 2,54-centimetere så oppnår man en mile med fremdrift. Til dette behøves en svært velutviklet evne til å finne feil overalt, og aldri aldri gi seg med å fikse de tusenvisene av småting som egentlig skulle vært tatt. Man blir en slags gartner som går og luker i bedet helt til alle feil er funnet, alle hjørner er rundet av og alle gradienter går fra øverst til nederst, eller omvendt… Prisen er selvfølgelig at ens nærmeste omgivelser av og til blir offer for umenneskelig detaljfokusert kritikk når man glemmer å legge igjen dette tankesettet på jobben. Så det må man ikke. Les og lær, det er viktig å prøve å opprettholde en sånn pasjon for det man holder på med som Joel skriver om. Først da kan man bygge fantastisk programvare.