jTechnics

Christina Lau: BPM 2.0 – A REST based architecture for next generation workflow management

Thursday, December 11th, 2008 | Devoxx | No Comments

Megvilágosodni jöttem erre az előadásra, hogy ezt a business process management nevű dolgot hogy kell elképzelni.

“Everything as a Service – What are we talking about? The Wikipedia defines Service as ….”

Az ilyen fóliákbál derül ki mindig, hogy nem én vagyok az előadáshoz a legjobb partner. Show me the code! Show me the machine!

“Allow organizations to build their first BPM apllication with zero IT overhead and show immediate business value.”

Na jó, csak türelmetlen voltam: Target scenarios and Applications:

• Vacation request
• Expense Statement
• Issue tracking
• Pricing udpate database
• Travel request approval
• Time or project reporting
• Onbarding new employees

És ezek szépen megrajzolva is, már érzem a megvilágosodás előszelét.

Az egész szép webes cucc, bele kell dobálni a elemeket, összekötni és ámen (mi van, ha nincs ott, amit be akarok dobni?).

Csoda demó: van egy google calendar, amibe események vannak tárolva (tenisz meccsek), és webes felületen létrehoztunk egy formot, ahol új tenisz meccsre lehet időpontot foglalni. Kitöltés után ellenőrzi a google calendar-ban, hogy szabad-e az időpont, ha nem, akkor behozza az ütköző esemény időpontját, ha szabad, akkor foglal a calendar-ban, küldd twitter üzenetet, és behozza a calendar havi nézetet.

Mos van szó, hogy activitykkal ki lehet terjeszteni: 1 class plusz 1 XML.

A végén meg nagyon megmondós Summary.

(Ilyen rögtön a laptopba jegyzetelni.)

Tags: bpm, ibm

Jeanfraoncis Arcand: Introduction NIO2

Thursday, December 11th, 2008 | Devoxx | No Comments

Az AIO = NIO2 nagyszerűségéről hallhattunk mondatokat. Az alapállítás, hogy a NIO1-hez képest sokkal könnyebb használni, nem leszünk annyira kiéhezve a frameworkokra (MINA, Grizzly, stb.)

Az előadás felhőtlen élvezetéhez NIO1 expertnek kellett volna lennem (ahogy nagyon nem vagyok az). Azt azért megtanultam, hogy hogy kell dead lock-ot implementálni (a Completion Handler-ben kell várni valami eseményre, és nem visszatérni gyorsan). És a dallama iis egész jól kiderült a végére, meg az, hogy hiába lett egyszerűbb a NIO Api, ezért rengeteg kedves gödör van amire bele lehet esni, hogy ha gondolkodás nélkül használunk (pl. a fent említett dead lock). Az előadásban ilyen gödröket kerülgettünk és láttuk a Grizzly megoldásait (az előadó a Grizzly fejlesztője).

Örültünk még egy fólián a NIO2-vel érkező File I/O System API-nak is (pl. van benne könyvtár figyelés új fájlokra, és nem kell ezt se külön kitalálnunk) és a  a végén még megmérkőzött a Grizzly NIO1-es és NIO2-es változata. (JDK 7-en). Nem sokkal, de az NIO2-es gyorsabb volt. Nem lett tehát sokkal gyorsabb (a NIO1-hez képest) csak egyszerűbb az élet.

Tags: aio, nio

Jason van Zyl: Efficient Enterprise Builds

Thursday, December 11th, 2008 | Devoxx | 2 Comments

Gyakorlatilag Maven-es előadás, Maven és közel álló eszközökről: m2eclipse, tycho, maven, hudson, nexus.
A (számomra) érdekes rész a következő Maven kiadásról szóló fóliák voltak (Eclipset aktuálisan nem használok, Hudsont meg úgyis, Nexus telepítése todo listán) Rengeteg kisebb változás (versionless parent element, XML POM fromat with attributes), és rengeteg alapvető dolog: teljesen újraírt komponensek, teljesen kicserélhető részek, okosabb pluginelhetőség, mixinek stb.

