Jeg vil igang med at lave en "Cross Domain Mashup":http://www.frankvilhelmsen.com applikation der asynkront kan hente data fra forskellige domains. Min klient er i HTML5, CSS3 og naturligvis Javascript. Protokollen er HTTP, kommunikation er asynchronous og indholdet skal være JSON fordi det allerede er Javascript, kompakt og ikke behøver parsing af nogen art. JSON skal pakkes ind JSONP for at overvinde Same Origin Policy sikkerheds modellen. Flickr Flickr er en fantastisk ressource til at præsentere og administrere billeder. De udstiller også en stribe API'er til mange forskellige ting. Jeg har kun interesser for "REST API'et":http://www.flickr.com/services/api Den præcise URI jeg vil bruge er til min egen foto feed på flickr. Det er værd at bemærke de sidste parameter i URI'en "format=json&jsoncallback=?". Disse paramter fortæller resourcen at response skal være i formattet JSON og at kaldet måske er Cross Browser og derfor skal JSON pakkes ind som et JSONP kald. Ydermere kan man specificere et callback navn "joncallback=?" ved spørgsmålstegnet hvis man vil have en bestemt metode kaldt når script er loadet. | URI | JSONP | | &format=json | jsonFlickrFeed({ "title":"Uploads" }) | | &format=json&jsoncallback=? | ({ "title": "Uploads"}) | | &format=json&jsoncallback=visfoto | visfotos({ "title": "Uploads"}) | Det kan betale sig at undersøge data grundigt inden man går igang med at skrive klienten. Hvis man kan operere/navigere med curl -i URI gennem de ønskede scenarie er man langt. Nu klienten. <pre> $(document).ready(function(){ $.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?id=7185299@N07&format=json&jsoncallback=?", function(data){ $.each(data.items, function(i,item){ $("<img/>").attr("src", item.media.m).appendTo("#images"); if ( i == 8 ) return false; }); }); }); </pre> Flickr ressourcen bliver ramt gennem Jquery og henter data. Der itereres gennem data der indeholder title, link til foto location, hvornår det er taget og en masse andet. Elementet item.media er en server location men der følger et m med som fortæller noget om de størrelse og repræsentationer som billedet allerede er skaleret til. Prøv fx at skifte m ud med et s. Nu til den næsten klient app som er twitter updates. Koden herunder henter et antal twitter status update og iterere gennem hver update. Undervejs ledes efter regulære udtryk der minder om et link tag og hvis udskiftes med et rigtig html link anker. Hver update bliver adderet til hash# div tag. Det er muligt at bruge this[array] til at hente data ud af strukturen. Læg også mærke til at twitter vil have en count parameter med ind for at minimere antal updates over linjen. Bemærk også at er mere REST aware i det de udnytter HTTP header information om den returnerede repræsentation og caching TTL i netværket. De udnytter infrastrukturen bedre end flickr. <pre> var regexp = /((ftp|http|https):\/\/(\w+:{0,1}\w*@)?(\S+)(:[0-9]+)?(\/|\/([\w#!:.?+=&%@!\-\/]))?)/gi; $(document).ready(function(){ $.getJSON("http://twitter.com/statuses/user_timeline/frankvilhelmsen.json?count=6&callback=?", function(data, textStatus) { $.each(data, function(i) { var twitter_time = prettyDate(this['created_at']) var twitter_uri_encoded_text = this['text'].replace(regexp,'<a href="$1">$1</a>') $("#statuses").append("<li>"+twitter_time+": "+twitter_uri_encoded_text+"</li>"); }); }); }); </pre> Server Indtil nu har jeg kun forbrugt ressource hvor jeg kun kender interfacet men jeg vil jo også gerne udstille mine egne REST baseret Cloud ressourcer. Heldigvis understøtte rubyonrails dette lige ud af boxen. Min platform er "Heroku | Ruby Cloud, Platform as a Service":http://heroku.com git og Rails. DNS og alt er sat op. <pre> p = Post.find(:all, :select => 'id, title, osv') response_to ... format.json {render :json => @posts, :callback => [:callback] } end </pre> Det eneste jeg skal gøre for at enable en ressource til cross browser er tilføje denne ":callback => [:callback]". Rails har altså dekoreret JSON til JSONP format uden at jeg behøver at gøre mere. Men måske ville jeg reagere anderledes på ønsket om at give parameter som denne med i requestet "&callback=chanceheader". Direkte til klienten. Og nu er det nemt for koden er næsen det samme som før. <pre> $(document).ready(function(){ $.getJSON("http://XXX/posts/title/all?format=json&callback=?", function(data){ $.each(data, function(i) { $("#titles").append("<li>"+this.post.id+" - " +this.post.title+"</li>") }); }); }); </pre> 2010-01-22T11:49:10Z 157 true 2010-01-22T14:32:11Z For at forstå værdien og forholdet mellem virksomhedens SOA løsninger og mashups er det nyttigt først at forstå hvorfor vi i det hele taget har brug for mashups! * mashups give dig hurtigere svar * mashups forbedre din ressourceforbrug (af både personale og bløde/hårde computing ressourcer) * mashups hjælpe dig med at tage fat på nye forretningsmuligheder ved at lade brugerne sammensætte data i en opportunistisk måde For en SOA enable virksomhed ligger det lige for at bygge og udstille et mashup lag mellem den interne SOA arkitektur og deres kunder. Det vil indkapsle de meget forretnings orienterede services og udstille et klient venligt allotment data lag. Det er forørigt en god måde at holde sine klient publicerede interfaces konstante mens den interne SOA protokol sikkert udkommer i flere nye versioner. Set i forhold til SOA og alle de komplekse "Entreprise" løsninger er mashup mere: * Collaborative. Mashups er designet til at blive mærket/søgba/deles med andre. * Focused on 'pack'. Mashups er typisk skabt et lille antal selekterede beslægtede individer. * Tidsfølsomme. Brugernes behov for data er nu. Mashups har normalt nær real-time levering krav. WWW er real-time. * Noninvasive. Der skal ikke indføres ny infrastruktur eller faglige forbindelser. * Limited cleansing. Mængden af data og behov normalisering bør sammenlignes med størrelsen at et Excel ark. * Have a face. Mashups har normalt et ansigt som en widget. Mashup applikationer eller mashup widgets lever godt med et SOA endpoint som backend og vil betrakte SOA akitekturen som en service cloud. Det vil hjælpe med til at fragmentere infrastrukturen på en mere hensynsfuld måde fremfor at SOA løsningen både skal sig af tunge forretningsmæssige ting og samtidig henvender direkte til enkelte kunder. Det er her mashup kommer ind i billedet. Et mashup kan bidrage til at skabe en ny, dynamisk, og potentielt stor gruppe af forbrugere til dine tjenester. Og det er derfor en SOA-arkitekt skal bekymre sig om mashups: Mashups kan blive en uvurderlig direkte sammenhæng mellem en SOA og erhvervslivet i en organisation. Der findes flere typer af mashups eller arkitektoniske stilarter. Normalt kan man kalde en webside for en mashup når den benytter data og funktionalitet fra mere end den server hvor den kommer fra. Ofte vil der også være langt mellem de adrætte kunde relaterede projekter og de afdelinger som skaber services. # Klient Mashup er den mest almindelige stil og den er målrettet til at eksisterer hos klienten i form af HTML/CSS og Javascript. En fordel er at man delegere datafangst til ud til klienten dermed væk fra serveren. # Data Mashup er mindre kendt idet den kombinere samme type af media og information fra flere forskellige kilder i en enkelt repræsentation. Denne stil er server-baseret og samler interne og eksterne data til en enkel ny repræsentation. # Enterprise Mashup er i fremgang og fokuser på at repræsentere forskelligformede data i en mere enkelt form og fordeler dermed arbejde mellem forretningen, udvikling og ikke mindst hardware. Denne type virker specielt godt i forbindelse med sande adrætte udviklingsafdelinger der hvor krav til "time to market" og iterativ udviklings proces er et issue. Enterprise Mashups er sikre, visuelle rige web applikationer der eksponere handlingsrettede information fra diverse eksterne og interne informationskilder. Mashups synes at være en variation af et Design Pattern Facade. En forskel er dog at snitflade/interfacet mellem de enkelte systemdele er mere tydelig og afgrænsede. Facade pattern er en interproces kommunikation mens mashups er fysiske adskilte grænsefladesnit over HTTP. Mashups kan med fordel bruges med software as a service(SaaS). Mange mainstream virksomheder kan drage fordel ved brug af mashups til at forenkle deres integration mod interne og eksterne serviceorienterede arkitekturer(SOA) ved at gøre dem tilgængelige til mashups. Med standardiserede protokoller skabes en ensartet metode til at få adgang til oplysninger udfra et bredt sæt af platforme, operativsystemer, programmeringssprog og applikationer. Selv disse kan igen genbruges til at levere helt nye tjenester og applikationer på tværs af organisationer. Det giver virksomhederne fleksibilitet. se OIORest. Mashups er velegnet til at skabe rige applikationer med stor udnyttelse af klient tilstand eller state i form af "hateoas"(Hypermedia As the Engine of Application State). Fordi mashup fordre mere tilstand væk fra serveren opnås mange fordele. En server med stateless tilstand er en billig server. Man behøver ikke replikere tilstand i server farmen. Hvis det er ligemeget hvilken server man rammer er det muligt at skabe skalerbare løsninger billigt. Javascript kan kun kalde den server hvorfra den kommer. Denne sikkerhedsmodel hedder Same Origin Policy(SOP). Hvis javascript kunne kalde servere med ondsindet program stumper kunne man lave "Man-in-the-middle" angrep mellem bank og kunde. Dette er meget komplekse problemstillerer men for specielle applikationer kan man kontrollere denne trafik. Man kan overvinde SOP ved at indsætte et dynamisk scriptelement i websiden Moderne browsere understøtter kommunikation mellem klient og server og er den vigtigste bestanddel af nye såkaldte Web 2.0 applikationer. Data hentes uden er reloade websiden ved hjælp af XMLHttpRequest objektet der lader Javascript etablere HTTP-forbindelser til en ekstern server. Denne form for kommunikation er basen i mashups. Resultatet af en asynkront kald fra en browser er data i JSONP format. Mashups bruger JSONP til at lave et lille trick på klienten så koden kan kalde tredieparts services uden om SOP. Som regel vil man gerne have overført data i JSON format fordi JSON er valid Javascript pakket ind JSONP formatet. JSONP har en præfiks der angiver input som argument for data selv. Navnet på dette præfiks er typisk en javascript callback funktion men det kan også være en variabel. JSONP gør brug af script-tags og dette åbner verden. Mashups kan publicere en mængde forskellige Web syndication formater som RSS og Atom, REST og SOAP, WSRP kompatibel, blogs, Atoms til mobiltelefon. Netop fordi mashups kan blive eksponeret som REST, WSDL og JSON baserede tjenester ser de ud og føles som en rigtige SOA baseret tjenester for de udviklere der ønsker at forbruge dem mens de bliver mere af en "bag kulisserne" kerneydelse. Mashups versus portaler Mashups og portaler er sammenlægning teknologier men alligevel helt forskellige. En Portal samler en masse funktionalitet mens en mashup er et fragment, en "portlet", og flere mashups kan samles i en enkelt webside. Portal er klassificeret som en traditionel web-server-model med en veldefineret strategi mens mashus er mere løst definerede "Web 2.0"-teknik. Det siges at en Portal er som en "Salatbar" mens mashup er en "smeltedigel". Portal styre sit state gennem en event-model defineret gennem et portlet API mens mashup selv har sit interne state og benytter REST baseret CRUD arkitektoniske principper ligesom mashup bruger base standarder som XML, REST og Web Services, RSS og Atom. Mashups Jeg er ikke i tvivl om at mashup applikationer vil vinde indpas over de næste år. Desværre er især store virksomheder i Danmark utrolig konservative med hensyn til nye teknologier og der vil sikkert gå adskillige år inden de helt åbenlyse fordele ved mashup slår igennem. For mig er fordelene åbenlyse. Små startup virksomheder vil kunne når deres mål hurtigt og effektivt og lade allerede indkøbt infrastruktur håndter ting som development, caching, scaling, clientstate, osv. Alle ting som Enterprise verden bruger oceaner af tid og resource på. Utroligt at helt enkelte beslutninger kan resultere i kæmpe fordele. 2010-01-18T19:07:49Z 156 true 2010-01-20T08:14:59Z Sommeren er forbi nu, og den nærmest fløj afsted, tomhændet står du tilbage & ka' slet ikke følge med! CV Jørgensen skrev de ord tilbage i 1988 og langt om længe, er jeg ved at forstå den reelle betydningen af den sætning. I sidste julebrev tænkte jeg på konceptet tid, og at tiden går sin gang ligemeget om vi er med eller ej. 2009 er et af de år hvor vi har udnyttet tiden tiden til vores fordel og leget at honning og forstand flyder frit. Den 9. april 1940 blev hestetrukket artilleri fra Ringsted anbragt i stillinger øst for Ringsted, så byen om nødvendigt kunne beskydes, men da der hurtigt kom ordre fra regeringen gennem den kommanderende general om, at der ikke skulle ydes modstand mod den tyske besættelse, så trak man artilleriet tilbage til kasernen igen, hvor den normale garnisons-tjeneste blev genoptaget. "Ringsted kaserne":http://www.frankvilhelmsen.com/posts/154-Ringsted-Kaserne Det herrens år 2009 var året, hvor recessionen i samfundet var så voldsom, at vores lille familie havde råd til at købe hus ved Artilleristen, sjovt nok præcis der hvor artilleriet var stille op i 1940. Derfor mente jeg at der var god grund til at døbe huset "skydebanen". Jeg må dog erkende, at mit forslag ikke blev vel modtaget. Når vi kigger tilbage over året 2009 er dette huskøb naturligvis det langt det overskyggende emne. Det er en utrolig positiv oplevelse at have så meget plads. Tænk at kunne gå i bad uden at ramle ind i alt ting. Alene den ekstra plads har tilført noget ekstra livskvalitet i vores dagligdag. På den anden side er det skæmmende at mærke hvilken betydning plads og luft har på ens velbefindende. Siden starten af Juli hvor vi flyttede har vi hver dag, glædet os til at komme hjem og vi har aldrig brugt så meget tid til at se på himlen som nu. Ligeledes varmer det om hjertet at se bambi(er) gå forbi udenfor, vi tror der er en hjorte sti mindre en 3 meter fra vores vindure. Der har skam også været en del bekymringer i processen, som at styre havearbejde, carport, stikledninger og flyvende trampoliner har skabt flere problemer, end vi turde drømme om. Familien Familien har det godt. Vi har alle fundet os tilrette, og det virker som især som Christian har haft godt af transformationen, han nyder at hele grunden er hans egen, og han ikke behøver tænke på naboerne. Han har fået nyt værelse, men synes at hele huset er hans. Meget mod sædvane er vi nu aktive med forskellige sysler om aftenen når vi er kommer hjem fra arbejde. En negativ effekt er, at vi er blevet territoale og bryder os ikke om, at noget eller nogen overtræder vores rum, hverken hunde eller mennesker :-) Christian Christian vokser i fuld fart nu, og løsningen er mad, der behager hans øjne og at vi overholder det faktum at han ikke er en drøvtygge med 4 maver. Han trives over al forventning, og vi er superstolte af ham. Han har så utroligt meget at sige. Christian er virkeligt begyndt at forstå forskellen mellem godt og ikke så godt. Udadtil er Christian en glad lille dreng, en rigtig mors dreng men indadtil er han en følsom tænker, som er ved at finde ud af sammenhængen mellem det talte ord og reel handling. Hvis Christian oplever at der ting der er sagt ikke følges op af handling kan han blive noget så skuffet. Christian har en stor motor, han kan køre langt på meget lidt brændstof. Han taler gerne med alle omkring ham, samtidig også kan det knibe med at høre når klasselæren prøver at få ham til at tie stille. Der er også lidt med bandeord, men den er vi flere der arbejder med. Næste år må vi til at kigge lidt på noget, der kan styrke koncentrationen. "Det sætter jeg pris på" har fået en ny mening i huset. Der er lavet en aftale om, at visse services bliver afregnet, så fx at tømme opvaskemaskinen giver en femmer, slå græs giver femten osv. Det er helt sikkert Moffe's karakter afregningsmetode, der har en afsmittende effekt. Håber Moffe også sætter pris på de nye karakterer, for de er rigtig gode! Arbejde Arbejdet dette år er baseret på tesen: "work smarter, not hard". Vi forsøger at leve op til det at være en del af et videnssamfund og reflektere over vores handlinger fremfor at repetere os selv uden bagtanke. Undskyldningen med at kun lave noget halvt, fordi der ikke var mere tid dure ikke. Susanne har opnået en skarpere fokus både på arbejdsproces og metode. Det virker som hun er begyndt at slappe mere af, og det virker også på os andre. Hun elsker at designe ting eller sammensætte produkter, og det bliver en stadig større del af hendes job. Hendes evne til at bedømme designs og trends i tiden er fantastisk, og bliver slet ikke udnyttet fuldt ud. Susanne har en kreativ sjæl med et enormt potentiale, men hun tør ikke stole fuldt ud på sin evner. Susanne har i arbejdsmedfør rejst en del i år til fx Kina, Hong Kong, Tyskland og England. Brug livet og vær provokerede proaktiv. Dette slogan er fra det pensionsselskab, hvor jeg det sidste år har siddet i en udviklingsafd. Jeg startede året med at være ressourceforstærkning, men langsomt har jeg bevæget mig mere og mere i retning af Enterprise Architect. Det er en rolle der indbyder til en statisk tænkning/holdning, som jeg har kæmpet mig væk fra i årevis men min naturlige nysgerrighed og frækhed fører mig ofte i den retning. Min lidenskab for applikations-design er dog uforandret. Det er der, jeg næres og fyldes af arbejdsiver, og det er også der, hvor behovet er langt størst. Det er ikke op til mig at vurdere om slogan holder stik. Hos Cybercomgroup har jeg forsøgt at deltage mere engageret i kundekontakt, sociale relationer og faglige netværk. Udover det er jeg glad for at kunne hjælpe forskellige medarbejder med faglig sparing, og om hvordan man udfylder rollen som konsulent. Jeg har "kun" deltaget i tre konferencer i år, hvoraf jeg på de to var inviteret som gæst. Ferie Vi har ikke holdt rigtig ferie i år. Susanne har godt nok været på en skøn ferie på Skiatos med sin mor, hvilken vi "andre" var lidt fortørnede over, idet vi plejer at være med på den lille skønne græske ø, som vi savner. Næsten samtidig arbejdede jeg hårdt på "formen i de italienske dolomitter":http://www.frankvilhelmsen.com/posts/144-Dolomite-Training-Camp Susanne skal forresten ha en stor tak for at gøre hus-handlen færdig fra en Græsks strandpromenade, mens jeg cyklede rundt i Italien. På en eller anden måde er det fedt at kunne stikke retningen ud og lade andre stå for detaljerne. Selv om vores hus fylder en del i dette efterår, har vi alligevel haft tid til kulturelle tiltag, et par som er værd at nævne er; Carmen i Operaen, Les Miserables på det ny teater, en tur på Statens Museum for Kunst og et meget interessant besøg på Middelaldercentret. Det er, som vi er ved at se elementer af klassisk musik som attråværdigt. Vores lyst til at invitere gæster er også kommet tilbage, og vi håber, at vi kan lave lidt kvalitetsservering for jer til næste år ved Artilleristen. Det var tanker fra året 2009. Håber at det næste år vil bringe endnu flere hyggelige stunder sammen med jer alle. Ha en rigtig glædelig jul og et godt nytår. Susanne, Christian & Frank 2009-12-11T07:48:07Z 155 true 2009-12-14T09:27:46Z I Ringsteds nordlige del på Teglovnsvej finder man nogle store røde kaserne-bygninger, og her har Artilleriets Befalingsmandsskole holdt til i mange år. I de senere år har kasernen dog kun været brugt til forskellige stabsfunktioner, og nu er den blevet nedlagt som kaserne og solgt til Ringsted Kommune. Det er imidlertid kasernens historie under anden verdenskrig, der må vække interesse, da denne er ret dramatisk. Den 9. april 1940 blev hestetrukket artilleri fra Ringsted anbragt i stillinger øst for Ringsted, så byen om nødvendigt kunne beskydes, men da der hurtigt kom ordre fra regeringen gennem den kommanderende general om, at der ikke skulle ydes modstand mod den tyske besættelse, så trak man artilleriet tilbage til kasernen igen, hvor den normale garnisons-tjeneste blev genoptaget. I 1943 gik tyskerne til aktion mod de danske soldater, og på Ringsted Kaserne forløb interneringen og hjemsendelsen af de danske soldater forholdsvis udramatisk, men denne begivenhed betød, at kasernen derefter blev overtaget af de tyske militære myndigheder, der ligeledes beslaglagde et par af de nærliggende villaer på Teglovnsvej. I mellemtiden var der opstået flere danske hjælpekorps, som dels skulle forberede danskere til tysk militærtjeneste og dels hjælpe tyskerne med opretholde sikkerheden i landet, og nogle af disse hjælpekorps fik overladt Ringsted Kaserne og de omtalte villaer. På kasernen rykkede der således medlemmer af flere forskellige hjælpekorps ind, f.eks. folk fra Schalburg-Korpset, og kasernen blev således både et militært udannelsessted og et hjemsted for en større styrke med politiopgaver. At der på Ringsted Kaserne allerede var placeret danskere i tysk militær- og politi-tjeneste fik betydning under den senere folkestrejke i flere store danske byer. Et af kravene i den københavnske folkestrejke var nemlig, at man forlangte det såkaldte Hipo-korps ud af byen. Dette korps var ment som et hjælpepolitikorps i tysk tjeneste, der var oprettet af de tyske myndigheder, efter at man havde slået til mod danske politi. Hipo-folkene skulle således erstatte de internerede og flygtede danske politifolk, men Hipo-folkene var overordentligt upopulære i befolkningen, og det var baggrunden for kravet under folkestrejken om korpsets fjernelse fra København. Da de tyske myndigheder gav efter for folkestrejkens krav, så var det jo helt naturligt at flytte Hipo-korpset til Ringsted Kaserne, hvor man som nævnt allerede havde placeret folk fra andre danske hjælpekorps. Derved blev Ringsted Kaserne faktisk det vigtigste tjenestested for danskere i tysk tjeneste, og folkene fra de forskellige hjælpekorps blev så samlet operativt i ”Vagtbataljon Sjælland”, der dels skulle støtte tyskerne militært under en evt. allieret invasion og dels udføre sikkerhedsopgaver af en mere speciel natur for de tyske myndigheder. Da vagtbataljonen netop bestod af folk fra flere forskellige korps, så fik bataljonen aldrig en egentlig fælles uniformering. De tjenestegørende gik simpelthen i de uniformer, som de havde fået i deres oprindelige korps, hvorfor man da også på kasernen havde danskere i tyske hæruniformer, tyske SS-uniformer og forskellige særlige danske udgaver af disse uniformer. Vagtbataljonen bestod af ca. 700 mand, hvoraf mange faktisk havde kamperfaring fra østfronten, da de tidligere havde gjort tjeneste i danske Våben-SS enheder som f.eks. Frikorps Danmark og det senere Pansergrenaderregiment Danmark. At Ringsted Kaserne var blevet det vigtigste tjenestested for danskere i tysk tjeneste gjorde naturligvis, at kasernen blev befæstet meget omhyggeligt, da krigen nærmere sig sin afslutning. De tjenestegørende i Vagtbataljon Sjælland hørte jo netop til dem, der havde mest at miste i denne situation, og på kasernen gjorde man da også parat til et såkaldt pindsvineforsvar, dvs. et forsvar vendt til alle sider. Man opbyggede således maskingeværstillinger og lette kanonstillinger hele kasernen rundt og befæstede den yderligere med pigtråd. Det var faktisk holdningen i Vagtbataljon Sjælland, at man skulle forsvare sig, også efter at tyskerne havde kapituleret. Den 5. maj betød derfor ikke nogen overgivelse på Ringsted Kaserne. Vagtbataljonen holdt forsat kasernen, hvad der bekymrede modstandsbevægelsen, da man kun vanskeligt kunne indsætte en tilstrækkelig stor styrke til at erobre kasernen i kamp. Der gik nogle dage, og modstandsbevægelsen havde fået ca. 1200 mand samlet i området, hvoraf dog mange kun var ganske let bevæbnet, men rygterne om det forstående angreb på kasernen og det håbløse i hele vagtbataljonens stilling gjorde alligevel indtryk, så vagtbataljonens chef indledte forhandlinger med en dansk officer om en overgivelse. Efter overgivelsen forefaldt der i øvrigt nogle episoder på kasernen, som ikke har været omtalt i medierne, da de ikke er særligt smigrende for modstandsbevægelsen. Disse episoder kendes fra flere lokale beboere, der har berettet om dem. I dagene efter overgivelsen førte modstandsfolkene således mange af fangerne fra hjælpekorpsene ud i kasernens gård, én efter en, skød en maskinpistolsalve af lige ved siden af dem, og førte dem derefter ind i en anden bygning. Derved opnåede man, at de tilbageblevne fanger efterhånden troede, at de alle blev skudt, en efter en, og denne psykiske terror drev modstandsfolkene i flere dage, indtil fangerne blev overladt i det nyopdukkede politis varetægt. Dette var ikke nogen særlig smuk episode, men den afspejler naturligvis bare den ophidsede stemning i foråret 1945. 2009-12-07T17:22:23Z 154 true 2009-12-07T18:17:04Z En cirkulær reference er en bidirektionel forbindelse mellem to objekter hvor hver instans har en reference til det andet objekt. I et "garbage collected" system er dette ikke noget problem. Begge objekter vil blive fjernet samtidigt når de ikke længere bliver brugt. Ved traversering af stakken holder processen selv øje med objekter som kun bliver refereret fra andre objekter. Hvis systemet er baseret på en tællefunktion pr referencer kan ingen af disse objekter blive elimineret fordi referencer tælleren aldrig kommer tilbage på 0. I et hybrid system hvor man både benytter optælling og "garbage collection" vil der opstå en leak fordi der ikke kan erkendes en cirkulær reference ud fra stakken. Der finde mange forskellige implementationer af gode og mindre gode javascript motere. Man kan se en oversigt på "Timeline of web browsers":http://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg Man kan fx lege lidt med den cirkulære reference på forskellige browser versioner for at se hvor store forskelle der faktisk findes. Det er ikke Javascript som programmeringssprog der er dårligt, men kun de Javascript fortolkere der benyttes. Desværre er det ofte op til den enkelte programmør at kende til de mange revisioner. Dette issue er vel i virkeligheden det svageste punkt ved Javascript. Dette er grunden til at de fleste vil bruge et Javascript bibliotek som er "Cross Browser Enable":http://en.wikipedia.org/wiki/Cross-browser robust. Disse bibliotker er naturligvis abstraktioner og når man arbejder i en "enterprisey":http://en.wikipedia.org/wiki/Enterprise_software virksomhed kommer der et tidspunkt hvor man må lave en helt specielt løsning. Uagtet om ideen er god eller dårlig. Derfor udvikler du selv to linjer Javascript og indsætter dem som en HOTFIX og merger dem direkte ind i produktion. Ups, vi har alle været der. <p>Her er et par eksempler på hvordan man kan ødelægge enhver browsers javascript motor. <ol> <li>Start din task manager så du kan se hvad din computer fortager sig! <li>Start din alletiders favorit browser! <li>Tryk på knapperne så hurtigt du kan! <li>Hvis du bruger en rigtig browser kan du følge CPU usage og Pagefile usage! <li>Prøv gerne forskellige typer og versioner af browserer. </ol> Jeg håber din produktionskode er mere kompleks og det vil være langt nemmere at lave disse operationer ved et uheld. Det er let at lave bugs når man ikke ved hvordan man laver bugs. Fixing bugs doesn't make the bugs go away! Eksemplet viser hvordan en cirkulær reference dannes mellem DOM objektet og Javascript objektet. <pre> // Circular references between JavaScript and DOM function circular_references_between_javaScript_and_dom() { var object; object=document.getElementById("element"); document.getElementById("element").expandoProperty=object; object.bigString=new Array(2000).join(new Array(2000).join("XXXXX")); } <div id="element"> <input type="button" value="circular_references" onclick="circular_references()"> </pre> I dette tilfælde vil mange gode browsere kunne håndtere denne function mens andre vil løbe tør for memory med det samme. Den væsentligste grund er den valgte memory model i browserens javascript motor. Hvis den er ren "garbage collected" som fx firefox 3 kan den nemt klare beslastningen. Måske vil den hænge lidt men ikke mere. IE4+ til IE6 har implementeret en hybrid memory model og kan derfor ikke gennemskue bidirektionelle (cirkulære) referencer. Jeg har ikke prøvet med Google Chrome's V8 javascript motor men efter som det er Lars Bak der har bygget den er jeg sikker på at den nemt kan klare den slags "hotspots". Hvis man har interesse både i virtuelle maskiner og Javascript har man nok bemærket at teamet i Århus er bemandet med en stor del af del mennesker fra det oprindelige hotspot team. JIT principperne sprang ud af Strongtalk, Smalltalk og programmeringssproget "Self":http://en.wikipedia.org/wiki/Self_(programming_language) Self er måske et af de vanskeligste programmeringssprog at skabe god bytecode for pga de dynamiske egenskaber. V8 motoren bruger mange af de samme teknikker som Java Hotspot for at få Javascript til at køre hurtigt. Fx bruger V8 "hidden classes":http://code.google.com/intl/da-DK/apis/v8/design.html til et forbedre "Fast Property Access" som er dynamisk addition af properties on runtime og derved øges kontrollen over opslaget af den valgte property betydeligt. Når Google Chrome OS også kommer på banen bliver alle disse optimeringer endnu bedre hvilket giver os brugere bedre performance og mindre at tænke på. Closures and circular references I den næste stump kode kaldes en closure fra Javascript der indeholder en reference til et DOM objekt. DOM elementet har til gengæld reference til Javasript objektet. Den resulterende cirkulære reference mellem javascript objekt og DOM objekt forårsager en memory leak. Eksemplet viser hvordan man addere et javascript objekt (closure) til DOM objektet. <pre> // Memory leak by closure function memory_leak_by_closure() { var parentDiv = document.createElement("div"); parentDiv.onclick=function(){ foo(); }; parentDiv.bigString = new Array(2000).join(new Array(2000).join("XXXXX")); } <input type="button" value="memory_leak_by_closure" onclick="memory_leak_by_closure()"> </pre> Closures er en af de mest kraftfulde funktioner i Javascript men det kan være svært at forstå dem. De er nemme at konstruere, selv ved et uheld. Deres eksistens er potentielt farlige for almindelige browsere og det er nødvendigt at forstår deres fulde omfang. Dette gælder ikke kun Javascript. Grunden til at jeg sidder og tager enterprisey "Your Moment of Zen" er at vores produktionskode fejler bigtime i IE Explorer version 7- Det er værd at huske at version 7 næsten version 6 med forbedre GC og version 6 næste er version 4.5 med lidt hotfix'es. Nuvel, i Javascript koden er konstrueret en timer som har til mål at løbe ud af en tidsramme inden nogle andre systemer timer ud, for at forhindre en "ufin" lukning for brugeren. Måske kan man forstille sig de vilkår vi som softwareudviklere arbejder under i kampen på at forbedrede interaktionen med brugerne. 2009-11-24T14:13:37Z 153 true 2009-11-24T14:28:03Z Hvad har Hercule Poirot, den belgiske mesterdetektiv, Sherlock Holmes, den engelske privatdetektiv, Inspector Hanaud fra det franske French Sûreté plus den altid selvsikre Chief Inspector Jacques Clouseau til fælles? Alle fire roder sig altid ud i de vildeste opklaringer af horrible forbrydelser. Hver især benytter de meget forskellige metoder ved deres opklaring. De er især gode til at drive en proces som går ud på at påvirker informationshastigheden ved at stresse alle implicerede parter. De arbejder altid med eller fra flere vinkler i parallelle forløb. De tolker oplysninger forskelligt på forskellige tidpunkter og undervejs frembringer de uensartede og forskellige delløsninger. Deres selvglæde kan til tider være overvældende og de tager enhver udfordringer personligt. Ofte besidder de en eksentrisk adfærd og kan forsvinde ind i dem dem selv i længere perioder. De isolere sig gerne ved at sætte andre standby mens de udføre deres opklaring. De har gennem deres resultater frembragt en tro i omgivelserne på at de er overlejende og deres bedrifter kan ser som rene kunstværker. De arbejder alle udfra en tese om at alt detektivarbejde udspringer af en ressource alene: rå tankekraft. Prøv at skifte billedet af detektiv ud med et billede af en softwareudvikler. Hvis alting stadig passer på en ansat har du helt sikkert fat i en stjerneressource. Du betaler sikkert en masse i løn men du får i tifold tilbage. Hvis du vælger at bruge de billgeste ressource til opklaring af forbrydelser eller til softwareudvikling må du selv tage konsekvenserne. "Cheap developers are most expensive!":http://www.frankvilhelmsen.com/posts/127-Cheap-developers-are-most-expensive 2009-11-12T19:58:34Z 152 true 2009-11-12T19:58:34Z Titlen på denne post kan måske forekomme misvisende eller ligefrem tvetydig idet den blander to paradigmer, to protokoller og to praktiske modeller. Men netop denne dualisme og tværgående egenskaber kan resultere i en styrke. Abstrakt handler dette blot om at se på services som resource. Denne post har absolut intet at gøre med REST men kun om brug og kombination af enkle og gode egenskaber omkring HTTP Applikations Protokollen. For at komme i gang vil jeg lige sige et par ord om Mocks. Mocks er objekter der indenholder en forventet reaktion. Man kunne fx mock'e information om "processen af købe en kop kaffe":http://www.frankvilhelmsen.com/posts/33-Caf-shop i nogle trin uden af kende hele den samlede proces til bunds. På den måde ville kaffe tørstige sjæle kunne benytte cafe-service'en ved at bestille forskellige type af kaffe. Endda før kaffebaren er helt færdig. En Stub derimod ville i samme senarie blot returnere den samme kedelige kop kaffe hvergang uden nogen hensyntagen til modtageren. Hvad har kaffe med SOAP at gøre? Jo, jeg har modtaget en række løstformulererede krav til en SOAP service der kan erstatte en ESB. Kravende indeholder ord som enkelhed, robusthed og fleksibel. Sjovt nok hænger de egenskaber ikke naturligt sammen med de flestes opfattelse af SOAP og WS-. Jeg må blankt indrømme at jeg normalt løber min vej når talen kommer ind på SOA, SOAP og WS- "dødsstjerne teknoliger":http://www.frankvilhelmsen.com/posts/56-WS-Death-Star Men på samme måde som en skatterevisor til fest er min interesse altid på ca. 50 procent når noget er dukket op på området. Min holdning er blot at jeg kan tilføre mere værdi med andre metoder. Som udgangspunkt enig med med folkene bag "http://soa-manifesto.org":http://soa-manifesto.org om at SOA som arkitektur er en god ting og SOAP som protokol er noget markværk. Derfor vil jeg bryde alle (mine) principper og forsøge at angribe med ord som "Brute Force" og "WS-* Duck-Typing":http://www.frankvilhelmsen.com/posts/21-WS-Duck-typing Når man operaer med "Brute Force!" metoden er det næsten det samme bare med mere traditionelle værktøjer. Paul Sandoz fra SUN, som i øvrigt sidder i ekspertgrupperne JSR-154, JSR-224, JSR-311 har på en konference fortalt mig at man kan se på enhver SOAP besked som en resource. Og hvis ikke er der et design issue. Derfor vil jeg i dette forsøge at udstille et SOAP endpoint som en resource. Eller rettere, forbrugeren vil ikke opdage en forskel men blot kalde en service som sædvandeligt men for service udbyderen er der en væsenlig forskel. Klienten kalder med JSR-244 (JAX-WS) og serveren svare med JSR-311(JAX-RS). Med denne metode kan jeg overholde WS-* Ducktyping principperne og på samme tid arbejde highlevel mod HTTP protokollen uden de afledte effekter som codeeksplosion, classeksplosion interoperability og de andre aspekter der bunder i en tæt bundet SOAP protokol. SOAP definere sin egne protokol ovenpå HTTP protokollen og den abstraktion er vigtig set ud fra det perspektiv at man kan skifte transportlag til JMS eller noget andet. Men hvis man kun bruger HTTP som transport er det naturligvis kun en abstraktion der altid vil ende med "Law of leaking abstractions by Joel Spolsky":http://www.joelonsoftware.com/articles/LeakyAbstractions.html I denne context er Highlevel er lig med det "Uniforme Interface":http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm fra REST der tilbyder ensartede operationer på tværs af alle komponenter. Det er en kæmpe fordel frem for SOAP protokollen hvor hver WSDL definere et specifikt service interface. Med SOAP arbejder man med et lag ovenpå http protokollen mens man med REST arbejder med protokollerne og derfor siges det at abstraktionen mellem de to fremgangsmåder er på forskellige plan. Resoucen <pre> @Path("/Customer") public class CustomerResource { @POST @Consumes("appliction/soap-xml;charset=UTF-8") @Produces("appliction/soap-xml;charset=UTF-8") public String method(String body) { ... } } </pre> Denne resource klasse repræsentere en kunde. Path symbolet viser den relative URI til ressourcen. For at kunne attakere denne metode som en resource kan man fx sende et HTTP (@POST) med den rette content-type (@Consumes) i HTTP headeren. Metoden modtager en SOAP besked og returnere en SOAP (@Produces) besked. Hvordan beskeden teknisk behandles i metoden er ligegyldigt. For en brugern af denne SOAP service er det transparent at der benyttes ressource. Ved en fejl i metoden returenes naturligvis en "optional SOAP Fault element". Det er muligt at skabe en @Singelton instans ved at tilføre en annotation. Således finder der kun den samme ressource for alle consumere og det er muligt at udnytte den feature på flere måder end jeg kan komme på her. Ved Mocking er det selvvalgt en naturlig ting idet man kan ændre indhold på ressource output i køretid. Under normale forhold vil vi naturligvis stræbe efter stateless resourcer for at bibeholde egenskaber som skalerbarhed, samtidighed osv. Indtil nu er der kun brugt annoteringer fra API'et på en POJO Java klasse men det er tid at vælge hvilken implementation der skal bruges. Jeg bruger JAX-RS API og SUN's Jersey 1.1 reference implementation fordi den er langt den mindste jeg kender og har en opstartstid jeg kan udholde. Ikke et ond ord om Apache CXF der har suppport for JAX-RS i sin JAX-WS implementation. Registrering og brug af denne resource kan ske på flere måder, både standalone og i container. Jersey har en super cool scanner der selv register klasser efter annotationer og binder dem til det rigtige endpoint der dekoreres dels i Web.xml og dels direkte i annotationer. Det bliver ikke bedre end det. :-) En af de stærke sider ved Jersey er deres client interface. Kan ikke lade være at vise en stumt kode der simulere et SOAP WS kald mod en ESB eller whatever du nu har. Læg især mærke til den dejligt "Java Fluent Interface":http://www.frankvilhelmsen.com/posts/111-Fluent-interface måde man opbygger sin request på, næsten i DSL stil. Mange forskellige teknologier har adopteret og overholder HTTP, Servlets og JAX-WS. Det betyder at man kan bruge en ressource som et endpoint for alle komponenter der taler samme sprog. De vil aldrig vide hvad der ramte dem. På samme måde kan man bruge klientdelen til at invokere fx ESP endpoints. Det er faktisk sjovt. <pre> Client client = Client.create(); WebResource endpoint = client.resource(uri); ClientResponse response = endpoint. type("application/soap+xml;charset=utf-8"). accept("application/soap+xml;charset=utf-8"). post(ClientResponse.class, xml); int status = response.getStatus(); String s = response.getEntity(String.class); </pre> Jersey og hele REST tankegange er baseret tæt omkring HTTP Applikations Protokollen. Man er "ON The Web" eller en del af "The Semantic Web":http://en.wikipedia.org/wiki/Semantic_Web og ens applikation kan understøtte "Linkede Data":http://en.wikipedia.org/wiki/Linked_Data Med disse tanker og metoder smelter applikationen sammen med internettet. Den forrige resource "/resource/Customer" vil blive ramt af SOAP klienter. Men jeg kan ikke dy mig for at lade den samme resource blive brugt af simpelt AJAX (Asynchronous JavaScript and XML). Med AJAX kan man fra Javascript kommunikere med en server gennem XMLHttpRequest objektet uden at reload HTML siden. En anden ting er, at man kan kontroller stort set alle de ekstra header informationer som overføres til serveren hvilkent betyder at man kan rammer en resource fx med en bestemt content-type. <pre> new Ajax.Request("/resource/Customer", { method:'GET', asynchronous:true, requestHeaders: ['Content-Type', 'text/html;charset=UTF-8'], onSuccess: function(transport){ $('message').update(transport.responseText); }, onFailure: function(transport){ $('message').update(transport.responseText); } }); </pre> Denne metode laver en GET på ressourcen Custormer og forventer at modtage en repræsentation af dennes response i form af HTML. Hvis man skal bruge JSON skal man kun ændre content-type til "applikation/JSON". Hvis man i stedet vil POST'e et ændret indhold ind i ressourcen kan man bruge denne form: <pre> new Ajax.Request("/resource/Customer", { method:'POST', asynchronous:true, requestHeaders: ['Content-Type', 'appliction/xml;charset=UTF-8'], postBody: $F('body'), onSuccess: function(transport){ ... </pre> Dette POST bindes sammen med ressourcen gennem POST med content-type 'appliction/xml;charset=UTF-8' og forventer at modtage en Customer i XML format som input i HTTP body. Hvis ressourcen ikke har implementeret denne indgang svares med "Status Code 415 Unsupported Media Type":http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Fik jeg så hvad jeg kom efter? Ja, det synes jeg. Ved at mappe ressource til simulering af SOAP endpoints og Servlets side om side fik jeg en cross platform, cross service implementation og mere clean snitflade uden de logiske layer som jeg hader. Håber bare at mine kravsstiller ikke vil skifte transport metode. Anyways, det sker nok alligevel aldrig. At efterleve DuckTyping principperne er en fornøjelse og jeg har virkelig hygget mig undervejs. Tak til Paul Sandoz for at starte den ide i mit hoved i 2007. 2009-11-06T17:28:12Z 151 true 2009-11-06T17:32:11Z Anne Thomas-Manes fra Burton Group introducerede den "Thing Oriented Architecture" (TOA) arkitektur til stor glæde for de få ægte RESTafarians der var mødt op i en eller pakkend sal på året Jaoo. TOA er lig med "The Web is REST and REST is the Web. Der var måske ikke så meget nyt på Jaoo i år men der var meget konsolidering af de gamle dyder lige fra Haskell programmering over Lean udviklingsmetodiker til hvordan man sælger REST opad i sin organisation. Scott Davis redede min første dag på Jaoo med hans tale om “Tale of Slippy Map”. Dagens ørige program gav ikke den store reaktion men der var et par gode solide præsentationer. Min gamle ven Kim Dalsgaard var trackhost på "Web Oriented Data" som til dels fangede min interesse sammen "Browser as a platform". Disse to track passer rigtig godt sammen de trak ikke ret mange mennesker. Min interesse er baseret på at jeg tror på løskoblet interconnected data over http protokollen. Barry Boehm tale om "Scaling Up Agility" var en lang reklame for agile metodikker og metoder og han løb gennem usecases hvor han beviser hvor langt man kan komme med lean udvikling. Eneste krav er at man skal havde ansat de beste adrætte resource og gøre forretningen klar til iterativ informations flow hvor adoption af forandring fylder langt mere end gammel planer og rutine processer. Den eneste sætning som jeg virkelig kan huske fra denne lidt, trætte taler, er hans statement om at man altid skal passe på når man får tildelt en fuldtidsansat forretningspecielist, måske er han den eneste de i virkeligheden kunne undvære? Og nej, din Compiler Driven Testing (CDT) kan ikke bruge som test tool. Emil Eifrem leveredere en overbevisende introduktion til Graf databasen Neo4j. Det er ikke ligefrem første gang jeg høre denne præsentation men Emil har udviklet en god sans for kunsten at tale og det er en fornøjelse at være vidne til. Især bifalder jeg hans annalogi om den kognitive tankegang fra et Whiteboard til den grafforbundende verden hvor relationer og properties er en naturlig del af data i kaotiske former. I vore dage kan en medarbejder have op til 10 jobtitler. Hvordan vil du repræsentere det? Addere en ny kolonne for hver title? nej vel, din database skal omstruktureres men du i en grafdatabase blot lægger flere properties på den node der repræsentere din medarbejder. Måske arbejder du et sted hvor alting er veddefineret og statisk og så kan du roligt forsætte med RDBMS og ORM. Michael Feathers gav en gennemrand af Clean Functions. Han præsenterede en del crap kode for at vi skulle kunne få invokeret vores logik til at finde nogle gode størrelser mht antal kodelinjer, klasser og sammenhænge mellem opgaver og opdeling. Der findes en flere teknikker og principper bag konceptet "clean code". Personligt er det mange år siden jeg har set nogle af dem i brug i Java verden men de er langt mere udbredt i letvægtkredse. Brian McBride viser hvordan " Linkend Open Data" og "Semantic Web" hænger sammen. Han er klar fortaler for "Jena Open Source" for at offentliggøre data på internettet og hvordan disse data kan udnyttes. Han repetere kort en række principper standarder for Linked Open Data og hvordan man konsumering data til og fra andre formater som fx RDF, RDF, XML, JSON samt SPARQL Query Language. Jeg synes dette område er enormt spændende men jeg må indrømme at jeg lukkede øjene lidt at tiden. Scott Davis nærmest råbte dages bedste tale i gang mens mine øjne stod på vid gab. "The Tale of Slippy Map" Kort fortalt er det historien om google maps og hvordan man skaber oplevelsen af den fede applikation. Hemmeligheden er at man bevæger sig på en pane som er noget større end det synlige område og der preloades mens man kigger på det synlige. Jeg høre til den meget lille gruppe af mennesker som helst vil være helt tæt på de oprindelige protokoller og derfor at fantastisk at se hvor godt google maps er designet. I øvrigt er det den direkte medvirkende årsag til den kæmpe susces som maps har fået. Maps applikationen består af en stateless server del der levere koordinater og billeder i 256 x 256 pix. Klient delen er stateful og består HTML/DIV med ca. 150 linjer af Javascript og indlejeret stylesheet. Så enkelt at det er grineren. Oplevelsen er meget lig desktop applikation men er velorganiseret snyd for “the brokken web”. Mr. Scott får også en pædagogisk topkarakter. Hans præsentation er meget velovervejet men ikke tilpasset til europæiske forhold. Mange selvbestaltede supereksterne følte sig helt sikkert forulempet og talt ned til. Højst kontroversielt. En sjovt ting jeg har tænkt over i dag er at mange har brugt sætningen “schema-free” adskillige gange i løbet af de første taler. Det glæder mig meget men det gør øjensynlig mange andre en del nervøse. I sessionen med Linked data var mange spørgsmål rettet mod det faktum at man ikke har kontrol over data sourcen. Tja, men sådan er der jo så meget og endnu et eksemplet på at man kan kende svaret uden at kunne spørgsmålet. Anden dage på Jaoo 2009 var rettet mod REST! Simon Peyton-Jones lægger for med en fantastiske tale om Haskell. Simon forklare om type klasser som de fungere i haskell, ikke at forveksle med Java og .NET klasser. Haskell er et akademisk funktionelt sprog der også bruges til få kommercielle applikationer. Et af Haskell’s mest karakteristiske kendetegn er dens type system, de såkaldte “type klasser”. Type klasser tjener samme formål, at de klasser af mainstream-OO-sprog men på en anden måde. Denne tale begynder med forklare lidt om “The Birth of Language” med først een “geek” bruger, derpå et par stykker mere, og måske knækker kurven og sproget et bliver populært udover tekniske venner og måske adopteret af den brede masse. Simon er veloplagt og stormer gennem noget kode og beder alle som ikke forstår detaljerne række armen op. Der er måske 500 mennesker i den store sal men ikke en røre sig. Publikum rør sig heller ikke der hvor Simon presser en test ind i en funktion der ikke lader sig gøre. Han skure blot ud over salen, rækker armen op og siger NU. Rachel Reinitz var en positiv overraskelse. Hun talte om "Extending the Reach of your SOAwith REST". Rachel er IBM Distinguished Engineer i WebSphere Services. Hun har bygget en stor del af IBM’s uddannelse på SOA, Enterprise Service Bus, og Web Services. Rachel er top ESB ekspert. Hun vil ikke reklamere for IBM men: "There are in fact good reasons to use messaging beyond IBM making a lot of money with MQ". Rachel riser hele web2.0 verden op som IBM ser kagen med Service, not software(SaaS), community added value, semple adgang til data osv.. Der er særlige grunde til at vælge SOA og webservices fremfor REST.. Lad mig være ærlig, der er ved at gå salg i den og hun opfinder termen RestfulSOA. Hvis hun viste hvem der skulle tale efter hende ville hun måske vægle sine ord med lidt større omhu. Anne Thomas-Manes fra Burton Group er en kvinde man lader tale ud.. Både ved cafeen og når hun indtager scenen. Anne er en af NetworkWorld’s "50 mest magtfulde mennesker og en respekteret ekspert i distribueret computerteknologi. Anne har deltaget i udviklingen af standarder som W3C, OASIS, JCP, UDDI.org, og WS-I. Hvordan sælger man REST i sin organisation? Forretningen tænker på afkast, ikke på hvilken underlige teknik ting der tales om i udvikling. Der er ingen reel fokus på teknologien. Elegance dosen’t sell. Hvis du har en god ide kan du sælge den til forretningen sammen med indtjenings prospekt og risici beregninger. REST er præcis så sikker som hvilken som helst anden ting der sendes over http protokollen siger hun. QoS hænger ikke sammen med om der er en envelope i den besked du sender men mere på skalerbarhed og pålideligehed. Med hensyn til at startop projekter mener hun ikke at det kan lade sig gøre uden en ægte RESTafarian som mentor. Programmeringmodellen bag REST og det at se verden som resource er meget svær at forstå i detaljer, slet ikke hvis man kommer fra en OO verden. Flere af de hårdeste RESTafarians udtaler at det kan tage op til frem 5 at forstå alle elementer af REST ROA WOA. REST er en arkitektonisk stil orienteret til at formidle oplysninger om ting. REST er en form for "Thing’ish Oriented Architecture". Ian Robinson er Principal Consultant hos ThoughtWorks og forklare hvordan “hybermedia” fungere i et restfuldt miljø. At han bruger Dungeons & Dragons spilscenarie gør det kun en smule mere tosset. Pointen er at spiltilstanden hverken er hos serveren eller klienten men i linkage'en mellem de to. Dette princip kaldes også HATEOAS(Hypermedia As the Engine of Application State, REST koncept). Man har kun et entry point til spillet og efter en GET til den resource får man de næste muligheder der findes i spillet lige nu. Hypermedia applikationer råde bod på SOA-visionen om et distribueret system baseret på evolutionære let sammensatte program protokoller Stefan Tilkov er medstifter og chef konsulent ved innoQ, et teknologi konsulentfirma med kontorer i Tyskland og Schweiz. Stefan har været involveret i udformningen af store, distribuerede systemer i mere end et årti og anvender en bred vifte af teknologier og værktøjer, der spænder fra C++ og CORBA over J2EE/Java EE og Web Services til at Ruby on Rails. Tikov er en mand der tør sige nogle ting og jeg ser altid hans taler hvis det kan lade sig gøre. I dag handler hans tale kun om at udnytte de mange muligheder for ægte caching der implicit er gemt i http protokollen. Man kan være mere eller mindre enig i hans synspunkter og personlige holdninger men hvor er det skønt at han virkelig kan bitche over teknologere som ESB, SOA, SOAP etc. Sikker derfor jeg kan li ham? En af de mest fremtrædende fordele ved at bygge services ved hjælp af RESTful HTTP er støtten til caching og man kan uden videre bruge de sande byggesten fra internettet uden at tænke på ekstra omkostninger til infrastruktur eller software. REST er en blot at udnytte Internette på den måde det er tiltænkt. Tikov har en interessant vinkel på hvor man ligger sit REST snit i en traditionel layed applikation. Grænsen skal ligge så tæt på klienten som overhoved muligt. Hvorfor? Kun klienten har tilstand og resten af middelvaren skal være stateless. Cool logik. Mange mennesker sad og så helt blanke ud. Jeg gætter på at man skal ha lavet et par apps i den stil for det falder nemt at tale om. Dagens REST track på Jaoo var fortrindeligt sammensat af Tikov. Gennem dagen var dette spor velbesøgt og adoptionskurven må mindst være breakeven. Flere personer jeg talte med gav udtryk for at de nærmest er eksperter i REST mens deres mangelene forståelse åbenlys og det gør mig lidt urolig for REST fremtiden. Det der kan ødelægge udbredelser af REST til masserne er dårlig rådgivning og ringer applikationer som ikke møder deres krav. Det gode ved hele er at jeg må været nået langt i min personlige erfaring med REST siden jeg kan så tydeligt kan se rigtig og forkert. Dagen gav mig ikke noget ny men jeg er glad for en god portion validering. :-) Der var ikke en generelt gennemgang af REST og det var måske en fejl. Kun specielle emner om REST såsom Hybermedie, HTTP Cachaing, hvordan man ikke laver et nyt RPC kald over XML og ikke mindst om hvordan man promovere REST videre ud og op i virksomheden. Efter min mening kommer den vigtigste pointe Anne Thomas-Manes, Burton Group. Du kan vælge REST på lige fod med andre teknologere men husk at allokere en specialist som mentor. Jeg sad og jokede med en vældig flink fyr som lige var kommet fra lufthaven og var en del træt. Vi var helt enige om Tikov's jokes om SOA var af en meget ringe karakter. :-) Cameron Purdy, var manden jeg jokede med. Manden som skabte og solgte Tangosol til Oracle. Han skulle prøvet at tage et kig bagud for at se om vi kan forudsige hvad der sker i de næste år fremover. Hvad har vi lært og hvordan kan vi drage fordel at det. Dette var et retrospektiv tilbageblik på hvorfor C++ blev glemt over natten da Java kom ind på scenen. Det sjove er at når man nu ser på Java og alle de ting som sker med fx Cloud Computing, Multi Core hardware og andet kan man nemt forstille sig at nye ting klart overhalder Java over en nat. Cameron pointere at man umuligt kan adoptere Agile udviklings metodik hvis det tager flere dage at lave den mindste forandring. Han bitcher også over Java evner til at lave pauser ved GC, et enormt memory forbrug, en sindsyg ringe startop tid. Faktisk mange af de samme ting som gjorde Java C++ overlegen i sin tid, nu er de ting en hæmsko. C++ var fantastisk i sin tid men hvor mange biblioteker finders der lige til C++? Nej vel! Grunden er den simple at man havde automatisk memory håndterring. I Java derimod er vi skide ligeglade med memory forbrug, vi smider bare det hele væk og det var også godt nok i en tid i de næste år vil det blive en stigende forhindring. Det var min mening at følge Cloud tracket i dag men en særlig omstændighed gjorde at det blev meget anderledes. See "Attending Conferences":/posts/116-Attending-conferences Kevlin Henney var min redning. Og hvilken en. Filuren var fyldt til bristepunktet og med god grund. Kevlin er en super behagelig taler med klare synspunkter om udviklings metodik. Han er fx ikke særlig imponeret af hele den agile bevægelse. I disse år er det som man skal udvikle efter agile principper for at cool. SCRUM fx ligger meget vægt på proriterede backlog emner mens det man i mange tilfælde burde fokusere på var at navigere uden om de væsentlige risicifaktorer. Det ligger implicit i mange agile metoder at design er behandlet som en kontinuerlig aktivitet men måske er design kun en af mange faser i udviklingen. Udvikling er også prototyper til TDD, arkitektur, refactoring og retrospektiv betragtninger med fortløbende feedback. Men denne erkendelse er ikke nok til at kommunikere hvordan et design bliver dannet og udvikler sig. Design fra kode fragmenter til store systemer kan forudses og diskuteret gennem fortællinger på lige måde som med programmerings episoder og pattern historier. Kevlin har også meget interessante vinkler på softwaretesting. Han giver nogle pragtfulde eksempler og jeg giver ham ret i at mange laver de mest stupide unittests. And hey,camel case doesn't scale over 40 chars. :-) Michael Nygard har senest skrevet "Release It! Design and Deploy Production-Ready Software", en bog, der indenholder mange af hans tanker om udvikling af software som kan overlever i den virkelige verden. Michael bestræber sig på at lindre den daglige smerte for den enkelte udvikler. Han har brugt år på at finde ud af hvad det betyder at være en professionel programmør der bekymrer sig om kunst, kvalitet og håndværk. Han kan ikke fordrage apati eller spildt potentiale. Han taler til udviklere men også i høj grad til management og andre der bevæger sig i periferien af udviklings miljøet. I denne tale fokusere Michael på tenologi, planlægning og risk management. Når man skære alt bullshitet væk er: "projects are experiments". Når et firma planlægger sin fremtid er det altid i gode solide blokke. fx næste år skal vi forbedre vores indtjening med 2.5 procent, ikke 100 procent og ikke -100 procent. Faktum er at alle virksomheder går fallit uden at det er planlagt. "requirements are ignorance", Denne bemærkning omhandler ikke at du som person er arrogant men blot at du er usikker med det samme du ikke ved noget med 100 procent sikkerhed. Det betyder at du kun kan gætte rigtigt eller forkert. Men det viser sig at man kan gætte 90 procent rigtig uden at vide noget med sikkerhed. Tænk på hvornår Johannes Gutenberg tykkede sin første bibel? Det ved du måske ikke, men du var at det var før år 1800 og efter år 1200. Hvis man samler 5 personer vil de med 93 procent sikkerhed repræsentere gennemsnitshøjten i verden. Du skal i hverfald aldrig sige: det har jeg ingen ide om! "Guessing is Truth". Mit gæt er at jeg så snart som muligt skal høre Michael tale igen! Jaoo var for mig endnu en god oplevelse med bravende gode talere. Kun en enkelt gang måtte jeg forlade en session og ty til min tidligere post om at hvordan man begår sig til konferencer. Alt i alt endnu en vellykket Jaoo med en grad af validering af allerede adoptere teknologer og konsolidering af allerede velkende processer. Husk at konferencen først er slut når alle omkring dig ved hvad der forgik. Som professionel udvikler stiller jeg mig det samme spørgsmål efter hver konference: Er der noget jeg vil gøre anderledes i mit job på baggrund af mine oplevelser på Jaoo? Ja, jeg vil intensivere min udbredelse af historien om dødsstjernen og rebelflåden. Konceptet med et system falder mere og mere til jorden og vi taler mere og mere om at publicere data og linke dem sammen på forunderlig vis. Koplingerne mellem de enkelte systemdele benytter sig mere og mere at allerede erhverve og gennemprøvet software som fx routere og proxy servere. Oh hey, for sidste gang, klienttilstand findes i klientprogrammet. ikke på serveren. "Small Things Loosely Joined Written Fast":/posts/122-Small-Things-Loosely-Joined-Written-Fast 2009-10-06T22:14:08Z 149 true 2009-10-08T11:43:36Z Jeg skal udstille en SOAP WebService fra et et lagacy system. Det er en forholdsvis triviel proces med enkelte retninglinjer men bliver ofte til noget overengineered markværk. Min tanke er at det må kunne gøres på en let og clean måde. Efter min mening er begrebet service i forbindelse med IT er desværre druknet i forretningprocesser og total mangle på vision. Mine forbehold er enkle! Jeg gider ikke skrive en WSDL fil og jeg vil helst ikke compilere tusindvis af filer flere måneder før jeg kender kravene til applikationen. Under normale forhold ville jeg være djævlens advokat når det gælder SOA, SOAP, Webservices og andre dødstjerne teknologer. Jeg vil have en service orienteret arkitektur med løs kobling og blød binding mellem komponenterne. Her er klasse med noget opdigtet funktionalitet. <pre> /** * Leagcy business rule */ public class Palindrome { public static boolean isPalindrome(String word) { int left = 0; // index of leftmost unchecked char int right = word.length() - 1; // index of the rightmost while (left < right) { // continue until they reach center if (word.charAt(left) != word.charAt(right)) { return false; // if chars are different, finished } left++; // move left index toward the center right--; // move right index toward the center } return true; // if finished, all chars were same } } </pre> Andrew S. Tanenbaum bog om distribuerede systemer dukker svagt op i min erindring når vi taler om server klient applikationer. Derfor føler jeg det er vigtigt at præcisere context. Det første perspektiv er fra leverandørens(supplier) synspunkt. Rigtig mange problemer opstår i forskellige opfattelse af distribuerede systemer og det kan være svært over tid at skele mellem hvad der er forbruger og leverandør i forskellige forretningsområder. Leverandør processer som har flere afhængigheder fra andre under-leverandører som agere forbruger skal snart omskrives. Første step er at fremstille en service. Jeg kalder processen for BusinessService men i teorien kunne det være hvilken slags forretnings regel eller dataplukning. For at spare taste slag bruger jeg Groovy til service interface. Det statiske metode kald til legacy kassen er verdens værste smutter men sådan er det jo med legacy. <pre> class BusinessService { boolean isPalindrome(String word) { Palindrome.isPalindrome(word) } } </pre> Dette service objekt skal nu omformes til et endpoint. Denne gang bruger jeg groovyWS til at tale SOAP. Bemærk navne-sammenfald i konstruktionen der invokere groovy's dynamiske newinstance metode. Objektet kalder jeg for BusinessServiceEndpoint. Grunden er at jeg forstår at en port på en maskine er et endpoint mens mange forstår alt muligt andet. Måske er jeg for logisk? Logisk er det også at man skal passe meget på sin service stak og ikke mindst rækkefølgen i classpath. <pre> new WSServer("BusinessService", "http://localhost:6900/BusinessService").start() </pre> Det var serverens endpoint. WSDL filen specificere alle nødvendige forhold omkring hvilken muligheder man som WS forbruger kan opnå. Man kan se WSDL filen live på url: http://localhost:6900/BusinessService?wsdl Nu er det tid til at tage det store skridt til højre for at lege forbruger(consumer) af webservice. Som klient modtager jeg en url der peger på et service endpoint. Dette bør være den eneste kobling mellem leverandør og forbruger. Hvis man har brug for mere som fx, et kompilerer jar arkiv, eller andre artifakter er man bundet for hårdt sammen. leverandøren har det med at ændre i sin kontrakt og fjerne dermed grundlaget for alle forbrugere. Løsningen er enkelt, en leverandør push'er successivt alle ændringer til sine forbruger. Eneste forhindring er at man som udstiller af services skal vide hvor mange forbruger man har hvilket totalt ødelægger service tanken. Og Tanenbaum vender sig. * SOA er som et autovaskeanlæg, du kan ikke bruge det uden at vide alt. I morgen er vaskehallen fx kun 1m bred men heldigvis ringer tankpasseren rundt til alle med ændringer. GroovyWS har en fin klient til Webservices. Klienten skal blot have endpoint og en classloader. Instansen kalder jeg proxy fordi den illustrere det objekt som ligger hos udbyderen. Når man kalder initalize generes alle de nødvendige stubs for dig og man kan derefter direkte invokere metoder gennem proxy'en. I dette tilfælde kalder jeg isPalindrome med argumentet otto. <pre> def proxy = new WSClient("http://localhost:6900/BusinessService?wsdl", this.class.classLoader) proxy.initialize() println proxy.isPalindrome("otto") # true </pre> Det fede er naturligvis at der foregår en masse nedeunder som jeg ikke engang gider ta mig af. Men dette var ret nemt fordi jeg jo blot bruger samme teknologi på begge sider af ledningen. Lad og prøve at skifte hele servicestakken på forbruger siden med noget helt andet. I teorien vil leverandøren gerne ha at så mange så muligt benytter de udstillede services fra så mange platforme som muligt. Dette er en af de gode grunde til at man ikke skal lade sine EA kommer med alt for mange gode ideer når de udvikler meget komplekset WSDL'er. Sikkerhed består ikke kun af kompleksitet. Ruby har en 'soap/wsdlDriver' indbygget man kan bruge til at tilgå soap endpoints. Syntakstisk minder det noget om groovyWS og man operere også direkte på en proxy uden at tænke på at afkode WSDL filen manuelt. Evt kan man se metodernavnen i browseren for derefter at invokere dem. Bemærk at argumentet i ruby er en hash fremfor en typed parameter. Hvis servicestakken ændres kan man risikere at skulle bruge andre navne end arg0, arg1 osv. <pre> require 'soap/wsdlDriver' proxy = SOAP::WSDLDriverFactory.new("http://localhost:6900/BusinessService?wsdl") proxy.create_rpc_driver puts proxy.isPalindrome("arg0" => "jruby-yburj") </pre> Indtil nu har vi kun kørt med SOAP version 1.1. Måske er det tid at udstille en soap service i version 1.2. En ESB kan nemt udstille services af begge versioner og det ville være ret cool fremfor at en central admin bestemmer at der kun findes SOAP version 1.2. Ved en sådan fremgangsmåde bliver man ramt af en alt for kraftig binding mellem endpoints og services og har voldsomme implikationer for alle forbrugerne. GroovyWS er ikke klar til soap version 1.2 ud af boksen og det kræver for mange omgåelser så det er tid at skifte til Metro 2.0 for at udstille vores næste service som sjovt nok også er palindrome. Legacy klassen er stadig den samme men service wrapperen er udskifte til en POJO java klasse med JAXB annotationer. Service endpoint interface(SEI). For ethvert defineret interface i WSDL filen kan man generer en SEI. Fra et Java perspektiv kan man sige at wsdl:porttype mapper lige over til en implementation med annotationen @webservice hvor hver operation defineret i wsdl mapper til en metode i SEI. Bemærk at SOAP 1.2 support is added til JAX-WS 2.2 <pre> /** SOAP 1.2 WS service */ @WebService @BindingType(value = "http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/") public class PalindromeService { @WebMethod public boolean isPalindrome(String word) throws PalindromeServiceException { if (word == null || word.length() < 2) { throw new PalindromeServiceException("No word added!", "Must have a word with length over 2 chars."); } return Palindrome.isPalindrome(word); } } </pre> Nu er den samme legacy kode altså dækket af flere service wrapper med forskellige egenskaber. Jeg kan bedst li Java klasse uden "det tredie sprog" annotationer men okey, det er bedre en rå xml konfiguration. Her er tilføjet en eksplicit exception og et par valideringsregler. Nu kan vi gå direkte til endpoint som også er en Java klasse som kalder et JAX-WS endpoint og publicer en ny service. <pre> public class PalindromeServiceEndpoint { public static void main(String[] args) throws Exception { Endpoint.publish("http://localhost:8080/business/ispalindrome", new PalindromeService()); } } </pre> Grunden til at dette er i Java fremfor Groovy er at jeg ikke vil lade JAXB binde superclass metoder. En groovy klasse har et metaClass interface og det kan JAXB ikke håndter. Dette kan afhjælpes ved brug af af en ekstra annotation. Det virker dog ikke særligt robust på den nye metro distribution og jeg synes det forurener koden at man skal fortælle hvilken objekter der er root. Nuvel, nu findes en service udbyder som har publiseret en service i SOAP version 1.2. Men behøver man ikke vide om den. Vel? Det er nu vigtig at pointere at jeg har kaldt denne post "dynamic" fordi jeg ikke vil tilgå services med en binær afhængighed. Det er ikke hensigten at modtage en *jar fil fra serviceudbyderen som jeg skal lægge i min classpath og kode imod fordi jeg ikke vil rammes af namespace ændringer overalt i min kodebase når næste version kommer. Mit udgangspunkt er at alle i teorien kan benytte denne service ligegyldigt hvilken platform og hvilken teknologi de fortrækker. Jeg vil betragte denne service(endpoint) som et sted at starte og jeg håber at wsdl filen fortæller mig om de næste skridt jeg kan tage. Jeg høre til den nysgerrige type og vil forsøge at forbruge denne service med med udgangspunkt i SOAP beskeden selv, altså "the Envelope". I konvolutten ligger information om sikkerhed, transaktioner og andre, for mig, ligegyldige ting. Klient koden til en soap 1.2 besked med standart Java 1.6 indbygende features. <pre> QName serviceName = new QName(service_namespace, service_name); QName servicePort = new QName(service_namespace, service_port); // Create a service and add at least one port to it. Service service = Service.create(serviceName); service.addPort(servicePort, SOAPBinding.SOAP12HTTP_BINDING, service_endpoint); // Create a Dispatch instance from a service. Dispatch<SOAPMessage> dispatch = service.createDispatch(servicePort, SOAPMessage.class, Service.Mode.MESSAGE); // compose a request message MessageFactory mf = MessageFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL); // Create a message with the SOAPPART. SOAPMessage request = mf.createMessage(); SOAPPart part = request.getSOAPPart(); // Obtain the SOAPEnvelope and header and body elements. SOAPEnvelope env = part.getEnvelope(); SOAPHeader header = env.getHeader(); SOAPBody body = env.getBody(); // Construct the message payload, ant binding type value SOAPElement operation = body.addChildElement(business_method, "ns1", service_namespace); SOAPElement value = operation.addChildElement("arg0"); value.addTextNode(business_args); request.saveChanges(); // Invoke the service endpoint. SOAPMessage o = dispatch.invoke(request); // Get reply content Source sc = o.getSOAPPart().getContent(); </pre> I dette eksempel var en IDE nødvendig både fordi der er alt for meget kode og fordi JAXB bibliotekerne i denne EA version er noget forskellige fra den tidligere. Et par ting der er værd at lægge mærke til: Jeg må bygge et soap xml request på Java's kedelige set get'er metodik. Ydermere, tiltrods for at jeg selv har konstrueret denne service må jeg ind i wsdl filer for at finde navnet hvori input består, isPalindrome(String word) er altså blevet til en række af inputparameter med fortløbende arg0, arg1 osv. Væk er det fine proxy objekt med stub'ens metode navne og hele interaktionen er alt for lowlevel for min smag. Og man bliver nu nødt til at bruge en Transformer for at MOF'e til et model objekt. Klient koden til en soap 1.2 besked med Java 1.6 + Apache CXF. <pre> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance(); URL serviceEnpoint = new URL(service_endpoint); QName serviceName = new QName(service_namespace, service_name); QName servicePort = new QName(service_namespace, service_port); // create proxy and genered classes from wsdl Client proxy = dcf.createClient(serviceEnpoint, serviceName, Thread.currentThread().getContextClassLoader(), servicePort); // call method on proxy Object[] res = proxy.invoke(business_method, business_args); // use the new genered class in this classloader Object palindrome = Thread.currentThread().getContextClassLoader().loadClass(business_class).newInstance(); p(palindrome.getClass()); p(palindrome.getClass().getMethods() ); </pre> Ahhh, noget mindre kode men stadig langt mere verbose en klienten med groovyWS. Men jeg fik min dynamiske proxy som svare til objektet på den anden side og det er muligt at kalde metoder direkte på proxy objektet. Hvor kom klient objektet fra? Tja de blev generet af wsgen udfra wsdl filen på samme måde som man ville gøre på normal vis blot runtime. Ved den traditionelle metoder vil model være dekoreret med referacer fra wsgen på compiletidspunkt hvor man med denne metoder først kender service objekterne runtime, dvs at ens model er uden reference til de generede service objekter. Hvilket påpege et helt nyt spørgsmål. Vil jeg arbejde på med en masse generede filer fra WSDL import eller vil jeg mappe en masse værdier i wrapper klasser? Sjovt nok er der ikke en perfekt løsning på nogen af disse problemer. Når et projekt i start fasen beslutter at bruge SOA/Webservices er det ikke fragmenteringen af service der kommer i første række. En regel siger at gamle udkørte lagacy systemer, og forretningens forældede tanke mønstre, specificere det nye service layout. Lad mig gætte, dine services er store WS beskeder og det er kun nødvendigt at kalde ca 5 service for at udføre alle forretnings processer. Hvis du kan svare ja til forgående sætning har du en hård kobling i dit system. Din udviklingsgruppe generet en domain model ud fra WSDL'er og der findes tusindvis af referencer til dine proprietære domain model. Den hurtige siger: vi har en rig domain model med et mapping layer! Okey, fint men samme problematik. Så hvordan opnår man en løs kobling med SOA og WebServices? Kom til at tænke på at man også kunne omskrive legacy klasse til groovy.. <pre> def isPalindrome(String word) { word == word.reverse() } </pre> 2009-09-16T07:45:30Z 147 true 2009-10-14T11:58:59Z Hold da kæft hvor jeg er træt af håndværkere! Nej, i dette tilfælde er håndværkerne faktisk super gode og grundige. Det er mere den administrende virksomhed bagved som forsøger at snyde mig. Virksomheden er EBK Huse A/S, Slagelse, de bygger arkitekttegnet individuel byggeri. Byggeteknisk er de rigtig gode. Jeg har købt en arkitekttegnet individuel carport til kr. 300.000.- Når de vil øge deres fortjeneste benytter de et ord over for os novicer. Når de nævner ordret "individuel løsning" betyder det er der ikke følger noget som helst med. Det du faktisk køber er et skelet uden ganske almindelige forkommeden elementer. Efter min bedste overbevisning er ting som lys i en carport helt naturligt. Men nej. Hvad med isolering? Nej, det er vist heller ikke med selvom vi er blevet lovet at en lille fryser skulle kunne holde udhuset frostfrit. Hvad med strøm udtag så vi selv kan sætte lys op? Nej, det er ikke med i prisen. Hvordan kan man så sætte en fryser til? Hvad med ledning til udhus? Nej, der er for langt til huset er svaret fra den markedansvarlige hos EBK. Når man skræller alt larmen er der kun et signal tilbage. De vil tørre mig for penge. Jeg købte en færdig løsning med det hele og stillede ikke spørgsmålstegn ved hverken pris eller indretning. Min klare forventning til en færdig løsning indeholder også at lyset tænder i carporten når jeg kommer hjem. Men min terminologi er langt fra den samme som EBK's administration. En sjov ting er det at deres dygtige håndværkere er på min side. Faktisk stoppede de arbejde i den tro at de manglede materialer og ikke kunne forstå de manglen tiltag. Skylden er naturligvis min egen. Min forståelse for at man eksplicit skal efterspørge alle individuelle krav er for underudviklet. Føler jeg mig til grin. Ja fuldstændigt. Føler jeg mig snydt? Ja, fuldstændigt. Vil jeg være kunde hos EBK igen. Nej. Jeg kan ikke selv bygge noget som helst, derfor køber jeg ting. Og hvis det betyder at jeg alligevel skal bruge tid på at sætte mig ind i alle aspekter gider jeg ikke. Så hvis du ikke har god tid til at detage i alle detaljer find en anden forretning end EBK i Slagelse. Eller måske kan du li at føle dig snydt! 2009-08-17T16:25:45Z 146 true 2009-08-19T07:26:09Z