Hetkel kõige rohkem endale huvipakkuv arendusraamistik on kahtlemata Grails, mis asub grails.org aadressil. Antud raamistik arendus käib kahes vaates.
On nn. tuumikmeeskond, kes tegeleb raamistiku tuuma enda arendamisega ning sellele lisaks kõige olulisemate lisade arendamisega. Nemad on eraldi firma palgal ja tööks ongi selle raamistiku arendamine.
Selleks et raamistik oleks elujõuline ja areneks edasi kiiremini, kui seda antud meeskond suudaks pakkuda, on loodud kõigile kätttesaadav vigade ja parenduste jälgimise keskkond JIRA https://jira.grails.org/browse/GRAILS, kuhu saab saata vigu koos testidega, teha ettepanekuid uute võimaluste jaoks jpm, kommenteerida ja muidu aidata kaasa süsteemi arenemisele.
Kes aga soovib konkreetselt koodi kirjutada ja muudatusi keskele saata, kus nad peale koodi ülevaatust võibolla sisse võetakse, saab seda teha edukalt siin: https://github.com/grails.
Teine lähenemine mida antud ökosüsteem pakub on nn. pistikute arendamine. Kui muidu on ettenähtud et tuuma ja sellega seotud lisade arendamisel tuleb vigu hallata ettenähtud keskkonnas, koodi saata ettenähtud keskkonda ning oodata seal selle heakskiitu või tagasi lükkamist, siis pistikute arendus näeb välja teistsugune.
Kui sul on mingi mõte mõnest funktsionaalsusest ja leiad et seda võiks jagada teistega, pole vaja muud kui teha lähtekood kättesaadavaks kõigile ning olla samas ise seal selle haldur ja muudatuste vastuvõtja, pakkuda enda personaalset vigadehaldus keskkonda kus kasutajad saavad ise sinuga suhelda ning loomulikult luua ka enda dokumentatsiooni lehekülg.
Kui vastavad tingimused on täidetud, siis on võimalik vastav kood teha kõigile kättesaadavaks siin http://grails.org/plugins/ ja oodata tagasisidet ning jälgida statistikat. Antud keskkonnas kirjeldatud pistikud ei ole garanteeritud kvaliteediga vastava raamistiku tuuma arendava firma meeskonna poolt, küll aga seal on võimalik kogukondlikult nende kvaliteeti tõsta ja igaüks võib saada väga lihtsasti osa kommuunist.
Tuesday, May 6, 2014
Thursday, April 10, 2014
OpenOffice kasutamine
Kui enamasti olen vaba tarkvara osas kasutanud pakkimisprogramme ja pildi vaatamise programme mis olid oma olemuselt väga lihtsad ja mugavad siis aastaid tagasi tekkis vajadus ülikooli lõputööd kirjutama hakata. Kuna enamus tööd tuli kirjutada õhtuti kodus ja ei saanud kasutada tööl olevat MS Wordi ja Excelit ning loomulikult polnud mul plaanis hakata selle jaoks MS Office litsentsi osta, tekkis mõte katsetada kas saab oma lõputöö kirjutada täielikult mõnes vabavaralises tarkvaras.
Kuigi OpenOffice oli sel hetkel alles oma esimeses versioonis (1.1 kui täpne olla), sisaldas ta ju täiesti kõik seda mida teksti kirjutamiseks on vaja ning oli olemas isegi stiilide tugi, mis võimaldas kenasti peatükkidele oma stiilid külge panna ja nende alusel sisukorda genereerida.
OpenOfficet kasutasin töö kirjutamiseks ca pool aastat ja kogu töö sujus kenasti, algul tundus et programm on veidi uimasem kui seda oli Word, kuid mida aeg edasi seda rohkem harjusin seda kasutama. Ei häirinud isegi see veidi arhailisem väljanägemine, sest funktsionaalsus töötas kenasti ja seda polnud seal niipalju kui vastava aja Word 2003 juba sisaldas, seega kõik vajalik oli kenasti leitav.
Töö sai kenasti ära vormistatud ning esitatud ja peale seda intentiivsem OpenOffice kasutamine lõppes, kuigi aegajalt tuli mõne tuttava saadetud Wordi failide avamiseks seda kasutada, polnud seda sellises mahus enam vaja kasutada ja tööl oli keskkonna tõttu ikkagi MS tooted kasutusel.
Täna uuesti koolis käies ja koolitöid vormistades peab tõdema, et Apple poolt uutele Mac omanikele tasuta pakutav Pages ja Numbers tooted on oluliselt kiiremad, mugavamad ja ilusamad kui OpenOffice, aga peamiselt võluvad ka just oma lihtsusega, mida OpenOffice pakkus juba 10 aastat tagasi.
Kuigi OpenOffice oli sel hetkel alles oma esimeses versioonis (1.1 kui täpne olla), sisaldas ta ju täiesti kõik seda mida teksti kirjutamiseks on vaja ning oli olemas isegi stiilide tugi, mis võimaldas kenasti peatükkidele oma stiilid külge panna ja nende alusel sisukorda genereerida.
OpenOfficet kasutasin töö kirjutamiseks ca pool aastat ja kogu töö sujus kenasti, algul tundus et programm on veidi uimasem kui seda oli Word, kuid mida aeg edasi seda rohkem harjusin seda kasutama. Ei häirinud isegi see veidi arhailisem väljanägemine, sest funktsionaalsus töötas kenasti ja seda polnud seal niipalju kui vastava aja Word 2003 juba sisaldas, seega kõik vajalik oli kenasti leitav.
Töö sai kenasti ära vormistatud ning esitatud ja peale seda intentiivsem OpenOffice kasutamine lõppes, kuigi aegajalt tuli mõne tuttava saadetud Wordi failide avamiseks seda kasutada, polnud seda sellises mahus enam vaja kasutada ja tööl oli keskkonna tõttu ikkagi MS tooted kasutusel.
Täna uuesti koolis käies ja koolitöid vormistades peab tõdema, et Apple poolt uutele Mac omanikele tasuta pakutav Pages ja Numbers tooted on oluliselt kiiremad, mugavamad ja ilusamad kui OpenOffice, aga peamiselt võluvad ka just oma lihtsusega, mida OpenOffice pakkus juba 10 aastat tagasi.
Friday, March 14, 2014
Blogimine kui asutusesisene teadmiste jagamine
Suurtes IT-ga tegelevates organisatsioonides tihtipeale ei jõua igapäevaselt presentatsioonidea tutvustusi või koolitusi korraldada (aega on vähe ja vähemalt 1 tunnine esitlus nõuab vähemalt 1 päevast ettevalmistust), lisaks on vaja kõik inimesed sobival ajal kohale saada.
Küll aga on reaalne vajadus pidevalt uusi lahendusi, suundi või kogemusi tutvustada, jagada ning selleks e-posti kanali kasutamine ei toimi, sest see enamasti "upub" saja teise igapäevase kirja vahele ära ja inimesed lihtsalt kas ei pane tähele seda või neil pole aega seda antud hetkel lugeda, hiljem on see info juba kadunud. Seda enam et tagasisidet anda, nii et kõik seda näeksid eeldaks kõigile teistele töötajatele ka koopia saatmist mille võiks kvalifitseerida juba spämmimiseks.
Milline oleks siis efektiivne võimalus oma teadmised lühikese ajaga soovijateni viia?
Kindlasti on siin võimalus kasutada näiteks asutuse siseveebi või wikit, aga need on enamasti pigem ametlikumad ja struktureeritumad, seega konkreetse isiku personaalsemaks kanaliks võiks olla hoopis blogi.
Blogi on konkreetse isiku oma ja väljendab otse tema arvamust, seega koolitamiseks ja isiklike kogemuste ja teadmiste edasiandmiseks võiks see kõige paremini sobida. Enamus blogimootoreid sisaldab ka kommenteerimise võimalust, seega saab alustada asjast huvitatutega diskussiooni, ilma et see risustaks teiste kaastöötajate postkasti.
Blogi võib pidada avalikult internetis, kui info pole salajane, aga võib ka samas konfidentsiaalsema info puhul luua sisevõrku oma blogileht. Kes kasutavad asutuse sees näiteks Atlassiani Confluence nimelist wiki-toodet, siis see toetab igale registreeritud kasutajale blogi loomist väga lihtsasti.
Autor ise siiani blogi pole pidanud, vaid on üritanud eelpool mainitud kanalites oma infot edasi anda (epost ja wiki), kuid näha on et need pole siiamaani väga efektiivsed olnud ja plaan on edaspidi mitteformaalset infot mis alles hakkab oma kuju võtma ja vajaks pigem rohket tagasisidet just siseblogina hakata edastama.
Esimese blogipostituse (martjarvi.blogspot.com) tegin eelmise aasta sügisel kui sai käidud USA-s Spring arendajate konverentsil, kus üks tööülesanne oli koju ära tuua kõik olulised teadmised ja infokillud. Mõtlesin pikalt, kuidas seda efektiivselt teha, sest kuni siiani tegin kokkuvõtteid siis kui reisidelt tagasi, aga siis alati palju detaile läks kaotsi kuna lihtsalt kõike ei mäletanud. Seekord üritasin blogi pidada iga päeva õhtul kui konverents läbi ja teadmised värsked.
Tagasiside oli kaastöötajte poolt väga positiivne sest info oli detailne ning neile meeldis mõte, et nad said lugeda infot juba siis, kui ma alles reisil olin (ajavahe tõttu neil oli mugav alati hommikul tööle tulles näha minu eelmise päeva sündmuste kokkuvõtet).
Küll aga on reaalne vajadus pidevalt uusi lahendusi, suundi või kogemusi tutvustada, jagada ning selleks e-posti kanali kasutamine ei toimi, sest see enamasti "upub" saja teise igapäevase kirja vahele ära ja inimesed lihtsalt kas ei pane tähele seda või neil pole aega seda antud hetkel lugeda, hiljem on see info juba kadunud. Seda enam et tagasisidet anda, nii et kõik seda näeksid eeldaks kõigile teistele töötajatele ka koopia saatmist mille võiks kvalifitseerida juba spämmimiseks.
Milline oleks siis efektiivne võimalus oma teadmised lühikese ajaga soovijateni viia?
Kindlasti on siin võimalus kasutada näiteks asutuse siseveebi või wikit, aga need on enamasti pigem ametlikumad ja struktureeritumad, seega konkreetse isiku personaalsemaks kanaliks võiks olla hoopis blogi.
Blogi on konkreetse isiku oma ja väljendab otse tema arvamust, seega koolitamiseks ja isiklike kogemuste ja teadmiste edasiandmiseks võiks see kõige paremini sobida. Enamus blogimootoreid sisaldab ka kommenteerimise võimalust, seega saab alustada asjast huvitatutega diskussiooni, ilma et see risustaks teiste kaastöötajate postkasti.
Blogi võib pidada avalikult internetis, kui info pole salajane, aga võib ka samas konfidentsiaalsema info puhul luua sisevõrku oma blogileht. Kes kasutavad asutuse sees näiteks Atlassiani Confluence nimelist wiki-toodet, siis see toetab igale registreeritud kasutajale blogi loomist väga lihtsasti.
Autor ise siiani blogi pole pidanud, vaid on üritanud eelpool mainitud kanalites oma infot edasi anda (epost ja wiki), kuid näha on et need pole siiamaani väga efektiivsed olnud ja plaan on edaspidi mitteformaalset infot mis alles hakkab oma kuju võtma ja vajaks pigem rohket tagasisidet just siseblogina hakata edastama.
Esimese blogipostituse (martjarvi.blogspot.com) tegin eelmise aasta sügisel kui sai käidud USA-s Spring arendajate konverentsil, kus üks tööülesanne oli koju ära tuua kõik olulised teadmised ja infokillud. Mõtlesin pikalt, kuidas seda efektiivselt teha, sest kuni siiani tegin kokkuvõtteid siis kui reisidelt tagasi, aga siis alati palju detaile läks kaotsi kuna lihtsalt kõike ei mäletanud. Seekord üritasin blogi pidada iga päeva õhtul kui konverents läbi ja teadmised värsked.
Tagasiside oli kaastöötajte poolt väga positiivne sest info oli detailne ning neile meeldis mõte, et nad said lugeda infot juba siis, kui ma alles reisil olin (ajavahe tõttu neil oli mugav alati hommikul tööle tulles näha minu eelmise päeva sündmuste kokkuvõtet).
Thursday, September 12, 2013
Neljas päev - SpringOne2gx 2013
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 :)
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 :)
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.
Subscribe to:
Posts (Atom)