Jeg var innom Platekompaniet her om dagen, og syntes (det skjer ytterst sjelden) at den låta spilte i butikken akkurat da, hørtes interessant ut. Jeg forhørte meg om hva det var og noterte det i hodet. Jeg har forlengst sluttet å kjøpe CD’er. For meg er det bare en omvei: Laste sangene over i iTunes fra CD’en, som jeg deretter kan kaste i søpla. Det føles eh.. bortkastet.. Så jeg gikk hjem og søkte opp gjeldende artist på nettet.
Les mer linker er på vei ut og det er flere grunner til dette. Min påstand:
Å ha “les mer” lenker på dine artikler og nyhetsartikler er like dumt som å ha et stort skilt som peker på dørhåndtaket på din utgangsdør hvor det står ”åpnes her”. (I de aller fleste tilfeller er dette åpenbart - medmindre du har kamuflert dørhåndtaket på en slik måte at dine gjester ikke skjønner at det er et dørhåndtak, da er et skilt ok - medmindre du ikke vil at de skal skjønne at det er en dør, da bør du droppe skiltet…. men nok om det!).
Mitt poeng er bare at dersom noe ser ut som en lenke så VET brukerne dine at det er klikkbart og at hvis man klikker på noe så skjønner de også at de kan lese mer om dette. En person som aldri har benyttet nettet før lærer seg to ting relativt raskt:
Etter over ti år med hektisk internettbruk har jeg etterlatt meg digitale spor overalt. I disse dager er det populært å spenne opp skremmebilder av hva all denne informasjonen kan brukes til. Jeg bekymrer meg mer over et annet tenkt tilfelle: Hva skal skje med min digitale identitet når jeg dør? Les hele artikkelen
Vi har vært deltagere i ulike inkarnasjoner av online communities fra tidenes morgen (i Internettsammenheng) hvor BBS og modem med en hastighet på 2400 baud (14 400 bits/s) regjerte mange gutterom rundt om i verden, til webbaserte forum for deling av interesser som er malen for dagens nettsamfunn. Det er en tendens som nå viser seg etter noen års erfaring med nettsamfunn at vi har en enorm vilje til å flytte oss fra sted til sted uten noen åpenbare grunner, som vi kommer tilbake til lenger ut i innlegget. Les hele artikkelen
Å rent faktisk implementere SOA er en ny øvelse, særlig hvis man snakker om en virkelig gjennomgripende tjenestearkitektur, og ikke bare det å være i gang med å etablere enkeltstående tjenester. Hvilke verktøy som vil være nyttige og nødvendige er derfor til dels ennå et diskusjonstema. Kanskje er dette også et område som tiltrekker verktøyleverandører med mer eller mindre akutt behov for å redefinere seg selv til noe annet enn det de holder på med i dag?
En del verktøy begynner imidlertid å få mange tilhengere og ganske entydige definisjoner, et av disse er den såkalte servicebussen, dvs en Enterprise Service Buss. En ESB altså. Som sagt er det ikke nødvendigvis enighet om nøyaktig hva en ESB skal omfatte, men her er ihvertfall en definisjon av hva en ESB skal bidra med:
Det finnes hyllemetre med litteratur på ledelse. Mye av denne litteraturen er amerikansk, påståelig og ikke minst grunnleggende. Mange vil sitte med inntrykket “dette visste jeg jo fra før” etter å ha lest denne type litteratur. Men ikke desto mindre kan det være nyttig å få noen påminnelser om hvilke selvfølgeligheter som utgjør de store forskjellene i hverdagen.
Neil Crofts har skrevet en bitteliten e-bok om ledelse - Authentic Leadership. Den kan lastes ned fritt gjennom Creative Commons som gir fri tilgang til å laste ned og dele åndsverk - så lenge opphavsmannen/kvinnen fortsatt er kjent, og gis honnør for sitt arbeid.
Boken tar 10 minutter å lese. Men langt lengre tid å forstå og etterleve. Du kan laste den ned her:
http://www.authentictransformation.co.uk/professional/AuthenticLeadershipe-book.html
Plate og filmbransjen har i dag et hodebry med å hindre kopiering og spredning av opphavrettet materiale. Etter at Internett ble allemannseie har det dukket opp en rekke teknologien som forenkler og allmenngjør fildeling så enkelt at selv mor klarer å laste den musikk og film. Hvordan skal dette fortsette og hva kan gjøres for at vi som kunder får et bedre tilbud?
For noen år tilbake var piratkopiering begrenset til lan-parties rundt om kring hvor deling av innhold på disken muliggjorde kopiering fra alle på nettverket. Dette var en relativt begrensende spredning av data, men etter hvert som flere fikk internett og det gikk raskere å laste ned ble spredningen større. Tidligere delingstjenester som Direct Connect teknologien tillot den samme delingen over internett. Her var brukerne avhengig av å bruke programmet riktig, finne riktige servere og riktige personer som hadde innholdet man lette etter. Dette var ikke for folk flest og spredningen var fortsatt moderat. Så kom torrent teknologien på banen og endret vår oppfatning av hvordan man laster ned og deler informasjon på nettet. Dedikerte nettsider lar deg søke blant millioner av tilgjengelige nedlastinger og på et øyeblikk kan man sette i gang nedlasting av innhold. Torrent i seg selv er en veldig bra teknologi og i seg selv ikke ulovlig.
Her er linkene til noen av demoene jeg viste på foredraget “Teknologi for rike webanvendelser” på Software 2008 den 13. februar 2008.
Mule ESB er et rammeverk for integrasjon som har fått ganske så mye oppmerksomhet i IT-miljøer og på konferanser som Java Zone 07. Årsaken til dette er nok at Mule sees som et open source alternativ til svært dyre integrasjonsteknologier, samt dens nære knytning til populære open source teknologier som Spring, Maven og JBoss.
Så hva kan Mule brukes til og hvordan funger det? Mule er en Enterprise Service Bus i forstand at den består av komponenter som kan motta data, transformere data, eksekvere kode, og sende data videre. Disse komponentene konfigureres via XML filer hvor prosessflyten og protokoller spesifiseres. Her er en figur som illustrerer et tenkt scenario hvor den første komponenten mottar data via en Web Service og legger dataene på en kø via JMS, og er ferdig. En annen komponent lytter på køen, transformerer dataene og splitter den til en komponent som lagrer dataene til en database og en annen komponent som sender dataene til et annet system via en Web Service.
Dette er et enkelt men veldig typisk scenario for integrasjon. Siden flyten og protokollene konfigureres via en XML fil er det en smal sak å endre det slik at dataen sendes til en tredje komponent, samt å legge på transaksjonsstøtte for garantert levering fra kø til destinasjon.
Mens flyten, protokoller, destinasjoner og transaksjons konfigureres via en XML fil, så består selve innholdet i hver komponent av en enkel java klasse. Å lage en web service kan være så enkelt som å lage en klasse med en metode String getName() og så spesifisere XML filen at det skal være en Web Service.
It’s free. There must be a catch? Vel, ja. Hovedproblemet med Mule er den teknologiske terskelen for å komme i gang. Mule består av så mange forskjellige teknologier, hvor mange av dem, blant annet Mule selv, er nokså dårlig dokumentert. Så foruten at man trenger en god forståelse av integrasjonsteori som synkron/asynkron kommunikasjon, normalisering, korrelasjoner, transaksjoner, xml og database, så er det underliggende teknologiene som er en utfordring. Teknologier som man bør kunne for å få gjort noe i Mule vil generelt være: Java, Spring, Maven, Web Services (Xfire,CXF, JAX-WS), JMS, XML, JDBC, JMX og J2EE applikasjons tjener.
Det er mange måter deployere Mule på, men måten jeg har funnet ut fungerer mest tilfredsstillende er pakke hver instans som en ear fil, og hot-deploy til JBoss. Når man deployer flere instanser så vil hver instans ha sin egen classloader og være fullstendig separat. Problemet med dette, i forhold til andre ESB produkter, er at Mule ikke kan dele såkalte konnektorer mellom ulike instanser. Konsekvensen av dette er at dersom man har to instanser som eksponerer Web Services så må hver instans ha sin egen port. Dette kan fort bli en utfordring dersom man har mange instanser.
Så for å summere opp. Fordeler med Mule er
Svakheter
Så alt i alt så er Mule et veldig interessant rammeverk som i mange tilfeller vil være tilfredsstillende for å gjøre integrasjon.
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.
Kommentarer(0)
