DPC Consulting

Mike West: Browser-side security

November 14, 2013,

Délelőtt már bele néztünk egy fél security előadásba, ott PMD és Findbugs eszközök demózása volt (a látott részben). Ezzel szemben ez megint egy nagyon jó, informatív, sodró lendületű előadás volt.

Az az alapvetés, hogy előbb utóbb mindannyian elkövetünk hibákat, és előfordul, hogy Cross Site Scripting-et (XSS) megengedő hibát kódolunk az alkalmazásunkba.

We are all idiots with deadlines

Hogy mégis csökkentsük a bajt és védjük magunkat, okos HTTP Headereket használhatunk. Ilyesmikről volt szó:

Ezek használatához persze HTTPS kell, mert ha bárki módosíthatja a kérés/válasz folyamot, akkor nem megyünk sokra a Headerjeinkkel. Tehát a hangsúlyos üzenet valahogy így hangzott:

  1. Használjunk mindenhol HTTPS-t.
  2. Olvassuk el ezt a cikket a Cross Security Policy-ról.

Az előadó azt mondta, hogy ha ez utóbbi megmarad a hallgatóságban, akkor már boldog, mert szerinte ez a legfontosabb. Mi se ajánlhatunk mást…

Aleksey Shipilev: Java Microbenchmark Harness: The Lesser of Two Evils

November 14, 2013,

Zseniális előadás. Azt eddig is mindenki mondta, hogy a microbenchmark veszélyes, de itt pontosan el volt mondva, hogy miért. Az előadó saját bevallása szerint is: elsősorban el akart mindenkit riasztani a microbenchmarkoktól és ez azt hiszem elég jól sikerült neki.

Sorozatosan jöttek a slide-ok, általában egy ártatlannak tűnő kóddal és egy meghökkentő mérési eredménnyel. És mindegyik furcsa mérési eredmény mögött valami kevésbé ismert Hotspot optimalizációs trükk volt. Egyre kevésbé ismert problémák jöttek elő, és a végén már valóban mindenki inkább lemondott volna a microbenchmarkokról, de saját keretrendszer írásáról biztosan. És mindezt nagyon gördülékeny és élvezetes stílusban.

Level 10-nél már az assemblyt is meg kellett nézni:

Untitled

Az előadó az Oracle-nél dolgozik, ahol a Java Microbenchmark Harness-t (JMH) ebben az évben nyitották meg. Elég meggyőzők voltak a mélységei. Eddig ebben a mezőnyben én a Google féle Calipert ismertem, de most arról is kiderültek érdekes dolgok. Ahogy mondta, ha valami furcsa eredmény érkezik hozzá általában először megnézi JMH-val, és ha más az eredmény, akkor már csak az a kérdés, hogy mi volt rossz az eredeti tesztben…

Untitled

Ezt az előadást nagyon ajánlom mindenkinek, aki ilyesmiben töri a fejét, vagy ha valaha lemert írni a blogján olyat, hogy egyik Java megoldás gyorsabb mint a másik. Elvileg a JVMLS-en is lement már, szóval lehet hogy meg lehet találni valahol a interneten, a Devoxx videók általában egy év után lesznek publikusak (Addig előfizetéssel lehet nézni őket a parleys-en.)

Peeter Veentjer: Distributed Systems using Hazelcast

November 14, 2013,

Egyszer indítani fogok egy olyan sorozatot, ahol a szépen megmunkált Java librarykról fogok írni. Mindig öröm olyan alkalmazással találkozni, amin látszik a gondos kezek munkája. A Hazelcast, amit szintén régóta kerülgetek már, pont ilyen. Kicsi, egyetlen Jar file, egyszerű api, okos defaultok, és jól lehet hangolni nagyon sok részletét. Mintha olyan fejlesztők gondoznák akik használják is.

Maga a Hazelcast a NoSQL világ datagrid osztályához tartozik, ahol pl. a Gigaspaces vagy a Coherence is versenyez. Csak ez Open Source és ingyenes (support elérhető). Aki nem látott még ilyet az leginkább egy nagyon elosztott ConcurrentHashMap-re kell, hogy gondoljon. Meg persze emellett még BlockingQueue-ra, Topic/Subscriber-re, valamint bármilyen saját adatszerkezetre (ugye szépen kiterjeszthető).

