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.

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.