Elég ígéretesnek tűnt, bár csak egy részét sikerült az újdonságokat felfogni. (A demó sajnos nem a részek közt volt, mert az laptop nem bírta a váltogatásokat). Néhány bejegyzéssel azelőtt pont azt némi ügyes kiterjeszthető hookot, és jól átgondoltásgot hiányoltam a Maven-ből,  úgy tűnik meg fogom kapni.

Tags: build, maven

Csütörtök keynote

Thursday, December 11th, 2008 | Devoxx | No Comments

Joshua Bloch: Effective Java Reloaded

A nemrég megjelent Effective Java 2dn edition-ból mesélt el néhány fejezetet. Én néhány fejezetet olvastam eddig a könyvből. Azok alapján azon kevés műszaki könyvek közé tartozik, érdemesnek találok megvenni. Bár a fejezetek legalább felében ismert dolgokról beszél, azokat ügyesen foglalja össze, és érdekesen meséli el, és azért mindenhol előkerül egy-egy ügyes trükk.

Ilyen volt az előadás is: nagy része ismert, da az is izgalmasan előadva, másik részében ügyes trükkök. 5-6 fejezez  Generics, Enum és Lazy initialization témakörben.

Mark Reinhold: The Modular Java Platform

Eredetileg Java SE 7 Update lett volna az előadás alkalmazkodott a pár napja bejelentett változásokhoz (JSR-277 helyett Jigsaw)

Felvezetés: Egy helló world akalmazás 77ms alatt indul el (vs. python 7s) és 332 osztályt tölt be.

Elmondta, amit már a blog-postban is olvastunk: két szintű modularitás: a JVM is modulokból áll, és a java alkalmazás is. JSR 277 hold állapotú lett, JSR-294 még él.

És még néhány jegyzet a fóliákról (olyan szép pontokba voltak, muszáj volt néhányat leírnom)

Project Jigsaw:

• simple
• low level
• interoperable with OSGi
• no JSR (nem Java SE része lesz, hanem a Sun-os JDK-é)
• available for developer use
• developed in the open

JAVA 7 újdonságok:

Features from Sun:

• Modularization (JSR 294 plusz Jigsaw)
• JSR 292: VM support for dymanic languages
• JSR 203: More New I/O APIs (NIO2, File System API)
• JSR TBD: Small language changes (Safe rethrow, null dereference exceptions, type inference, multi-catch) Ezekről szavazni is lehet egy új whiteboard-ön a folyosón
• 6u10 features: Java Kernel, Quickstarter, New Plug-in

Kis változások:

• Stream Control Transmission Protocol
• Sockets Direct Protocol
• Method to close a URLClassLoader
• Unicode 5 support
• XRender pipeline for Java2D
• Swing cuccok: JXLayer, DatePicker, és talán CSS styling

Sebesség:

• HotSpot még okosabb
• G1 garbage collector
• Compressed-pointer 64-bit VM
• talán: MVM – lite (Multiple Virtual Machnie)

Features from others:

• JSR 308: Annotations on Java Types (több mindenre lehet majd annotációkat használni. Pl. @Override mintájára @NonNull annotáció, ami statikus ellenőrzéséket implikál).
• Concurrency and collections update

NEM lesz benne (várhatóan)

• Closures (nincs megállapodás benne)
• Külső proposálok, amit túlságosan drága lenne megcsinálni: pl. Operator overloading, Bug Decimal syntax, First-class properties
• JSR-295: Beans Binding (JavaFX-ben van binding, nem akarnak másikat is)