Untitled

Mindez nagyon sok ügyes extrával:

Nem véletlen, hogy sok Open Source pojekt használja a felszín alatt.

Untitled

Shape the future of the web development

November 14, 2013,

A mai napot a Google kezdte egy keynote-tal. A szerény és visszafogott cím igazából Dart demót és promót takart.

We put closures from the beginning. (And it was not that hard).

A magam részéről még kissé szkeptikus vagyok. Vagy mondjuk úgy, hogy kivárásra játszom. A Google részéről teljesen logikus lépés házon belül nyelveket gyártani és azt használni, de hogy a világnak is ez-e a legjobb, azt nem tudom. Rossznak nem tűnt rossznak, sokat bizonygatták, hogy mennyire megy már minden IDE-ből, lehet debugolni, stb. Mondjuk a programfejlesztés nem csak ezekből áll, ha kinyitjuk a Javascript ajtót rögtön ránk ömlik a rengeteg megoldás: teszt framewörköktől kezdve, code quality eszközökig, build toolokig. Nyilván ehhez kell, hogy a Dart elérje a kritikus tömeget.

Untitled

Mindenesetre azt megtudtuk, hogy a Dart már körülbelül olyan gyors mint a js. (Ez a dartból fordított js-re vonatkozik. Dart VM egyelőre csak chromium dev buildben van, arra még egyelőre nem lehet építeni). Volt néhány demó is, ahol az adoptálók nagyon elégedetten nyilatkoztak a produktivitásról.

Untitled

Azért én még elviseltem volna némi technikai low-level összevetést, hogy jobban meggyőzzenek. Mert így mindig az a régi tweet motoszkál a fejemben, hogy szép és jó ez a sok 2js compiler, de nem lett volna egyszerűbb megtanulni rendesen a Javascript-et mindenkinek? Persze értem én, hogy itt VM szinten azért komolyabb kérdések vannak: az előadó 27 éve OOP-s nyelvek VM-jeit hegeszti, beleértve a hotspotot is, nyilvan ott az ördög a részletekben. Csak erre sajnos nem tért ki a keynote.

Devoxx 1. nap vége

November 13, 2013,

Estébe kanyarodott az első nap, a végén még néhány maradék mondás, ami a folyosó padlószőnyegéról összejött:

Tim Fox: Introducion Vert.x 2.0

November 13, 2013,

Már rég várok rá, hogy valaki meggyőzzön a vert.x-ről és ezt ez az előadás abszolút hozta.

Ahogy az előadó mondta node.js for JVM-nek szokták hívni, és a hasonlóságot nem is tagadta, de ez gyorsabb annál és ugye több nyelvet is beszél.

Azért vannak nyitott kérdések. Az eventbuson csak egyszerű dolgok közlekedhetnek (a JSON a preferált, de ekkor ugye rámegy majd az idő egy része a parzolásokra). És az üzenetküldés se garantált, tehát a saját alkalmazásunkat kell erre valahogy felkészítenünk. De mindenesetre nagyon ígéretes. Mindenképpen használni szeretném majd valamihez.

Untitled

Remi Forex - What Java EE can learn from dynamic languages?

November 13, 2013,

Remi Forex ott folytatta körülbelül, ahol Brian Goetz abbahagyta, igaz sokkal kevésbé lehengerlő, inkább kicsit döcögősebb stílusban.

De hogyan tudna profitálni a Java EE az invokednyamics használatából? A példa egy hibernate és egy spring exception tree volt, amik tele voltak saját és dinamikusan generált proxykkal, ami a saját Java EE kódunk köré kerül. Ilyet mindenki látott már, nagyon sok framework dolgozik proxykkal.

Az előadás részletesen végigment azon, hogy hogyan működik egy nagyon egyszerű (Java EE) konténer, miért használnak végtelen sok proxy objektumot, és ebből mit tud a JVM kipotimalizálni.

