Jeg har to problemer! Jeg vil kunne tilføre nye regler og undtagelser dynamisk i en process. Min kode, eller notation skal være sprogneutral og den skal uden videre kunne læses af forretningskyndige. Dette er et par ydmyg krav og opgaven er at overføre policer fra et system til et andet. Konverteringsprocessen løber over flere dage og undervejs vil der komme undtagelser på enkelte policer og nye forretningsregler vil opstå. Det er ikke en option at stoppe, restarte eller deploye applikationen igen for at realisere evt nye regler. Jeg har valgt at isolere en process omkring en pensions-regel på laveste niveau. En pension kan bestå af dusinvis af disse niveauer og en samling af dem udgør en fuld pension. Jeg tager udspring en den eksisterende kode. Det kan være Java, .NET eller andre sprog som er konstrueret i samme programmering model. <pre> DummyPolice police = new DummyPolice(); PoliceLevel level = new PoliceLevel(); level.setPolice(“150364xxxx”); level.setGrundlag(“omregning”); level.setProcent(3); level.setGrundform(212); level.setYdelse(123.340,25); police.add(level); </pre> Udviklere fra den dynamiske eller funktionelle verden er ikke imponeret. En af de første ting man kunne fornemme er en høj grad af syntaktisk støj. I denne situation findes to slags støj, unødvendige forstyrrende elementer, som parenteser, semikolon og lodret skrivemaskineapostrof/tegnsætningsapostrof, og en del repeterende kode som fx “set”. <pre> level.police “150364xxxx” level.grundlag “omregning” level.procent 3 level.grundform 212 level.ydelse 123.340,25 </pre> Hvordan skeler man mellem “set” kontra “get” metode signaturer. En “set” metode modtager input hvorimod en get metode afgiver output! Hvordan bestemmes hvilken type som bliver overført i beskeden mellem objekterne? Når man arbejder med dynamiske sprog er en af de første ting man bemærker og sætter pris på, den mindre betydning som typer udgør. Med mindre systemet fejler er man faktisk ligeglad. Fx police identifikator er en integer, biginteger eller en streng når man som her indføre “xxx” som erstatning for de 4 sidste tal. Hvis man vil have en numerisk værdi skulle “xxxx” udskiftes med “0000”. Denne kode er en Intern DSL hovedsagligt opbygget gennem “DSL Method Chaining” med en tydelig kontekst(DSL Context). Konteksten er en police på laveste niveau. Det betyder at når linjen “procent 3” eksekveres er det af en regel på et police niveau. <pre> police 150364xxxx grundlag omregning procent 3 grundform 212 ydelse 123.340,25 </pre> Ved denne transformation har jeg nu noget business like kode som forretningens domain eksperter kan fortolke. Det er sprog neutralt og fungere som en pensions DSL input. Nu mangler jeg blot at skrive selve DSL fortolker koden, men det vil jeg ikke komme ind på i denne post. De yder omstændigheder gør at dette skal eksekveres på en JVM og med Java SE kan det ikke lade sig gøre. Med Java’s Scripting API JSR223 kan det lade sig gøre. JSR223 Scripting API’et gør det muligt at eksekvere mange former script-sprog på Java platformen. Jeg gider ikke fortælle om de små detaljer da frameworket er ganske lille og super enkelt. Java SE 6 indeholder en javascript-engine baseret på Rhino og det betyder at man kan fortolke dynamisk javascript i Java koden uden at addere ekstra jars. Hvorfor vil man eksekvere script kode internt i Java kode? * Java mangler en dynamiske tilgang * Man kan skabe nye variabler uden at definere en type, man kan skifte type undervejs, typekonvertering sker i mange tilfælde helt automatisk. * Man kan edittere kode og eksekvere, uden brug af rekompilering. * Man kan eksekvere konfiguration scripts, forretningslogik/regler og matematiske udtryk for finansielle applikationer fra en ekstern kontekst. * Man kan invokere “shell” scriptsekvenser i kørende applikationer. Hvis man vil have fortolket andre script-sprog, fx ruby i Java applikationen kræver det at man lægger en jar fil med ruby-script engine i classpath. se nederst på siden for andre muligheder. Når man skal fortolke script sprog undervejs er hastigheden ikke fantastisk! Derfor er der indbygget mulighed for at kompilere et script til bytecode og optimere hotspots. Alle binære script-engiens er bygget med Java SE 6 hvilket gør bagudkompatibilitet irriterende besværligt. Med Java 1.4 er det nærmest umuligt idet der i implementationen er brugt varargs fra Java 5. I Java7 er flere dynamiske API’er på vej fx JRuby, Jython og Beanshell. Det betyder at det er muligt at skrive fx ruby kode i Java kode. Faktisk mangler man så kun at kunne at kunne markere blokke med ruby koden med tags direkte i Java koden. På samme måde som Pascal kunne håndtere assembler i sin tid. Tilbage til eksemplet. Jeg vil udnytte groovy’s smarte og lette notation til denne opgave i en kørende Java applikation så lad os antage at jar filer og fortolker er tilstede i projekt konfigurationen. I teorien kunne det være hvilken af de scriptsprog som understøttes. Nu vil det være muligt at skrive denne kode: <pre> public void run_groovy_code(Sting code) throws Exception { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine = factory.getEngineByName("groovy"); Object ret = engine.eval(code); assertEquals('this is groovy code', ret); } run_groovy_code("return 'this is groovy code'") </pre> Nu er det altså muligt at overføre kode som eksekveres “on the fly”. Lad os nu antage at Java processen har kørt i flere timer og der kommer forskellige fejl. De bliver listet i en kø og kan browses med en gui. Man kan hente hver enkelt ind og se beskeden og fejl beskeden. Der er også mulighed for at indtaste en regel som kan løse netop denne situation. Det modtagende system kan ikke modtage 212 for ægtefælder, den skal konverteres til 216. <pre> rule if grundlag == omregning && grundform == 212 then grundform 216 </pre> Nu findes den nye regel i systemet og policen kan reeksekveres igen. Hvis køen er smart konstrueret opdager den selv at en ændring er sket og policen submittes ind i systemet mens den nye regel bytter 212 ud til 216 som det modtagne system kan håndtere. Hvis man betragter applikationen som ren scaffolding for forretningsprocesser og forretningsregler kan man invokere et meget tættere samarbejde med de forretningskyldige. Ligeledes kan man separerer/abstrahere forretningsspecifikke regler fra applikationer og dermed også de lange round-trips som vi lider under. En af de store nøgler er at isolere enkelte processer til en niveau hvor det er muligt at skrive en DSL og skabe en mere deklarativ måde at anskue problemerne på-. Processen kan ovenikøbet være interaktiv og tillade at tilføre regler undervejs, måske af forretningen selv. Skønt! JSR223 gør det muligt! Her er en kort liste med et par af de script-sprog som kan eksekveres i Java med JavaScripting API. * BeanShell - Small, free, embeddable Java interpreter * FreeMarker - Java-based general purpose template engine * Groovy - Groovy is an agile dynamic language for the Java * Jaskell - Lazy functional programming language * JavaScript Rhino 1.6R7 based JavaScript script engine. * JEP - Parsing and evaluating mathematical expressions * Jexl - Java Expression Language, expression language engine * JudoScript - Scripting language built on top Java * JUEL - Java Unified Expression Language * OGNL - Object-Graph Navigation Language * Ruby - Best language ever * Scheme - multi-paradigm programming language, one of two main dialects of Lisp * Tcl - Tool Command Language * XPath - Finding information in an XML document * XSLT - language for transforming XML * JavaFX Script - Declarative scripting language * AppleScript - The Language of Automation * Bex script * OCaml - fast, concise and powerful language * PHP * PHP * Python * Smalltalk - Dynamically typed, reflective programming language * CajuScript - Powerfull script to use with Java. 2009-01-16T01:28:21Z 131 131 true 10 2009-03-21T01:40:47Z Jeg sider på et projekt og abstrahere nogle skatteberegninger som skal eksekveres i Java. Alt det kryptiske gøjl omkring opsætning og små ligegyldige spidsfindigheder er på plads. Det som holder mig vågen er hvordan jeg skal synliggøre eller promote grænsefladen til disse beregninger for en stribe udviklere. Jeg kan jo bare lade dem konstruere en stribe objekter og invokere set metoder på objekterne. Det er bare så almindeligt og jeg er dødtræt af hele termologien omkring set og get metoder. Jeg kunne også bruge injection framework eller måske factory metoden. Flere af beregninger kan udføre alene men nogle andre er afhængige af delberegninger. Hvordan udtrykker jeg det på en simple og hensynsfuld måde? Alle beregninger kræver forskellige input og nogle resultater er input til andre hvilket medfører en bestemt rækkefølge. Fluent interface kunne være en løsning nu da platformen er Java. Martin Fowler har skrevet flere blogs omkring emnet og de er for det meste fornuftige. Et sandt fluent interface kan være en fornøjelse at bruge. Man behøver ikke huske alle mulige ting om implementeringen og man kan direkte fortolke lingo’en. Fluent interface har levet i lange tider i dynamiske sprog men gode eksempler er der ikke mange af. Fluent interface kan tvinge en til at tænke hårdt over selve forretningen og det det er der jo aldrig tid til. Så hellere lave én dårlig løsning. Nå det handler om Lingo. <pre> Beregn beregn new BeregnImpl(); beregn.befordring(). beregn.fribil(). beregn.skat(); </pre> Dette er en fin løsning og næsten helt deklarativ programmering, men tager ikke højde for input/output og heller ikke for selve eksekveringen. Fluent interface er måske den bedste metode til at gøre statiske Java til et DSL sprog? Måske ikke helt men næsten, der er stadig de grimme parenteser alle vegne og lidt gentagelse men det kan lade sig gøre at skrive noget kode som næsten lader sig læse som plain sprog. Når man arbejder med fluent interface drejer det sig om at opbygge en kontekst der kan opereres på. Så fribil er altså en metode på beregn og fribil returnere samme kontekst osv. At designe et fluent interface er svært, at implementere bibliotekerne bag er endnu sværere. * Skjul dit arbejde. Hvis du hele tiden føler dig nødsaget til at fortælle hvor langt du er kommet er der noget galt. * Hold din kontekst for dig selv. Klienten må naturligt kunne fornemme konteksten. * Eksponer ikke din implementation. Klienten må kun se de valg som findes netop i denne kontekst. * Brug lang tid på navn konvention. Perspektivet er klientens og DSL’en skal udtrykke forståelige koncepter. * Lav flere design. Fly ikke med det første. * Lad aldrig klienter gentage sig selv. Lad mig prøve at gøre det lidt bedre: <pre> Beregn().befordring().fribil().skat(); </pre> Gentagelserne er væk. Desværre kan jeg ikke styre eksekveringen, skal hver metoder invokere en del beregning? Og hvad med input og det faktum at befordring er en del af skatberegningen. Vil jeg sætte input på Beregn(), så input gælder alle beregninger? Behøver jeg en metode til sidst som eksekvere koden? Hvad er output? Mens jeg tænker over dette har min kollega lavet denne presentation om fluent interfaces. "Fluent interface for SQL in Java":http://docs.google.com/Presentation?id=dckns5q8_86hff23tcw 11 2008-05-16T05:44:00Z 111 111 true 10 2008-05-27T00:45:10Z Når man laver en DSL (Domain Specific Language) er der flere forskellige patterns man kan benytte. Men først kan man dele DSL'er op i to grupper. En intern og en ekstern. Den interne bliver til i host programmeringssproget. Den mest almindelige eksterne DSL er en samling af unix programmer som i en bestemt sammenlægning udgør et stærkt DSL. I dette tilfælde drejer det sig kun om intern DSL. En DSL er et subset af et programmeringssprog der er forenklet på en måde så forretningsdrivende der arbejder i domainet umiddelbart kan genkende og validere de enkelte sprogkonstruktioner. En DSL er enkel og kan udtrykke selve forretningen. Et af de mest kendte DSL eksempler på blog niveau er kaffe testen. Jeg er rigtig glad for dette eksemple da jeg drak meget Starbucks kaffe da jeg arbejdede i New York. Alle Starbucks forretninger har deres egen sprog når der bestilles kaffe. Som kunde modtager man en veritabel byge af spørgsmål om alt fra vandkvalitet til vaniljesmag. Det drejer sig altså om at skabe en bestilling på en eller flere kopper kaffe. Grammatikken for en kaffeordre er størrelse, tilbehør og typen af kaffe. Så på baggrund af dette vil jeg kunne bestille sådan. <pre> Starbucks.order do grande.coffee short.americano venti.breve.half_caff end </pre> Okey det kan vel næsten alle læse. Hver linje er en kop kaffe, så her er altså en ordre på tre kopper. Et normalt morgenforbrug. Hvis vi kigger nærmere på ord som forretningen ikke kender finders der kun nogle få. En af de største styrker ved DSL er læsbarheden. Måske kan forretningen ikke selv skrive den konkrete kode men de kan nemt læse og forstå den, evt i samråd med de udviklere som forsøger at validere deres implementering. Det ser ud som ordre objektet laver alt arbejdet. Ordre har ansvar for fortolkningen af DSL'en. Modulet ordre laver en instans af Ordre og kalder metoden instance_eval på det. Det får blokken til at eksekvere med ordre som binding. Derefter vil alle metoder være brugbare på ordre via blokken. Det fortolkerne objekt kan udføre en masse tricks en mens det eksekvere DSL'en, i dette tilfælde generere det en oversættelse. Kombinationer er dog utallige. Hvis du har svært ved at vænne dig til context kan man parse et objekt med ind i blokken men jeg elsker den DRY kode med meget lidt repetition. I nogle år har jeg haft den tanke at konstruere en ny webbank light til de almindelige bankkunder som har normale krav, de 10 mest brugte features taget ud fra en eksisterende prioriteret liste. Webbank light udnytter i høj grad DSL. Selv det at oprette testdata er blevet til et specifikt sprog. Problemet er at applikationen kræver det som en bank har som kærneforretning. At vedligeholder en konto med kontobevægelser over tid. Kort sagt skal jeg popurlere databasen med konto balance og konto bevægelser tilbage i tiden og jeg vil gerne kunne finde på nye scenarier efterhånden. <pre> trans = Bank.transaction |account| do account.deposit.everly.month.amount 27500 "Salary" account.withdraw.everly.month.amount 8000 "Rent" account.withdraw.amount 50 "Irma" account.balance.amount end </pre> Men det kan nemt gøres bedre. For det første er der for meget repetition i koden, flere ord står på hver linje og udgør ikke noget ekstra information for mig. Ved at fjerne ord som amount og account bliver DSL’en mere læsbar for mennesker. Til gengæld kan nogle muligheder i DSL’en være forstået eksplicit. h4. Java fluentinterface Man kan også lave næsten det samme med Java. Måske bliver koden en smule mere verbose men meningen skulle være der. Jeg benytter fluentinterface til at få syntaksen på plads. <pre> Payment payment = new Payment() .transation() .whitdraw() .currency(Currency.DKK) .amount(50) .text("Irma"); </pre> Det er samme teknik som kan gøre lej med dato objekter nemmere. Her addere et fluentinterface nye metoder til en Date klasse. <pre> Dato dato = new Dato(); dato.at_beginning_of_day(); dato.advance(); dato.end_of_day(); dato.midnight(); dato.ago(84000); </pre> 4 2008-01-31T03:19:00Z 95 95 false 10 2008-02-04T05:22:51Z Obscure Data Formats, Workflow, and Remote Synchronization Ved RailsConf i Berlin talte jeg med Chad Thatcher om et projekt hvor han har konverteret et stort katalog der indenholder musik manuscripter fra det 16ende og 18ende århundrede. Musikken ligger i det anerkende format MARK som blev udviklet i 1960erne for digital lager. Formatet er komplekst herakttisk opbygget og bruges stadig overalt hvor kunstværker gemmes i digital form. "Répertoire International des Sources Musicales":http://www.rism-ukie.org Chad har konstrueret ny grænseflade til systemet i Rails med fuld udnyttelse af Ajax, fx Drag and drop and auto-completion af de meget komplekse MARK records hvilket er en stor hjælp for de folk som tilføre data til disse records da de i selv indeholder mere end 2500 keywords. Selve MARK formatet er bibehold men der er tilføjet en ny model som mappe til en en mere normal RDMS løsning som giver flere fordele i henhold til søgninger og editering af records. På grund af den rå mængde af data så man ingen mulighed for at flytte til andet format. Hver MARC record er nu gemt som tekst i databasen og bliver mappet i real-time til en tree struktur, ved hjælp af composed_of property indbygget ActiveRecord. På denne måde kan navigation og søgning ske umiddelbart i MARK data. Dette har forbedret en søgning fra ca. 43 sekunder til 0.003 sekund. Jet Fighter Fuel En sen aften time talte jeg med Rich Kilmer fra Virginia-based InfoEther. Han tale på JAOO om Ruby and the Art of Domain Specific Languages. Han anses som den førende indefor DSL og desktop-based Ruby + Flash applikation. Rich er aktiv medlem af Ruby community har lavet fx. FreeRIDE Ruby IDE, RubyGems package manager, Ruby Java Debugging Library and the Jabber4R Jabber library. Rich hostser også RubyForge.org projekt siden for Ruby community og er medlem af Ruby Central. Rich viste nogle slides omkring et projekt i 2003 hvor han var indkaldt som redningsmand da projektet var stagneret pga kompleksitet. Systemet skulle håndtere USA's militær fly brændstof påfyldning simulationer der ligger til grund for hvor og hvornår jet fly tanker i luften. Rich besluttede at skrive løsningen i Ruby, og gøre det Domain Specific. Så koden blev skrevet i samråd med den ene militær mand som viste helt præcist hvordan denne proces skal forløbe. På tre uger kunne de begge læse den samme kode som ethvert andet A4 dokument med en tekstuel repræsentation af systemets adfærd. Koden skrive i det sprog som forretning eller processen bruger og alle kan derfor forstå forløbet. "Rich Kilmers blog":http://richkilmer.blogs.com/ 3 2007-10-04T09:01:00Z 74 74 false 10 2008-04-08T07:04:39Z The way you writing efficient, effective code are changing. Domain Specific Languages are one of the key factors driving this "Shifting Paradigm". DSL allow you to incorporate highly specialized tasks into your projects, tasks that otherwise could not be accomplished by general purpose programming languages like Java. bq. DSL can perspectives complexity. DSL can escalate the abstraction layer. DSL are less comprehensive. DSL are much more expressive in their domain. DSL are more agile, reusable and manageable applications Domain Specific Languages En DSL kan beskrives som et begrænset computersprog designet for et specielt problem. DSL kan være et kraftfuldt værktøj til at lukke det ocean som findes mellem udviklere og domæne eksperter. DSL udtrykker information og adfærd på en klar og tydelig måde og samtidig kan koden læses som almindeligt sprog. Domæne eksperterne kan nemt læse DSL for at fastslå at forståelsen af forretningen er korrekt, i et traditionelt system kan dette typisk ikke lade sig gøre. DSL har stor indflydelse på mange områder af applikationsudvikling og frameworks hvor løsninger kan blive både kraftige og elegante. 11 2007-05-31T02:58:00Z 43 43 false 10 2008-04-03T09:21:51Z