Várható időpont: Early 2010 (ehhehh, úgyis a JavaOne-ig fog csúszni

Másik személyes megjegyzés: kicsit úgy tűnt, hogy a túl nagy közösségi közreműködés, és a sok ötlet már-már ellehetetlenítette a Java7 kiadását. Ezért úgy tűnik, a Sun inkább kihagyja, amiben túl nagy a vita (Closures) vagy csinál belőle egy saját megoldást (modularizáció) a végtelen vita helyett (JSR-277). Legalábbis ez az érzésem, nem tudom igaz-e. Én mindenesetre örülök neki, már néha tényleg kicsit túl sok volt a pilpul.

Tags: java7, jigsaw, modularitás

Csütörtök

Thursday, December 11th, 2008 | Devoxx | No Comments

Úgy is mint az utolsó teljes konferencia nap. Holnap már csak délelőtt lesznek előadások, és nem lesz keynote sem.

Ma viszont Joshua Bloch-é (Effective Java Reloader) és Mark Reinhold-é (Java SE 7 Update) lesz a délelőtt. Utána az “ismerjük meg RSS olvasónk szereplőit” sorozat keretében Jason Van Zyl-hez fogok beülni (Efficient Entreprise Builds) a Sonatyptól (akik leginkább a Nexus Maven proxyról, és az ingyenes Maven könyükről híresek).  Aztán dilemma: NIO.2 vagy project Fuji? Utána viszont valószínű moduláris Java lesz, majd BPM (vagy OpenMQ), és parleys.com, ez utóbbi mindenképpen.

A Parleys.com-ról (ami már most is irreálisan jó és használható oldal) már az újság megszellőztette a dolgokat: a következő verzióhoz lesz author kliens, és lesznek csatornák és spacek: a helyi JUG-ok is tölthetik fel rá a prezentációkat, illetve cégek is saját részeket bérelhetnek (ők pénzért, de abszolút saját megjelenés alatt).

És persze BOF-ok és villám előadások: Glassfish V3 prelude, java alapú hírdertési rendszer, jugevent projekt, stb.

Tags: program

Antoine Borg: Getting to grips with Mule

Wednesday, December 10th, 2008 | Devoxx | No Comments

Lefekvés előtt hallgasson Mule előadást ön itt. Elmondjuk önnek, hogy a Mule mire jó és miért.

A Mule egy remek ESB megoldás, semmilyen szabványt nem támogat, de nagyon egyszerűen és gyorsan működik. Mindent össze lehet kötni mindennel, minden része kicserélhető. Kicserélhető a tranzakció kezelő, kicserélhető a szál kezelés, minden. Olyannyira, hogy nem csak ESB mintát tud megvalósítani, hanem bármilyen más mintát. Nem feltétlenül kell az üzeneteknek egy buszon menni, a példányok kommunikálhatnak egymással is (ha akarjuk). Ha akarjuk tud XA tranzakció kezelést is (egy példányon belül).

Azt kell mondanom, hogy szimpatikus lett. Olyan egyszerű, amennyire csak lehet, és annyira kiterjeszthető, amennyire csak lehet. Nem kell. pl a buszon belül feltétlenül, XML-t beszélni,  bármit használhatunk, amit szeretnénk. Csak okos transzformereket kell használni/írni.

Az előadó szerint a hibái: a clusterezés natívan nem megoldott (ügyes átmeneti tárolókat kell használni, és akkor lehet elosztani a terhelést). Ezen még dolgznak.
És ha elkezded kicserélni a dolgokat, akkor függeni fogsz a Mule-tól. Ez van. Viszont addig könnyű életed lesz.

Tags: esb, mule, soa

Richard Bair,Martin Brehovsky: The JavaFX SDK

Wednesday, December 10th, 2008 | Devoxx | No Comments

Azért ültem be erre az előadásra (amellett, hogy pont nem volt a slotba semmi ami érdekelt volna), hogy amikor JavaFX-ről van szó, akkor átlássam annyira a dolgot, hogy tudjam mire megy ki a dolog, és tudjam értelmezni a példákat. Ezt a cél az előadás maximálisan hozta. Richard Bair pedig régi motoros, még azt is elő tudja adni, amikor csak copy paste-eli be a példákat.

Aztán Martin Brehovsky mutogatta az animációs lehetőségeket. Ezeket is megnéztük, egy sárga négyzetet animáltunk össze viszza. Valóban működött. Egyszerű API-k kellettek hozzá.

Épp előtte beszélgettünk a folyosón, hogy ez a JavaFX megkésett dolog-e, és hogy kidobott pénz-e. Nem tudom. Az én munkáimhoz nem nagyon kapcsolódik (alapvetően nem is szeretem az olyan projekteket, ahol GUI is van, abból csak baj van , de azt kell mondanom, hogy ha veszteséges lesz, ha nem, ha elkésett, ha nem, azért egy jó kis játéknak tűnik. Kijön majd Linuxra, és kicsit stabilabb lesz csinálok vele valami dolgot, amit lehet nyomogatni.

Tags: javafx

Romain Guy: Filthy Rich Android Clients

Wednesday, December 10th, 2008 | Devoxx | No Comments

Kiváncsi voltam az előadóra, annyit hallottam már a nevét (többek között a Devoxx programfelelős bizottságába is benne van). Fiatal tag, átlagos előadó, semmi különös.

Az Androidban található grafikai lehetőségekről beszélt: áttünések, animációk, árnyékok, felületek, objektumok.

Vannak benne ilyenek. Láttam. API-kon keresztül lehet elérni őket.

Tags: android, gui

Adam Warski: Envers – Easy Entity Versioning

Wednesday, December 10th, 2008 | Devoxx | No Comments

Entitások verziózása a feladat (szép hosszan magyarázva). A subversion hasonlat szerintem mindent elmondott róla előszőrre is. Revíziók vannak (tranzakciókhoz kötve), külön táblákban tárolva a verziózott adatokat. A legfrisseb változat továbbra is szabvány JPA-val kezelhető, és van egy saját API a régi verziók előcsalogatásához. A verziózandó entitásokat meg kell annotálni, a hibernate configba néhány property és már megy is.

Viszont: csak hibernate-tel megy (Toplinknek van más megoldása erre), tehát a használatával pont a provider függetlenséget vesztem el. (És igen, nekünk konkrétan előfordult már, hogy JPA providert váltottunk, tehát ez egy valós probléma szerintem.).

Talán majd a JPA 3-ban.

ps: az Envers a hibernate projekt része lett

Tags: envers, hibernate, JPA, verziózás

Joris Kuipers: Introduction to the SpringSource dm Server

Wednesday, December 10th, 2008 | Devoxx | No Comments

A Spring “alkalmazás szerver”ének bemutatása. Az alkalmazás szerver egyik oldalról egy Tomcat felturbózva OSGi-val, a másik oldalról egy Equinox OSGi konténer, amiben Tomcat is van.

Ez első kérdés az volt, hogy miért csináltak új szervert, miért nem voltak jók az eddigiek (itt nagyon jegyzeteltem, mert ez  sosem volt teljesen világos). Válasz: mert a létezők nem elég modulárisok. Egy deploynál az egész alkalmazást kell redeployolni, és az alkalmazások között sincs megoldva a közös szolgáltatások megosztása. A szerver felépítése sem moduláris, ha nem akarunk mindent használni a J2EE szolgáltatásaiból akkor is mindent el indít (khm. Glassfish v3 már nem).

És akkor az ő megoldásuk: egy Equinox OSGi konténer, ami war-filet is és egy saját OSGi alapú formátumot is felismer. Alapértelmezésben autodeploy könyvtár útján (itt pickup), de van admin felület is, ahonnal deployolni lehet. A saját kváziwar formátumuk is OSGi szabvány család része lesz valamilyen RFC néven.

A demók alapján ez a formátum csak azt jelenti, hogy egy plusz spring könyvtárba vannak Spring xml varázslatok a jar fileban (és annotációk a kódban), és ezek leegyszerűsítik az OSGi service-ek használatát és publikálását.

Eszközök: van hozzá Eclipse plugin, mást nem is akarnak fejleszteni.

Jó dolgok még: van hozzá repository alkalmazás (1.0.1), ami Maven és IvY kompatibilist, és lehet bundleokat közvetlen a netről repositoryból deployolni. A logolás is okos: bundle szintű logfájlok vannak.

Bevallom én elég szkeptikusan álltam hozzá az elején, mégis tetszett a dolog, pazar cuccnak tűnt.
Volna.
Ugyanis a végén kiderült, hogy ez az egész csak Equinox konténer alatt fut (azt tudták jól meghekkelni), mást OSGi konténer alatt nem. Tehát ha írok valami csodát, akkor azt csak az ő szoftverükön futtathatom. Egy kicsit meggyőzőbb lenne, ha tényleg nagy OSGi kompatibilitás lenne. Bár lehet, hogy csak én nem értettem valamit, és az csomagformátum RFC segít majd ezen is.

Tags: osgi, server, spring, springdm, tomcat