Az invokdedynamics-okkal ezeket a végtelen proxy hívásokat el lehetne kerülni. És mivel az invokedynamics tudja cache-elni azt, hogy hogyan is kellene az adott helyen meghívni egy funkciót, ezért sokkal rövidebb és gyorsabb gépi kódot kaphatnánk. Ebben a felfogásban a Java EE nem is konténer a klasszikus értelemben, hanem egy compiler, mert ha ügyes invokedynamics hívások kerülnének a kódba, akkor nem lenne arra szükség, hogy egy konténer elemei ékelődjenek a saját kódunk metódhívásai közé (pl. egy nem lenne szükség proxyra két EJB hívás között). Hasonlóképpen dependency injection-höz vagy lombok szerű getter emulálásra is az invokednyamics lehetne a megoldás.

Maga az alapötlet nem volt rossz, de az előadás belefért volna egy rövidebb előadásba is. (Na jó, akkor lemaradtunk volna néhány szép assembly kódról).

Brian Goetz: A peek under the hood

November 13, 2013,

Brian Goetz a keynote alatt olyan meggyőző volt, olyan jó olajos kezű munkás embernek tűnt, hogy beültem az előadására is. Nem bántam meg.

Az előadás nem a konkrét használatról szólt, hanem, hogy JVM szinten hogy oldották meg a Lambda Expressionök (LE) használatát (és miért úgy).

A két nagy döntés, hogy mi legyen a típusa az LE-knek, és hogyan reprezentálja őket a JVM. Mindenhol szóba került az obvious but wrong megoldás is.

Típus szinten lehetne külön nyelvi elemet, byte code műveletet bevezetni rájuk, de ez sok mindent felforgatna (obvious but wrong). Végül típus szinten functional interface ként kell tekinget rájuk, amik leginkább a Runnable szerű egy metódusú interface-ek örökösei.

Reprezentáció szinten is sok kerülő út jön számításba. Pl. lehetnének annonymous inner classok, de ekkor rengeteg példányosításra lenne szükség. Implementációban végül a dinamikus nyelvek kedvéért bevezetett invokedynamics-ra esett a választás. Itt a hagyományos invoke… bytecode művelett helyett egy külön kódot lehet definiálni, ami megmondja a JVMnek, hogy mit hívjon meg. LE-k esetén egy speciális MethodFactory-ra lehet hivatkozni, ez annak a kódnak a szimbolikus neve, ami implementáció függően meg mondja, hogy mit hívjon meg a JVM egy új Lambda expressiont látva. A mit az lehet akár annonymous inner class vagy generált osztály, bármi. A szép a megoldásban is, hogy ez nem dől el a bytecode-ban, hanem csak a JVM implementációban ezért később változhat is. És pontosan ezért a LE-ök gyorsabbak lesznek az inner classoknál. Ott a byte code implementáció kötött, de itt dinamikus. Már a mostani implementáció is sokszor gyorsabb, de rajta vannak a témán, hogy elkezdjék optimalizálni.

Untitled

Mindez egy nagyon dinamikus lehengerlő előadói stílusban.

Keynoteok

November 13, 2013,

Az Oracle részéről Mark Reinhold kezdte a Devoxx keynote-ot. Még egy piros pontot is összeszedett tőlem, mert (amire nem számítottam) már az első 5 slide-on volt forráskód.

Aztán Brian Goetz folytatta természetesen a Lambda Expressionökkel. Illetve először 1995-től kezdte, hogy kontextusba helyezze a Java történetét. És azt kell mondjam, hogy bármennyire is szkeptikus a természetem, nagyon meggyőzően beszélt a Java nyelvvel kapcsolatos döntésekről (sűrűn emlegetve James-t). Például az egyik mondás:

Reading core is more important than writing code.

És ha belegondolok, akkor ez – még ha lehet is rajta vitatkozni – egy érvényes hozzáállás. És ha ez az alapvető hozzáállásunk, akkor sokkal érthetőbb, hogy a Java miért olyan lomhán fejlődik, vagy hogy miért nem követi pl. a Scala útját. Ha elfogadjuk, hogy többször olvassuk a kódot mint írjuk, ezért a kód olvasása fontosabb, akkor azt is el kell fogadunk, hogy ebből a szempontból a Java-nak kétségtelen az előnye pl. a Scala-val szemben, amelyik inkább a frappánsabb leírásban erős, nem az egyszerű olvashatóságban.

