Hommikune loeng: Testing Grails - Experiences from the field
Testida tuleb tervikut, tervet süsteemi
1) rakendusi
2) integratsioonipunkte
3) kogu süsteem
Testida tuleb rakendusi lahus ja samas ka koos. Unit testid ei ole piisav, vaja on ka integratsiooni ja funktsionaalseid teste.
Autotest plugin - vaatab mis sa koodis teed ja laseb selle peale testi käima.
Spock tööriist. Tundub et hetkel parim variant mis on testimiseks Grailsi lisatud.
Meetodi nimi saab olla string ehk siis kirjeldab otse ära mida antud test peaks tegema. Siia saaks väga kenasti nõudeid lisada mis tulevad analüüsi poolt.
Sisseehitatud mocking library. GrailsMock
BetaMax - salvestab reaalsega API-ga suhtluse ja pärast seda saab antud rakendust kasutada vastava API simulaatorina integratsioonitestides. Tuleks üle vaadata kuidas see töötab ja kuidas rakendada.
1) No IO in Unit tests - ei tohi teha tegevusi mis kasutavad seda tüüpi ressursse (failisüsteem, võrk, baas) et unit testid ei läheks aeglaseks
2) unit test peaks testima ainult ühte väikest funktsionaalsust - näiteks meetodit
Põhimõte - kui antud koodiblokk ei ole testitav, tuleks teha refaktooring.
Post-Dramatic-Test-Driven-Programming :)
Tuleks kirjutada test mis loob sul arenduses veaolukorra uuesti.
Ükski feature ei tohiks olla valmis kui pole kirjutatud teste.
Test fridays - kirjuta iga reede mingi test :)
Javascript UI testing - karma-test-runner raamistik, Angulari team soovitab seda.
Jmeter - testkeskonnas
Automatiseeri kõik tegevused mida muidu käsitsi peaks tegema.
CodeNarc
Code Coverage
gmetrics
Canary - end user QA :))))
Grails - Real world
Embedded TcServer - as jar
FileCacheService - hoia failid MongoDB GridFS sees (võimaldb Cloud Foundryt kasutada)
saab urli pealt striimida otse gridfs sisse ilma et peaks mällu kõike tõmbama.
Osta kvaliteetset infot. Osta theme'e
Typescript - tasuks vaadata - pakub tugevalt tüübitud javascripti sarnast keelt mis kompileeritakse javascriptiks (olemas ka grails plugin).
UI-dest tuleks vaadata lähemalt Kendo UI Angular versiooni mis tehti just opensourceks. Tundub arvestatav alternatiiv Ext JS-ile ning Bootstrapile.
GSON - domeeniobjektist JSON andmestruktuuri loomine. Ei tohiks vaikimisi lazy seoseid kohe mällu laadida.
JSON teenuste arendamise juures oleks XSD-le heaks alternatiiviks JSON andmestruktuuri kokkuleppimine koos näidis andmetega. Seda saaks serveri arendaja kasutada enda endpointide testimiseks ning UI arendaja testimiseks ilma serverita.
Jätkuvalt soovitati Grailsi webdriver plugina kasutamist functional testide tegemiseks.
Sellega konverents ka lõppes. Kokkuvõttes oli väga kasulik üritus, andis palju mõtteid millega iseseisvalt edasi tegeleda.
Kokkuvõtlikud märksõnad mis siin erinevates esitlustes läbi käisid:
REST, JSON, ASYNC, SPOCK, NOSQL, GRAILS 2.3, SPRING IO, GROOVY DSL, SPRING DSR, KARMA, MAGNOLIA, GRADLE.
Jääme ootama SpringOne 2014-st. Nüüd väike sleep ja siis ülipikale tagasisõidule.
Siia lõppu veel üks mõte kui rääkida paksudest klientidest:
http://griffon.codehaus.org + QT või JavaFX! - ütleme EI .NET-ile eks :)
Thursday, September 12, 2013
Wednesday, September 11, 2013
Kolmas päev - SpringOne2gx 2013
Kui eile oli põhiteemaks Big Data, Sprinb Batch, Grails uuendused ja tulevik, siis täna on lisaks ka kliendi poolsed teemad (Angular, Events) ning Rest, Rest ja Rest.
Vaatasin üle loengu Grailsi erinevad arhitektuurid ja tõesti hakkas silma väga tugev sisemsite bus-ide kasutamine olgu see siis Spring Events, Spring Integration või Camel vormis. Samas võib ka selleks vabalt olla rabbitmq lahendus.
Üks arhitektuurne lähenemine mis seal meeldis, oli see, et kasutaja tegevused tulevad sisse ja
need kirjutatakse kõik denormaliseerituna maha baasi nn. deltadena, et on täpselt näha iga kasutaja liigutus. Kasutaja saab teate et andmed on töötluses ja kohe tuleb tulemus.
Selle peale käivitatakse push event busile mis teavitab gorm-i uutest andmetest mis täidab ära nii põhibaasi kui ka vajalikud otsingubaasid ning siis lastakse grails events plugina abil kasutajale info tagasi. Tõeliselt asünkroonne lahendus.
vt. grails-events plugins, grails-push. Spring Events, Reactor.
Nüüd algab Angular.
Matias Googlest räägib AngularJS-ist.
http://yearofmoo.github.io/springone/#/
http://www.yearofmoo.com/
Slaidid ja selle tüübi kodukas angluari kohta, väga hea info allikas.
Angulari loengus soovitati kirjutada palju unit-teste ning lisaks soovitati kasutada webdriverit. Tuleks üle vaadata chrome webdriver.
Järgmisena oli teemaks Graeme Grails 2.3 Rest kasutus. Sarnanes eilse keynotega, aga oli täna põhjalik.
Uues grailsis on rest ressurssideks nii controllerid kui ka vajadusel domeeniobjektid otse. Domeeniobjektil on vaja ta defineerida kui @Resource ja url mappingus paika ajada ja ongi automaatselt kõik rest toimingud toetatud.
Controllerite puhul tulekb need kas genereerida (uus scaffolding plugin genereerib rest controllereid) või kasutada RestController superklassi.
2.3 võimalusi vaadates võiks kokkuvõtlikult öelda et springwebservicest võib loobuda ja soapi lõplikult ära visata. Kui on vajadus xml-i väljastada või vastu võtta saab seda lihtsalt rest controlleris öelda et väljundiks oleks xml mida näiteks saaks vajadusel xsd-ga valideerida.
Versioneerimist restis toetati nii urli põhiselt kui ka Accept-Version:x põhiselt. Mõlemad toimivad.
Objektide renderdamiseks JSON/XML kujul kasutatakse spetsiaalseid renderdajaid, mida on võimalik ka ise luua. Siin näeks use-casena näiteks Xtee rendereri loomist kus väljundiks on xml mis sisaldab vajalikke xtee tage ka.
urlmappingus saab rest resurssse ka nestida ala /cities/1/persons/1/edit
Async - Promiselist (väga mugav mitme asünk operatsiooni tulemuste kokkuviimiseks).
Päeva viimased loengud teemadel Angular-Groovy ning Spring Android midagi uut eriti ei pakkunud näidati lihtsalt Rest teenuste kasutamist.
Õhtul keynotet polnud seega sai varakult asi kokku tõmmatud.
Õhtul vabaa hetke ära kasutades sai lisaks uuritud veel nn. desktop kliendi arendamist ja hetkel on jäänud kaks varianti silma.
1) HTML rakenduse loomine Windows 8 peale kasutades VIsual Studiot ja WinJS komponente. Selle abil saab täiesti reaalse Metro rakenduse luua mis saab suhelda failsüsteemiga jne. Mootorina kasutab siis ilmselt IE 10-et.
2) Luua tüüpiline SPA rakendus ning bundleda see koos Bracktes-shell nimelise rakendusega mis on Adobe poolt loodud konteiner nende HTML-is kirjuatud HTML/CSS/Javascript editori jooksutamiseks erinevates OS-ides. hetkel on toetatud Mac ja windows aga Linuxi tugi on kohe tulemas. Kiire tutvumine erinevate postitustega näitas et selle shelli abil on võimalik suhelda nii failisüsteemiga kui ka kõikide teiste apidega mida Chrome pakub, sest see shell pakendatakse koos värske Chromium paketiga.
Lisaks on võimalik ise pluginaid kirjutada kui ka kasutada teisi mida on kommun loonud. Pluginad võimaldavad siis luua sildasid opsüsteemi ja javascripti vahele.
Siin on ka üks blogipostitus antud lahenduse kasutamisest: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/. Tundub paljulubav ja võiks lahendada probleemi kuidas rakendusi lõppkasutajale teha ilma et peaks muretsema et igapäevaselt kasutatav browser kas ei toeta teatud funktsionee või teeb versiooni uuendus omakorda midagi katki.
Vaatasin üle loengu Grailsi erinevad arhitektuurid ja tõesti hakkas silma väga tugev sisemsite bus-ide kasutamine olgu see siis Spring Events, Spring Integration või Camel vormis. Samas võib ka selleks vabalt olla rabbitmq lahendus.
Üks arhitektuurne lähenemine mis seal meeldis, oli see, et kasutaja tegevused tulevad sisse ja
need kirjutatakse kõik denormaliseerituna maha baasi nn. deltadena, et on täpselt näha iga kasutaja liigutus. Kasutaja saab teate et andmed on töötluses ja kohe tuleb tulemus.
Selle peale käivitatakse push event busile mis teavitab gorm-i uutest andmetest mis täidab ära nii põhibaasi kui ka vajalikud otsingubaasid ning siis lastakse grails events plugina abil kasutajale info tagasi. Tõeliselt asünkroonne lahendus.
vt. grails-events plugins, grails-push. Spring Events, Reactor.
Nüüd algab Angular.
Matias Googlest räägib AngularJS-ist.
http://yearofmoo.github.io/springone/#/
http://www.yearofmoo.com/
Slaidid ja selle tüübi kodukas angluari kohta, väga hea info allikas.
Angulari loengus soovitati kirjutada palju unit-teste ning lisaks soovitati kasutada webdriverit. Tuleks üle vaadata chrome webdriver.
Järgmisena oli teemaks Graeme Grails 2.3 Rest kasutus. Sarnanes eilse keynotega, aga oli täna põhjalik.
Uues grailsis on rest ressurssideks nii controllerid kui ka vajadusel domeeniobjektid otse. Domeeniobjektil on vaja ta defineerida kui @Resource ja url mappingus paika ajada ja ongi automaatselt kõik rest toimingud toetatud.
Controllerite puhul tulekb need kas genereerida (uus scaffolding plugin genereerib rest controllereid) või kasutada RestController superklassi.
2.3 võimalusi vaadates võiks kokkuvõtlikult öelda et springwebservicest võib loobuda ja soapi lõplikult ära visata. Kui on vajadus xml-i väljastada või vastu võtta saab seda lihtsalt rest controlleris öelda et väljundiks oleks xml mida näiteks saaks vajadusel xsd-ga valideerida.
Versioneerimist restis toetati nii urli põhiselt kui ka Accept-Version:x põhiselt. Mõlemad toimivad.
Objektide renderdamiseks JSON/XML kujul kasutatakse spetsiaalseid renderdajaid, mida on võimalik ka ise luua. Siin näeks use-casena näiteks Xtee rendereri loomist kus väljundiks on xml mis sisaldab vajalikke xtee tage ka.
urlmappingus saab rest resurssse ka nestida ala /cities/1/persons/1/edit
Async - Promiselist (väga mugav mitme asünk operatsiooni tulemuste kokkuviimiseks).
Päeva viimased loengud teemadel Angular-Groovy ning Spring Android midagi uut eriti ei pakkunud näidati lihtsalt Rest teenuste kasutamist.
Õhtul keynotet polnud seega sai varakult asi kokku tõmmatud.
Õhtul vabaa hetke ära kasutades sai lisaks uuritud veel nn. desktop kliendi arendamist ja hetkel on jäänud kaks varianti silma.
1) HTML rakenduse loomine Windows 8 peale kasutades VIsual Studiot ja WinJS komponente. Selle abil saab täiesti reaalse Metro rakenduse luua mis saab suhelda failsüsteemiga jne. Mootorina kasutab siis ilmselt IE 10-et.
2) Luua tüüpiline SPA rakendus ning bundleda see koos Bracktes-shell nimelise rakendusega mis on Adobe poolt loodud konteiner nende HTML-is kirjuatud HTML/CSS/Javascript editori jooksutamiseks erinevates OS-ides. hetkel on toetatud Mac ja windows aga Linuxi tugi on kohe tulemas. Kiire tutvumine erinevate postitustega näitas et selle shelli abil on võimalik suhelda nii failisüsteemiga kui ka kõikide teiste apidega mida Chrome pakub, sest see shell pakendatakse koos värske Chromium paketiga.
Lisaks on võimalik ise pluginaid kirjutada kui ka kasutada teisi mida on kommun loonud. Pluginad võimaldavad siis luua sildasid opsüsteemi ja javascripti vahele.
Siin on ka üks blogipostitus antud lahenduse kasutamisest: http://clintberry.com/2013/html5-desktop-apps-with-brackets-shell/. Tundub paljulubav ja võiks lahendada probleemi kuidas rakendusi lõppkasutajale teha ilma et peaks muretsema et igapäevaselt kasutatav browser kas ei toeta teatud funktsionee või teeb versiooni uuendus omakorda midagi katki.
Tuesday, September 10, 2013
Teine päev - SpringOne2gx 2013
Jetlag andis tunda - pool ööd istusin üleval.
Alustuseks võtsin Neo4J loengu, selle külastamise raames anti ka tasuta Graph baaside raamat, usun et see on ülivajalik kõigile kes tahavad sellest täpsemat ülevaadet saada.
Graph database kasutusvaldkondi:
teekonna otsimine
CA baas kus näiteks vaadata mida muudatus veel mõjutab.
soovitamised (ala amazoni soovitused raamatute otsimisel)
facebook tüüpi kes on selle sõbra sõprade seas veel keda sinna tunned vms
Logistika
Õiguste haldus (MIS raames on see eriti keerukas sql tasemel hetkel???)
Fraud Analysis
Graph andmebaasi puhul on hea omadus see et kiirus ei aeglustu kui baas läheb suuremaks, kui operatsioonid on suhteliselt lokaalsed. Sõltub rohkem sellest mitu seost sa ühe päringuga läbi jooksed.
Neo4J baasil on graafiline liides olemas mis on hästi sarnane domeenimudelile seega on võimalik hoida nii loogiline osa kui ka füüsiline olek väga sarnased (impedance mismatch puudub).
Väljade, seoste loomine käib vabalt, pole vaja kogu struktuuri ette defineerida.
Huvitav kuidas teha päringuid kiiremaks - lisad lihtalt kahe üksteisest liiga kaugel olevale graafile vahele seose.
Spring-Data-Neo4j on annoteerimispõhine API Neo4J otsa.
---------
Advanced Grails 2.3
gopivotal.com - Vmware spinoff kus toimub arendus nüüd. Grails core arendajad töötavad nüüd seal, peab täpsemalt uurima mis seda tähendab.
2.3 lasti eile välja.
Rest is the coolest feature in 2.3 :). Async support.
Kogu saal on grails arendajaid täis :)
Where query'd töötavad compile time ajal. Ehk siis kui kompileerimise ajal võetakse nende sisu ette parsitaks läbi ja asendatatakse konkreetsete hibernate päringutega. Oluliselt kiirem ja veavabam kui dynamic finderid. Lisaks võimalik tingimusi seadistada mugavalt keele süntaksiga <>= etc. Dynamic findereid kontrollitakse runtimes seega hetkel tundub et igati kasulikm on where querisid alati kasutada ja loobuda finderitest.
Jeff soovitab igal juhul kasutada ainult where querisid ja loobuda criteria kasutamisest, v.a juhul kui muid võimalusi ei ole ilmselt SQlrestriction on siin üks variant ala postgre fulltext indeks.
2-st alates on soovitab kindlasti Controlleri meetodid defineerida meetoditena mitte closuritena (aitab kaasa ka näiteks Appdynamicsi stacktracede lugemisel).
tahaks näiteks kõikides meetodtes cotrolleri sees IllegalArgumentExceptionid kinni püüda ja siis midagi teha:
def handleIllegalArugment(IllegalArgumentException e) {
//this block is always executed
render 'excption was thrown'
}
Tundub suur samm edasi defencive programmingu valdkonnas, et ei pea koodi try catch blokkidega üle ujutama, oluliselt muudab koodi lugemist ning samas ärgitab exceptione kasutama/viskama kuna nendega hilsem tegelemine pole nii tüütü. Kaval asi.
Kompilaator tegelikult ise genereerib try catch blokid koodile ümber.
Antud meetod peab olema compile time reziimis ehk metaprogrameerimisega seda ei saa lisada.
Kui defineerida lisaobjekt controlleris ning lisada see objekt sisendargumendina mõnele controlleri meetodile, käsitletakse seda objekti koheselt command objektina. See on väga mugav võimalus täiendavaks valideerimiseks. Databinding tehakse automaatselt ära params mapi ning antud objekti vahel. 2.3-es toetatakse ka request body bindimist command objekti külge. Näiteks hea kasutusviis oleks json payloadide töötlemiseks kui luua Rest API-sid.
def someControllerMethod(MyObject my) {
}
Täpselt sama asi kehtib ka domeeniobketide puhul, kus payloadi mappimisel otsitaks see objekt kõigepealt baasist üles ja siis mapitaks uued andmed sinna külge. Kui baasis sellist objekti ei ole, siis ei juhtu midagi, sest kui id-d ei anta tehakse uus.
def someMethod (MDomainObject obj ){
}
Forked Execution - protsessid eraldi threadides.
Rest Scaffolding eraldi pluginana - võimalik genereerida Rest controllerid domeeniobjektide peale.
grails-dependancy-report käsk annab kena sõltuvuste ülevaate.
Saab näha mida miski endale nõuab ja vastavalt sellele ka teha buildconfigis muudatusi.
Spoc on default raamistik testimiseks nüüd.
Kõik classpathid isoleeritud - seega test-app ei riku ära run-app profiili ja vice versa.
urlmappingus saab lihtsasti luua urlid rest jaoks
"/books"(resources:"book")
url-mappings-report - annab ülevaate kuidas urlid on mäpitud.
gorm-rest-client - standartne gorm api rest backendile (grailsi seest saab kasutada välist rest teenust üle mugava ja tuttava gorm api mitte mässama käsitsi tehtud rest päringutega), toetab kõike crud, find, criteria meetodeid.
Uus respond method mis olenevalt kliendist renderdab välja erineva tulemuse ja valib ka vastav renderdaja,
hal Json renderer - uus standard mis on tekkimas, tuleks lähemalt uurida.
class MyController extnds RestfulController - annab kõik rest meetodid kätte ilma koodi genereerimata, lisaks override võimalus. Tuttav teema grails-smit-core pluginast AbstractControllerist.
kindlasti kasutaks seda kui rest väljundit teha.
Vaadates arengute suunda tundub, et grails kui rest server on tugev suund kuhu liigutakse. Suurimaid arenguid UI-de osas pole näha peale XSS preventsioni täienemist, seega GSP-d kui sellised ja taglib kui selline hakkab pigem hääbuma, kui just mitte väga searchengine friendly avaliku saiti teha.
@Transactional annotatsion groovy jaoks. Määratleb ära millised meetodid või klassid alluvad transaktsioonile saab kasutada ka controllerites.
Väga oluline vahe nüüd spring transaktsional annotatsiooniga on see et spring versioon loob proxy (CGI või JDK) mis toob täienvada klassid aga antud lahendus kasutab AST transformatsiooni ja kirjutab klassi reaalselt ringi.
Asünkroonsus:
Book.async.list() - gorm päring asünkroonselt, väga mugav asi. Näiteks vaja teha korraga 3 päringut baasi siis mõistlik lasta nad asynciga saab tulemuse kordades kiiremini kätte.
@DelegateAsync - lihtsasti saab tavalisele klassile öelda et kõik meetodid nüüd toimivad asünkroonselt.
Grails 3 - uus Gradle põhine otsingusüsteem,
tuleb package profile lahendus. Vaja näiteks luua netty või batch rakendus siis saab profiili ette anda ja vastavad pluginad laetakse selle tulemusel.
Graemega vestlus - veebirakenduste puhul oli nagu arvata soovitus kasutada Angular/Bootstrapi.
Paksu kliendi puhul soovitas kas minna opsüsteemi põhiselt (ios, net) või siis selline uus projekt nagu OpenDolphin.
Grails search:
elastic-search-gormplugin - tasub kasutada kuna sõltub gorm eventidet mitte hiberante eventidest seega saab seda kasutada ka näiteks mongodb backendina või mõni muu. Jfrogi tüübid võtsid ise standard elasticu plugina ja tegid selle ringi.
Keset loenguid hakkas väga külm konditsioneeri pärast, seega sai ruttu üks rakendus cloudfoundrysse visatud ning omale hood saadud et soojem oleks :). Grails 2.3-e cloudfoundry plugin ei suutnud asju üles panna ütles et vale parool seeg kasutasin STS-i enda pluginat deploymiseks.
http://horizon2gx.cfapps.io/item/index - jookseb siin.
Spoc testid rockivad - tahaks kohe ise teste kirjutada - demoti väga head testi kus testiti elasticsearch serverist andmete küsimist.. Spock on 2.3-es core sees.
Vaatan kui aega saan, üritan spocki katsetada.
Viimane loeng näitas erinevaid tehnikaid jsoni tootmiseks ja parsimiseks erinevate grails vahenditega kuna rest puhul reeglina on json andmevahetuseks.
Kui nüüd keegi teeks ära standardse lahenduse kuidas jsonit valideerida, (grailsi uus command objekt lahendus sobiks kenasti aga see on grails ja ka lähtekoodipõhine. Aga ehk midagi xsd laadset oleks veelgi parem, kuna võimaldaks seda contractina kasutada??) saaks soapist lõplikult loobuda.
http://json-schema.org/example1.html - siin on algatus olemas - kas see oleks piisav et loobuda xsd, soap lahendusest?
Jäänud on siis veel keynote ja siis on päev sisuliselt läbi.
Keynote teemadeks oli Spring XD (Bigdata töötlemine) ja Spring Batch ning lisaks Grails 2.3-e demo async osas.
Peale keynotet jäi veidi vaba aega ja siis hakkas sinna otsa kohe Grails BOF. Pidi kestma tunni aga juttu jätkus nii palju et sain sealt 23:45 alles minema olles täiesti läbi juba. PEamiselt sai räägitud Grails tulevikust, Grails levikust, pluginatest, võrdlusest Railsi ja Djangoga jpm.
Graeme põhisõnum oli et Grails ei ole su YAWF raamistik enam mida siis võrrelda siin php-ga vms. Vaadates kuhu liigub grails 3 (konteinerist välja) ning mida pakub meile GORM (algsest hibernate mapperist on saanud eraldi pluginana täiesti iseseisev moodul mis pakub abstraktsioon täna juba erinevatele andmeallikatele REST-ist kuni MongoDB-ni välja.)
Palju arutati ka muidugi seda, et kuidas Spring arendajatele Grails paremini selgeks teha, kuidas seda sõnumit edasi anda - see et Grails nimetati Spring IO üheks "Runtime" komponendiks oli suur samm edasi.
Täna on Grailsil ka maine poolest palju puudusi kuna endiselt ka versioon 2.x Grailsi seostatakse tegelikult versiooniga 1.x kus oli palju erinevaid vigu mis kasutajat frustreerisid, aga see on miskipärast meeles kõigil. Burt käis eile BOF-is isegi välja mõtte et tuleks nimi ära vahetada.
3.0 tuleb välja järgmise aasta sügiseks. Mainimist tasuks ka veel 2.3 AETHER sõltuvuste raamistik mis täna kättesaadav on, sest see on sama komponent mis maveni kõhus, seega peaks kõiksugused IVY jamad kadunud olema.
Loodan et varsti saab alustada 2.3-ga tööd.
Alustuseks võtsin Neo4J loengu, selle külastamise raames anti ka tasuta Graph baaside raamat, usun et see on ülivajalik kõigile kes tahavad sellest täpsemat ülevaadet saada.
Graph database kasutusvaldkondi:
teekonna otsimine
CA baas kus näiteks vaadata mida muudatus veel mõjutab.
soovitamised (ala amazoni soovitused raamatute otsimisel)
facebook tüüpi kes on selle sõbra sõprade seas veel keda sinna tunned vms
Logistika
Õiguste haldus (MIS raames on see eriti keerukas sql tasemel hetkel???)
Fraud Analysis
Graph andmebaasi puhul on hea omadus see et kiirus ei aeglustu kui baas läheb suuremaks, kui operatsioonid on suhteliselt lokaalsed. Sõltub rohkem sellest mitu seost sa ühe päringuga läbi jooksed.
Neo4J baasil on graafiline liides olemas mis on hästi sarnane domeenimudelile seega on võimalik hoida nii loogiline osa kui ka füüsiline olek väga sarnased (impedance mismatch puudub).
Väljade, seoste loomine käib vabalt, pole vaja kogu struktuuri ette defineerida.
Huvitav kuidas teha päringuid kiiremaks - lisad lihtalt kahe üksteisest liiga kaugel olevale graafile vahele seose.
Spring-Data-Neo4j on annoteerimispõhine API Neo4J otsa.
---------
Advanced Grails 2.3
gopivotal.com - Vmware spinoff kus toimub arendus nüüd. Grails core arendajad töötavad nüüd seal, peab täpsemalt uurima mis seda tähendab.
2.3 lasti eile välja.
Rest is the coolest feature in 2.3 :). Async support.
Kogu saal on grails arendajaid täis :)
Where query'd töötavad compile time ajal. Ehk siis kui kompileerimise ajal võetakse nende sisu ette parsitaks läbi ja asendatatakse konkreetsete hibernate päringutega. Oluliselt kiirem ja veavabam kui dynamic finderid. Lisaks võimalik tingimusi seadistada mugavalt keele süntaksiga <>= etc. Dynamic findereid kontrollitakse runtimes seega hetkel tundub et igati kasulikm on where querisid alati kasutada ja loobuda finderitest.
Jeff soovitab igal juhul kasutada ainult where querisid ja loobuda criteria kasutamisest, v.a juhul kui muid võimalusi ei ole ilmselt SQlrestriction on siin üks variant ala postgre fulltext indeks.
2-st alates on soovitab kindlasti Controlleri meetodid defineerida meetoditena mitte closuritena (aitab kaasa ka näiteks Appdynamicsi stacktracede lugemisel).
tahaks näiteks kõikides meetodtes cotrolleri sees IllegalArgumentExceptionid kinni püüda ja siis midagi teha:
def handleIllegalArugment(IllegalArgumentException e) {
//this block is always executed
render 'excption was thrown'
}
Tundub suur samm edasi defencive programmingu valdkonnas, et ei pea koodi try catch blokkidega üle ujutama, oluliselt muudab koodi lugemist ning samas ärgitab exceptione kasutama/viskama kuna nendega hilsem tegelemine pole nii tüütü. Kaval asi.
Kompilaator tegelikult ise genereerib try catch blokid koodile ümber.
Antud meetod peab olema compile time reziimis ehk metaprogrameerimisega seda ei saa lisada.
Kui defineerida lisaobjekt controlleris ning lisada see objekt sisendargumendina mõnele controlleri meetodile, käsitletakse seda objekti koheselt command objektina. See on väga mugav võimalus täiendavaks valideerimiseks. Databinding tehakse automaatselt ära params mapi ning antud objekti vahel. 2.3-es toetatakse ka request body bindimist command objekti külge. Näiteks hea kasutusviis oleks json payloadide töötlemiseks kui luua Rest API-sid.
def someControllerMethod(MyObject my) {
}
Täpselt sama asi kehtib ka domeeniobketide puhul, kus payloadi mappimisel otsitaks see objekt kõigepealt baasist üles ja siis mapitaks uued andmed sinna külge. Kui baasis sellist objekti ei ole, siis ei juhtu midagi, sest kui id-d ei anta tehakse uus.
def someMethod (MDomainObject obj ){
}
Forked Execution - protsessid eraldi threadides.
Rest Scaffolding eraldi pluginana - võimalik genereerida Rest controllerid domeeniobjektide peale.
grails-dependancy-report käsk annab kena sõltuvuste ülevaate.
Saab näha mida miski endale nõuab ja vastavalt sellele ka teha buildconfigis muudatusi.
Spoc on default raamistik testimiseks nüüd.
Kõik classpathid isoleeritud - seega test-app ei riku ära run-app profiili ja vice versa.
urlmappingus saab lihtsasti luua urlid rest jaoks
"/books"(resources:"book")
url-mappings-report - annab ülevaate kuidas urlid on mäpitud.
gorm-rest-client - standartne gorm api rest backendile (grailsi seest saab kasutada välist rest teenust üle mugava ja tuttava gorm api mitte mässama käsitsi tehtud rest päringutega), toetab kõike crud, find, criteria meetodeid.
class Book {
String title
static mapWith = "REST"
static mapping = {
endpoint "/books"
format "xml"
}
}
Instances can be retrieved an unmarshalled with the regular
get method (which will issue a GET request):def b = Book.get(1) // GET /books
save toimib ka samamoodi nagu ta gorm-hibernate lahenduse puhul toimub.
Uus respond method mis olenevalt kliendist renderdab välja erineva tulemuse ja valib ka vastav renderdaja,
hal Json renderer - uus standard mis on tekkimas, tuleks lähemalt uurida.
class MyController extnds RestfulController - annab kõik rest meetodid kätte ilma koodi genereerimata, lisaks override võimalus. Tuttav teema grails-smit-core pluginast AbstractControllerist.
kindlasti kasutaks seda kui rest väljundit teha.
Vaadates arengute suunda tundub, et grails kui rest server on tugev suund kuhu liigutakse. Suurimaid arenguid UI-de osas pole näha peale XSS preventsioni täienemist, seega GSP-d kui sellised ja taglib kui selline hakkab pigem hääbuma, kui just mitte väga searchengine friendly avaliku saiti teha.
@Transactional annotatsion groovy jaoks. Määratleb ära millised meetodid või klassid alluvad transaktsioonile saab kasutada ka controllerites.
Väga oluline vahe nüüd spring transaktsional annotatsiooniga on see et spring versioon loob proxy (CGI või JDK) mis toob täienvada klassid aga antud lahendus kasutab AST transformatsiooni ja kirjutab klassi reaalselt ringi.
Asünkroonsus:
Book.async.list() - gorm päring asünkroonselt, väga mugav asi. Näiteks vaja teha korraga 3 päringut baasi siis mõistlik lasta nad asynciga saab tulemuse kordades kiiremini kätte.
@DelegateAsync - lihtsasti saab tavalisele klassile öelda et kõik meetodid nüüd toimivad asünkroonselt.
Grails 3 - uus Gradle põhine otsingusüsteem,
tuleb package profile lahendus. Vaja näiteks luua netty või batch rakendus siis saab profiili ette anda ja vastavad pluginad laetakse selle tulemusel.
Graemega vestlus - veebirakenduste puhul oli nagu arvata soovitus kasutada Angular/Bootstrapi.
Paksu kliendi puhul soovitas kas minna opsüsteemi põhiselt (ios, net) või siis selline uus projekt nagu OpenDolphin.
Grails search:
elastic-search-gormplugin - tasub kasutada kuna sõltub gorm eventidet mitte hiberante eventidest seega saab seda kasutada ka näiteks mongodb backendina või mõni muu. Jfrogi tüübid võtsid ise standard elasticu plugina ja tegid selle ringi.
Keset loenguid hakkas väga külm konditsioneeri pärast, seega sai ruttu üks rakendus cloudfoundrysse visatud ning omale hood saadud et soojem oleks :). Grails 2.3-e cloudfoundry plugin ei suutnud asju üles panna ütles et vale parool seeg kasutasin STS-i enda pluginat deploymiseks.
http://horizon2gx.cfapps.io/item/index - jookseb siin.
Spoc testid rockivad - tahaks kohe ise teste kirjutada - demoti väga head testi kus testiti elasticsearch serverist andmete küsimist.. Spock on 2.3-es core sees.
Vaatan kui aega saan, üritan spocki katsetada.
Viimane loeng näitas erinevaid tehnikaid jsoni tootmiseks ja parsimiseks erinevate grails vahenditega kuna rest puhul reeglina on json andmevahetuseks.
Kui nüüd keegi teeks ära standardse lahenduse kuidas jsonit valideerida, (grailsi uus command objekt lahendus sobiks kenasti aga see on grails ja ka lähtekoodipõhine. Aga ehk midagi xsd laadset oleks veelgi parem, kuna võimaldaks seda contractina kasutada??) saaks soapist lõplikult loobuda.
http://json-schema.org/example1.html - siin on algatus olemas - kas see oleks piisav et loobuda xsd, soap lahendusest?
Jäänud on siis veel keynote ja siis on päev sisuliselt läbi.
Keynote teemadeks oli Spring XD (Bigdata töötlemine) ja Spring Batch ning lisaks Grails 2.3-e demo async osas.
Peale keynotet jäi veidi vaba aega ja siis hakkas sinna otsa kohe Grails BOF. Pidi kestma tunni aga juttu jätkus nii palju et sain sealt 23:45 alles minema olles täiesti läbi juba. PEamiselt sai räägitud Grails tulevikust, Grails levikust, pluginatest, võrdlusest Railsi ja Djangoga jpm.
Graeme põhisõnum oli et Grails ei ole su YAWF raamistik enam mida siis võrrelda siin php-ga vms. Vaadates kuhu liigub grails 3 (konteinerist välja) ning mida pakub meile GORM (algsest hibernate mapperist on saanud eraldi pluginana täiesti iseseisev moodul mis pakub abstraktsioon täna juba erinevatele andmeallikatele REST-ist kuni MongoDB-ni välja.)
Palju arutati ka muidugi seda, et kuidas Spring arendajatele Grails paremini selgeks teha, kuidas seda sõnumit edasi anda - see et Grails nimetati Spring IO üheks "Runtime" komponendiks oli suur samm edasi.
Täna on Grailsil ka maine poolest palju puudusi kuna endiselt ka versioon 2.x Grailsi seostatakse tegelikult versiooniga 1.x kus oli palju erinevaid vigu mis kasutajat frustreerisid, aga see on miskipärast meeles kõigil. Burt käis eile BOF-is isegi välja mõtte et tuleks nimi ära vahetada.
3.0 tuleb välja järgmise aasta sügiseks. Mainimist tasuks ka veel 2.3 AETHER sõltuvuste raamistik mis täna kättesaadav on, sest see on sama komponent mis maveni kõhus, seega peaks kõiksugused IVY jamad kadunud olema.
Loodan et varsti saab alustada 2.3-ga tööd.
Monday, September 9, 2013
Esimene päev - SpringOne2gX 2013
Spring 4 on väljas. Peamised uuendused on uuendatud async tugi, rest tugi. Toetatud on konfigureerimine Groovy abil.
Spring tutvustas oma uut projekti nimega Boot. Mõte on sarnane Grailsiga - kõikide spring tehnoloogiate ühendamine ühteks RAD platvormiks kasutades springi enda meelest (opionionated) parimaid praktikaid. Kindlasti on see väga oluline ja vajalik samm et springi ennast paremini kasutada, sest siiamaani suurimates probleemideks oli just kogu stacki õieti konfigureerimine (boilerplate koodi loomine) ennem kui sai midagi sisulist arendama hakata.
Siiani oli selleks ainuke mõistlik võimalus Grailsi kasutada või otsida suvalisi koodinäiteid netist, aga nüüd on ka ametlik ja toetatud versioon sellest.
Demos näidati nii Java kui Groovy näidist kuidas Booti kasutada. Groovy näiteks sisuliselt tehti groovy stiilis kontroller mida annoteeriti siis vastava springi @Controller annotatsiooniga ning järgmine hetk oli pilt juba ekraanil - väga sarnane grailis enda põhimõttele, et minimaalselt vaja luua koodi mis suhtleks raamistikuga ja ülejäänu on juba sisuline. Puhas java versioon oli sarnane kus maveni sõltuvustesse määrati spring boot spetsiaalsed klassid ning peale main meetodi defineerimist oli juba võimalik pilt ette saada. Lisaks annab Boot välja ka mitu servletti kust küsida infrastruktuurset infot - millised beanid on defineeritud, palju võetakse mälu, mis on mäppingud, mis on kasutus statisitika jpm - väga asjalik ja kasulik info arendajale ja miks ka mitte haldurile.
Spring ise kutsub nüüd oma tooteperekonda Spring IO-ks. Kus siis alt tuleb raamistik ise, java ja groovy keel, keskel on igasugused integratsiooniraamistikud nagu Spring Batch, Spring JPA, Spring Security ning kõige peal on siis Boot või Grails. Sellega seoses on Spring loonud ka oma tooteperekonnale täiesti uue kodulehe mis täna ka läks kõigi ees Laivi. Spring.io on loodud spring Boot raamistiku peale (kui seda võib nii kutsuda üldse?). Siin on väga tänuväärne et meil on firma kes jälgib põhimõtet "Eating your own dogfood". spring.io on hea tutorialite, uudiste näidistele ja koodile orienteeritud koduleht kus sisuliselt copy paste meetodil saab töötavaid !"Hello world" rakendusi kokku panna kasutades erinevaid tooteperekonna komponente. Igatahes jättis väga hea mulje et on mõeldud ka inimestele kes pole Springiga väga detailselt kodus kuid tahaksid seda proovida ja õppida ning selle asemel et minna StackOverFlowd külastama saavad parimaid näpunäiteid otse allikast.
Lisainfot leiab siit: http://www.datacenterdynamics.com/focus/archive/2013/09/pivotal-launches-spring-platform-spring-io aga antud firma tootis selle kodulehe ja ise kes nad väga peavad lugu oma lihtsuse poolest Ruby on Railsi kiitsid Boot-i produktiivsust ja ütlesid et see on täiesti võrreldav Railsiga ning ka parem kuna koosneb korralikest ja tõestatud komponentidest.
Demo ajal oli juba näha kuidas on erinevate jar-ide näol tekkimas ka Boot-i plugina süsteem. Ei mäleta peast aga näiteks websocketi toeks oli juba üks plugin olemas mis abstrahheerib kogu keerukuse kasutaja eest kes tahab socket stiilis suhtlust kliendiga.
Huvitav kuidas Boot suhestub Grailsi ja Spring Roosse, seda ma tahan kindlasti Graeme käest küsida, sest siin on näha kuidas Grails ja Spring omavahel aina lähedamale tulevad. Grails kasutab oma põhjaks Springi kõiki parimaid komponente kui samas Spring Boot võimaldab kirjutada oma controllereid näiteks groovy süntaksis rääkimata et Spring Core ise toetab nüüd ka konfigureerimist Groovy DSL-iga mis on üks Grailsi põhiomadusi. Eks näis!
Spring.io jookseb Cloud Foundry peal. Tundub et see pilvetehnoloogia läheb aina paremaks ja seda tuleks ehk ka Enterprise kontekstis lähemalt vaadata. Igatahes jooksist spring.io rakendusest kaks versiooni korraga ning reaalajas switchiti siis url ringi nn. ametlikule variandile. Lisaks töötaks ideaalselt multinode koos load balanceriga.
UPDATE: lähiajal antakse spring.io website välja opensource projektina, mida saab kasutada hea reference materjalina kas siis Boot-i õppimisel või isegi lausa alusrakendusena. Eks näis.
Vaatame mis homme põnevat tuleb kui sessioonid pihta hakkavad.
Spring tutvustas oma uut projekti nimega Boot. Mõte on sarnane Grailsiga - kõikide spring tehnoloogiate ühendamine ühteks RAD platvormiks kasutades springi enda meelest (opionionated) parimaid praktikaid. Kindlasti on see väga oluline ja vajalik samm et springi ennast paremini kasutada, sest siiamaani suurimates probleemideks oli just kogu stacki õieti konfigureerimine (boilerplate koodi loomine) ennem kui sai midagi sisulist arendama hakata.
Siiani oli selleks ainuke mõistlik võimalus Grailsi kasutada või otsida suvalisi koodinäiteid netist, aga nüüd on ka ametlik ja toetatud versioon sellest.
Demos näidati nii Java kui Groovy näidist kuidas Booti kasutada. Groovy näiteks sisuliselt tehti groovy stiilis kontroller mida annoteeriti siis vastava springi @Controller annotatsiooniga ning järgmine hetk oli pilt juba ekraanil - väga sarnane grailis enda põhimõttele, et minimaalselt vaja luua koodi mis suhtleks raamistikuga ja ülejäänu on juba sisuline. Puhas java versioon oli sarnane kus maveni sõltuvustesse määrati spring boot spetsiaalsed klassid ning peale main meetodi defineerimist oli juba võimalik pilt ette saada. Lisaks annab Boot välja ka mitu servletti kust küsida infrastruktuurset infot - millised beanid on defineeritud, palju võetakse mälu, mis on mäppingud, mis on kasutus statisitika jpm - väga asjalik ja kasulik info arendajale ja miks ka mitte haldurile.
Spring ise kutsub nüüd oma tooteperekonda Spring IO-ks. Kus siis alt tuleb raamistik ise, java ja groovy keel, keskel on igasugused integratsiooniraamistikud nagu Spring Batch, Spring JPA, Spring Security ning kõige peal on siis Boot või Grails. Sellega seoses on Spring loonud ka oma tooteperekonnale täiesti uue kodulehe mis täna ka läks kõigi ees Laivi. Spring.io on loodud spring Boot raamistiku peale (kui seda võib nii kutsuda üldse?). Siin on väga tänuväärne et meil on firma kes jälgib põhimõtet "Eating your own dogfood". spring.io on hea tutorialite, uudiste näidistele ja koodile orienteeritud koduleht kus sisuliselt copy paste meetodil saab töötavaid !"Hello world" rakendusi kokku panna kasutades erinevaid tooteperekonna komponente. Igatahes jättis väga hea mulje et on mõeldud ka inimestele kes pole Springiga väga detailselt kodus kuid tahaksid seda proovida ja õppida ning selle asemel et minna StackOverFlowd külastama saavad parimaid näpunäiteid otse allikast.
Lisainfot leiab siit: http://www.datacenterdynamics.com/focus/archive/2013/09/pivotal-launches-spring-platform-spring-io aga antud firma tootis selle kodulehe ja ise kes nad väga peavad lugu oma lihtsuse poolest Ruby on Railsi kiitsid Boot-i produktiivsust ja ütlesid et see on täiesti võrreldav Railsiga ning ka parem kuna koosneb korralikest ja tõestatud komponentidest.
Demo ajal oli juba näha kuidas on erinevate jar-ide näol tekkimas ka Boot-i plugina süsteem. Ei mäleta peast aga näiteks websocketi toeks oli juba üks plugin olemas mis abstrahheerib kogu keerukuse kasutaja eest kes tahab socket stiilis suhtlust kliendiga.
Huvitav kuidas Boot suhestub Grailsi ja Spring Roosse, seda ma tahan kindlasti Graeme käest küsida, sest siin on näha kuidas Grails ja Spring omavahel aina lähedamale tulevad. Grails kasutab oma põhjaks Springi kõiki parimaid komponente kui samas Spring Boot võimaldab kirjutada oma controllereid näiteks groovy süntaksis rääkimata et Spring Core ise toetab nüüd ka konfigureerimist Groovy DSL-iga mis on üks Grailsi põhiomadusi. Eks näis!
Spring.io jookseb Cloud Foundry peal. Tundub et see pilvetehnoloogia läheb aina paremaks ja seda tuleks ehk ka Enterprise kontekstis lähemalt vaadata. Igatahes jooksist spring.io rakendusest kaks versiooni korraga ning reaalajas switchiti siis url ringi nn. ametlikule variandile. Lisaks töötaks ideaalselt multinode koos load balanceriga.
UPDATE: lähiajal antakse spring.io website välja opensource projektina, mida saab kasutada hea reference materjalina kas siis Boot-i õppimisel või isegi lausa alusrakendusena. Eks näis.
Vaatame mis homme põnevat tuleb kui sessioonid pihta hakkavad.
Subscribe to:
Posts (Atom)