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.
Mandag 3. desember var en aldri så liten merkedag i norsk internettbransje, da Bransjerådet for søkemotormarkedsføring hadde sitt stiftelsesmøte. Nå skal det nemlig bli mulig å handle konsulenttjenester for å optimalisere sine nettjenester i trygg forvissning om at man ikke risikerer sanksjoner fra Google eller andre søkemotorer.
Bransjerådet skal ikke bare fremme kunnskap om fagområdet, men skal sikre at brukere og kunder i søkemotormarkedet ikke skal utsettes for feil type rådgivning. Medlemmer av rådet forplikter seg til å følge rådets regler for søkemotormarkedsføring, og annerkjenne vurderinger fra en egen klagenemd som skal vurdere eventuelle konflikter.
Det kan kanskje virke rart at man ser behovet for å etablere et bransjeråd for søkemotormarkedsføring, herunder søkemotoroptimalisering (SEO). Det er jo ikke akkurat Norges lover som brytes om man skulle forsøke seg på et kreativt grep for å få en høyere plassering i søkemotorene. Og i søkemotorenes tidlige barndom kunne man langt på vei si at dette ikke var verre enn å gå på epleslang. Regelbruddene var uskyldige, og langt på vei ufarlige.
Men i dag kontrollerer søkemotorene, med Google i spissen, nær sagt all trafikk som er basert på at brukere skal finne frem på internett. Søk er i følge Forrester og Georgia tech. GVU center kun overgått av e-post når det gjelder folks bruk av internett. Ikke minst har omfanget av innhold på nett blitt så formidabelt at vi er helt avhengige av at søkemotorer kan gi oss relevante treff på våre søk. Søkemotorene er med andre ord nødt til å slå hardt ned på forsøk på å manipulere regelsettet deres, hvis ikke vil deres produkt levere dårlig. Bedrifter er på sin side blitt helt avhengig av søkemotorene, og en utestengelse fra resultatlisten fordi man bryter regelsettet kan få fatale følger.
Det er med dette som utgangspunkt man må se på bransjerådets begrunnelse. Når arbeidet som skal utføres er av så kritisk art, både ovenfor søkemotorene og for bedriftene, er det en klar trygghetsfaktor at det nå finnes en tiltrodd tredjepart som man kan henvende seg til for å finne frem til seriøse leverandører og ikke minst grunnleggende informasjon om søkemotormarkedsføring.
Dynamisk er fint. Dynamisk betyr bevegelig, effektivt og hensiktsmessig. Dynamisk er et plussord, og udynamisk er et tilsvarende minusord. Dersom man kaller en person udynamisk er det ikke for å rose, skryte og framheve positive egenskaper. Udynamisk er det når ting er helt fast definert, og man (nærmest vrangvillig) ikke ønsker å bevege på dem. Udynamisk gjør det vanskelig å gjøre annet enn det som er faktisk planlagt og avtalt - og gode idéer skal man helst ikke presentere underveis. For å sikre gode vilkår for innovasjon og kreativitet er det derfor viktig å være dynamisk.
I Tarantell leverer vi prosjekter. Prosjekter er (av andre enn oss) definert som å være “ikke-repeterende” arbeidsoppgaver. En form for dugnad, der man setter ned en arbeidsgruppe eller prosjektgruppe på tvers av linjeorganisasjonen; på tvers av ordinære ansvar og oppgaver. En prosjektgruppe har mandat til å løse én bestemt oppgave, innenfor gitte tidsrammer og budsjettrammer.
Et prosjekt kan i sin natur ikke gjentas. Om det kunne, ville det vært en prosess, en produksjonsprosess - som gjerne kunne inngå i en industribedrift. Måten man lager hamburgere på hos McDonalds er en slik prosess: man følger de samme stegene og kommer til det samme resultatet. Gang på gang, i et repeterende mønster.
I et prosjekt kan man gjenbruke erfaringen og kunnskapen som ligger igjen hos prosjektdeltakerne, men prosjektet i seg selv er for unikt til å gjentas steg for steg.
Gjennom denne ganske raske argumentasjonsrekken kan man trekke den slutningen prosjekter (som er unike) har behov for dynamikk (for å sikre nødvendig innovasjon og kreativitet). Dynamiske prosjekter burde derfor være et plussord som var mye brukt. Men det er det ikke. Istedet hører man mye om agile prosjektmetoder, smidighet, fleksibilitet og effektivitet. Dette er verktøy for å nå prosjektets målsetning - ikke for å påvirke prosjektets målsetninger. Den kreativiteten og innovasjonen man gir rom for er for å levere det beste resultatet - ikke for å omdefinere behovet.
Det er viktig å se denne forskjellen, slik at man legger til rette for den rette bruken av alle kreative krefter (og de er mange!). Prosjekt som arbeidsform er i de fleste tilfeller lagt opp som en relativt rigid og udynamisk gjennomføring. Man har fastsatte budsjettmidler, en fast tidsramme og et fast team av mennesker til å løse oppgaven. At teamet eller arbeidsgruppen har behov for en smidighet i sin gjennomføring er lett å se: Når alt annet er fastlagt, er det kun den mennesklige tilpasningsevne som kan dekke opp for uforutsette forhold (og de er det OGSÅ mange av!).
Finnes det da ikke dynamiske prosjekter der ute? Prosjekter der målsetningene defineres basert på en kontinuerlig læringsprosess?
De finnes. Men jeg er ikke sikker på om det gjør prosjektgruppens arbeid noe enklere. I dynamiske prosjekter vil man arbeide på et høyt abstraksjonsnivå; og man er nært koblet til forretningsstrategi og bevilgning av midler. Dette gir helt andre leveransetyper enn de man er vant til i mer rendyrkede utviklingsprosjekter. Man vil f.eks. levere en idé, et mandat, en beslutningsunderlag - kort sagt et premiss for å gjøre den endelige leveransen. Og det er noe ganske annet enn en å komme til en sluttført løsningsleveranse.
Kommentarer(1)