Aztán persze jöttek a lambda expression-ök.

int heaviestGuy = people.ParalllelStream().filter(p -> p.getGender() == MALE).mapToInt(Person::getWeight).max();

És egy másik példa is az alapvetetések követésére: az tagadhatatlan, hogy a Java elég erős a visszafelé kompatibilitásban. Ha önmagában nézem azt a Java8 újítást, hogy default implementáció-kat adhatunk az interface-ekhez, akkor elég vegyesek az érzéseim. De ha az az kérdés, hogy hogyan lehet kiterjeszteni a Collection interface-t a fentiekkel a kompatibilitás megtörése nélkül, akkor már sokkal inkább egy ésszerű kompromisszumnak tűnnek az interface-be ágyazott kód darabkák

A Whats next szekcióban felmerül pl. a “value types”. A Java-t sokszor kritizálják, hogy nem minden objektum, hanem vannak primitív típusok. Brian szerint ezek épp hogy jók, csak az a baj, hogy nem lehet saját primitív típusokat definiálni. Ha lehetne ilyeneket, és pl. object header nélkül használhatnánk pehelysúlyú saját primitív típusokat is, akkor sok minden előtt megnyílnia az út, pl. lehetne Tuple-eket tisztességesen implementálni.

Ezek után jött Richard Bair és Stephen Chin, akik elhozták a JavaOne-on is demózott kütyüket. Egy Raspberry Pi alapú sakk robotot és egy Raspberry Pi (RPI) alapú home-made tabletet (DukePad). Ügyes kis kütyük kis döccenőkkel a demó is ment, mindegyiken Java fut.

Én a magam részéről kicsit szkeptikus vagyok a RPI-vel kapcsolatban. Az előadásban is felmerült, hogy egy RPI CPU ereje kb. tizede egy Samsung Galxy S4-nek. Viszont alig drágábban mint az RPI lehet kapni elég jó – akár a Samsung S4-es processzorokhoz is mérhető – ARM processzoros paneleket, amik még nyitottabbak is, csak kevesebb a hype körülöttük.

Továbbá az Internet of things dolgokra sokszor elég egy AVR (Arduino) vagy PIC. Amik nagyásgrendileg 2-8 dollárba kerülnek, és bár C-ben kell programozni, de Real Time dolgokra sokkal alkalmasabbak mint a Linux alapú RPI. Pl. egy I2C busz implementációt sokkal könnyebb szerintem C-ben programozni, mint Linux-ban debugolni, hogy a GPIO-k időzítése a kernelben és az APIn keresztül hol tart. Nem is beszélve, hogy AVR alapú kütyük akár egy évig elmennek egy gomb elemről…

Ennek ellenére, az RPI alapú Java nem felesleges erőfeszítés, mert ha RPI-n már fut elfogadható sebességgel a JVM, akkor a komolyabb ARM processzorokon is lesz értelme használni. (Más kérdés, hogy pl. egy szintén fillérekért kapható MIPS alapú házi routeren nem tudom, hogy mikor lesz JVM. Valószínű NodeJS hamarabb fog mindenhol futni.)

Untitled

Kezdődik a show

November 13, 2013,

A negyedben ahol aludtunk a villamos még kaftános kalapos munkába siető zsidókkal volt tele a villamos, de ahogy egyre haladtunk kifelé a város szélén lévő mozi komplexum felé, egyre nagyobb lett a laptop táskás tömeg a villamoson. A végére már minden Budapesten tanult praktikát be kellett vetni, hogy fent maradjunk

Aztán kiérkeztünk a város szélére. A hatalmas regisztrációs sort viszonylag jól kezelték, és akkor már csak a keynote terem előtt lévő hatalmas tömegen kellett átszivárogni, hogy leüljünk a hatalmas moziteremben.

És ahogy lépésben mentünk befelé bentről már dübörgött az elektronikus zene. Még néhány méter és bent a mozi teremben:

Untitled

Hatalmas kivetítő, dübörgő zene. Balra kivetítve a színpadon a két működő DJ, balra valami kód illusztrációkén. Várjunk csak, nem is illusztráció. Lassan kiderült, hogy a két DJ realtime Clojure kódot szerkeszt, és a kód adja ki a zenét, ami dübörög. Live Clojure, live zene. Így kell indítani egy Java konferenciát.

JavaBar prezentációk

November 13, 2013,

Miközben mi már Antwerpenben készülünk a holnap induló Devoxxra (pontosabban University rész már két napja megy, holnap a konferencia kezdődik), szeretettel ajánljuk mindenki figyelmébe, hogy az eddigi JavaBar minden prezentációja elérhető a meetupos oldalról. (Kicsit el van dugva, a Discussions alatt van egy Konzerv anyagok szekció, ahol megtalálhatóak a linkek.) Például Varga Patrik legutolsó JavaEE7/Java8 fóliái is letölthetőek. Kíváncsian várjuk, hogy holnap délelőtt Mark Reinhold tud-e a Patrik után valami újat mondani a Java 8-ról ;-)

A prezentációk egyébként a legkülönbözőbb rendszerekkel készültek (impress.js, reveal, prezi, LibreOffice, …). Az aktuális módszer a PDF konverzióra, hogy az egzotikusabb prezentációkból screenshotokat készítünk, és azt rakjuk be egy PDF-be. Emiatt kicsit pixeles lehet némelyik PDF, valamit a mérete is 20-30 Mbyte, viszont legalább PDF-ben terjeszthető. A screenshotokat linux alól készítjük, a watch -n 5 parancs öt másodpercenként meghív egy scriptet, amiben a scrot készít egy screenshotot a beep pedig pittyen egyet jelezve, hogy lehet tovább lapozni. A kész képeket, pedig imagemagick-el méretezzük át és fűzzük össze PDF-be. Nem túl elegáns, de praktikus megoldás, ami például a prezi saját PDF exportjánál is hatékonyabbnak bizonyult…

Devoxx.be 2013

November 11, 2013,

Európa két meghatározó Java konferenciája a Devoxx és a Jazoon. Ezek közül a Devoxx az öregebb, még 2001-ben kezdték el szervezni JavaPolis néven (amit azt hiszem korporét jogi problémák miatt neveztek át). Közben elindult a Jazoon is Zürichben a Devoxxnak meg a belgiumi rendezvényen kívül lett londoni és párizsi testvére is. De az eredeti belgiumi rendezvény is még mindig nagyon népszerű, általában két-három hét alatt elkapkodják az összes jegyet.

A népszerűség okait sokféleképpen lehet magyarázni. Egyrészt ez volt az egyik legnagyobb európai (Java) konferencia. Másrészt valószínű az is segített, hogy itt a belga Java User Group (illetve annak a főszervezője) állt a háttérben, tehát sosem volt elsődleges semmilyen nagyvállalati szempont. Mondják azt is, hogy az segített, hogy eredetileg nem volt Call For Papers, azaz nem lehetett jelentkezni előadásokat tartani, hanem a szervezők hívták meg a jónak ítélet előadókat, és ezáltal már nagyon korán egy elég minőségi tartalmat tudtak mutatni.

Mindenesetre a következő napokban mi is ott leszünk az idei belgiumi Devoxxon és terveink szerint részletesen beszámolunk mindenről, ami kicsit is izgalmas lehet Javás szemmel. Reméljük kiderül, hogy még mindig olyan tartalmas-e a konferencia, mint amennyire beszélik…

Javabar

November 3, 2013,

Most szerdán újra JavaBar:

Trendek és távlatok a Java világából

Előadó: Varga Patrik, aki nemrég ért haza a JavaOne konferenciáról

Az előadásban szó lesz a mainstream Java technológiák jelenlegi és jövőbeni helyzetéről, többek közt:

Mindez JavaOne élménybeszámolóval színesítve: személyes élmények a világ legnagyobb Java konferenciájáról első kézből.

És természetesen lesz kávé (Java)!