Kaum hatte das Ja­va­fo­rum be­gon­nen, war’s auch schon wie­der vor­bei – eine ein­tä­gi­ge volle Breit­sei­te an Vor­trä­gen, Ge­sprä­chen und ver­schie­de­nen Ein­drü­cken. Ich ver­su­che mal fest­zu­hal­ten, was mir aus mei­nen Vor­trags­be­su­chen hän­gen­ge­blie­ben ist.

Da­ten­ver­sio­nie­rung in Busi­ness-An­wen­dun­gen

Eine Art Ver­si­ons­ver­wal­tung in der Da­ten­bank - Stän­de mit Tags fi­xie­ren und zwi­schen Va­ri­an­ten (Bran­ches) wech­seln, und das mög­lichst trans­pa­rent für den Ent­wick­ler, der mit Hi­ber­na­te als ORM ar­bei­tet. Man kann sich leicht vor­stel­len, daß das eine eher kniff­li­ge Auf­ga­be ist! Eine uni­ver­sel­le Lö­sung, die dann auch noch per­for­mant ist, kann es mei­ner Mei­nung nach nicht geben; der vor­ge­stell­te An­satz ist durch­aus ge­schickt und funk­tio­niert für das An­wen­dungs­set­ting (ge­rin­ge Zahl von Bran­ches mit wenig Ak­ti­vi­tät dar­auf) auch flott.

Die ge­zeig­te Lö­sung funk­tio­niert nur in Zu­sam­men­spiel mit einer Ora­cle-Da­ten­bank, über Ver­füg­bar­keit wurde nichts ge­sagt. Die Idee kann man aber mal im Hin­ter­kopf be­hal­ten.

Teile und herr­sche - ver­teil­te Ja­va­an­wen­dun­gen mit Do­cker

Eine Blitz­tour quer über Do­cker. Do­cker­files, Image-Lay­ers, Con­tai­ner an­le­gen, star­ten, stop­pen, Moun­ten lo­ka­ler Ver­zeich­nis­se für Kon­fi­gu­ra­ti­on und per­sis­ten­te Daten… nicht viel neues für je­man­den, der schon mal mit Do­cker her­um­ge­spielt hat. Für alle an­de­ren eine schö­ne Ein­füh­rung. In­tel­liJ hat (im Ge­gen­satz zu Eclip­se) Sup­port für Do­cker­files? Muß ich mal an­se­hen.

Er­freu­lich: Das Thema „Patchen von Si­cher­heits­pro­ble­men in Con­tai­nern“ wurde an­ge­spro­chen, auch wenn die Re­fe­ren­ten dafür of­fen­bar auch noch keine Pa­tent­lö­sung ge­fun­den haben :-) An­sons­ten be­kommt der Talk von mir den Preis für die Li­ve­de­mos mit dem cools­ten Kom­man­do­zei­len-Prompt ;-)

Mach mit Eclip­se Smar­tHo­me dein Zu­hau­se in­tel­li­gent

Nach kur­zer Ein­füh­rung eine Demo, wie man mit Open­HAB 2 Ge­rä­te ein­bin­det und skrip­tet. Ich habe Open­HAB 1 vor zwei oder drei Jah­ren mal an­ge­guckt und ich muß sagen: Wow, da hat sich ei­ni­ges getan! Ins­be­son­de­re das au­to­ma­ti­sche Er­ken­nen von Ge­rä­ten macht si­cher vie­les ein­fa­cher. Das ganze macht rich­tig Lust auf Aus­pro­bie­ren.

Im An­schluß hatte ich noch ein Ge­spräch be­züg­lich der Si­cher­heit der di­ver­sen Funk­pro­to­kol­le im Hei­m­au­to­ma­ti­ons-Be­reich. Mein letz­ter Kennt­nis­stand war, daß quasi alle Pro­to­kol­le außer Z-Wa­ve be­kann­te Schwä­chen haben - und Z-Wa­ve ver­mut­lich nur des­halb noch nichts be­kannt ist, weil das pro­prie­tä­re Pro­to­koll noch nicht re­ver­se-en­gi­neert wurde. Im Ge­spräch mein­te der Re­fe­renz, daß Zig­bee mög­li­cher­wei­se das kleins­te Übel ist, das ein­zi­ge be­kann­te Pro­blem ist sei­ner Kennt­nis nach ein In­se­cu­re Re­join. Eine kurze Re­cher­che führ­te diese Vor­trags­fo­li­en zu Tage - min­des­tens gibt es wohl noch Re­play-Pro­ble­me, an­sons­ten war das der Stand von 2011, un­klar, was sich in der Zwi­schen­zeit noch er­ge­ben hat. Ich blei­be mal skep­tisch.

Yes we scan! Soft­ware-Ana­ly­sen mit jQAs­sis­tant

JQAs­sis­tant ist ein Tool, um Ja­va-Ar­te­fak­te (JARs, aber auch WARs, EARs, sogar Log­files von Sonar o.ä.) re­kur­siv zu par­sen und Struk­tur und In­for­ma­ti­on in einer Neo4J-Da­ten­bank ab­zu­le­gen. Als Ein­ga­be die­nen ein­zel­ne Da­tei­en, ganze Ver­zeich­nis­se oder sogar kom­plet­te Ma­ven-Re­po­si­to­ries. Auf den Daten kann man dann durch ge­eig­ne­te Que­ries das Wach­sen der Kom­ple­xi­tät be­ur­tei­len, oder die Ein­hal­tung von Na­mens­re­geln, Pa­cka­ge­struk­tur-Vor­ga­ben oder Ar­chi­tek­tur-Zu­griffs-Cons­traints über­prü­fen.

Ir­gend­wie kom­men un­ter­schied­li­che Leute immer wie­der auf ähn­li­che Ideen, JQAs­sis­tant kann ver­mut­lich die Funk­tio­na­li­tät von de­graph ab­bil­den, und soll­ten auch Funk­ti­ons­auf­ru­fe samt Zei­len­num­mern in der Da­ten­bank lan­den, wäre wohl auch mein Stack­tra­ce Fin­ger­prin­ting damit um­setz­bar. In jedem Fall braucht jedes der drei Pro­gram­me einen Scan­ner, der die Struk­tur von JARs (und beim Stack­tra­ce Fin­ger­prin­ting die Ma­ven-Ab­hän­gig­kei­ten) parst - viel­leicht kön­nen sich die Pro­jek­te da in ir­gend­ei­ner Form er­gän­zen?

Ef­fek­ti­ver Ein­satz von Code Re­views

Der Vor­trag war eine Liste von Emp­feh­lun­gen und Er­fah­run­gen des Re­fe­ren­ten aus et­li­chen Jah­ren Code Re­view:

• Code Re­views er­for­dern etwa 15% zu­sätz­li­che Zeit zur Ent­wick­lungs­zeit (dafür sinkt die Zahl der Bugs und der Zeit­be­darf für ir­gend­wel­che Re­fac­to­rings, was al­ler­dings sich schwer als Zeit­ge­winn mes­sen läßt)
• Code Re­views loh­nen sich bei Pro­jek­ten ab etwa einem Mann-Jahr; bei klei­ne­ren An­wen­dun­gen oder ir­gend­wel­chen Pro­to­ty­pen ren­tiert sich die zu­sätz­li­che Zeit nicht (außer man will hier ge­zielt Team­play und Wis­sens­aus­tausch trai­nie­ren).
• Re­views soll­ten nach Ab­schluß jedes Fea­tures bzw. Bug­fi­xes durch­ge­führt wer­den. In einem sol­chen Paket soll­ten ma­xi­mal drei Tage Ent­wick­lungs­zeit ste­cken.
• Das Re­view ma­chen der ur­sprüng­li­che Autor und ein Re­view­er. Hier soll­te im Team bunt ge­mischt wer­den, es soll „jeder mit jedem“, un­ab­hän­gig vom Skill-Le­vel.
• Ein Code Re­view wird syn­chron (am sel­ben Rech­ner oder per Screen­s­ha­ring) durch­ge­führt. Kon­trol­le über Tas­ta­tur und Maus be­kommt der Re­view­er, der Autor er­läu­tert und be­ant­wor­tet Fra­gen.
• Ein Code­re­view soll­te ma­xi­mal 300 - 400 Zei­len Code be­trach­ten und nicht län­ger als 1 - 2 Stun­den dau­ern.
• Sinn­voll ist das Pro­to­kol­lie­ren der Re­view-Er­geb­nis­se: Wel­ches Ti­cket bzw. wel­cher Fea­ture-Branch wurde be­han­delt, wer waren Autor und Re­view­er, wie lange waren Im­ple­men­tie­rungs- und Re­view­zeit, wie­viel Zeit wurde für die Nach­be­rei­tung auf­ge­bracht, wie viele LOC hatte die Än­de­rung, wie­vie­le Bugs/Ver­bes­se­run­gen wur­den ein­ge­bracht. Sehr hilf­reich, um den Auf­wand zu recht­fer­ti­gen, wenn man die zu­sätz­lich in­ves­tier­te Zeit gegen die An­zahl der ge­fun­den Bugs auf­rech­net.
• Ein Team soll­te sich eine Check­lis­te geben, auf was bei Code­re­views ge­ach­tet wird. Das struk­tu­riert das Vor­ge­hen und er­laubt es dem Pro­gram­mie­rer, schon bei der Ent­wick­lung ge­eig­net vor­zu­ar­bei­ten.
• Re­view-Tools sind ab­so­lut zweit­ran­gig! In ers­ter Linie wird eine sau­be­re diff-An­zei­ge be­nö­tigt. Viel wich­ti­ger ist eine gute Con­ti­nuous-In­te­gra­ti­on-Pipe­line, wel­che im Vor­feld schon prüft, ob der Code kom­pi­liert, alles Tests ok sind, Style-Richt­li­ni­en ein­ge­hal­ten wur­den, etc.

Hack that web­site!

Mein Vor­trag (Fo­li­en hier) fand im prop­per ge­füll­ten Beet­ho­ven-Saal statt. Ich habe keine Ah­nung, ob 500, 700 oder 800 Leute im Raum waren - als mir wäh­rend der Li­ve­de­mo spon­tan meine vir­tu­el­le Ma­schi­ne von der Bild­fä­che ver­schwand (Vir­tu­al­Box mein­te nur “ab­or­ted”), guck­te ge­fühlt das ganze Ja­va­fo­rum auf mich ;-)

Das Po­ker­face scheint aber ge­hal­ten zu haben:

I wish I could be as relaxed as @_skyr is during talk demos. #jfs2015

— Florian Hopf (@fhopf) July 9, 2015

Glück­li­cher­wei­se ließ sich der VM-Neu­start mit Er­klä­run­gen über­brü­cken, und glück­li­cher­wei­se star­te­te sie auch er­neut :-) Mit einer Demo we­ni­ger als ge­plant lief dann der Vor­trag voll­ends durch, den Zu­schau­ern scheint’s trotz der Panne ge­fal­len zu haben.

Top Java Per­for­mance Fehl­trit­te

Ein wirk­lich äu­ßerst un­ter­halt­sa­mer Ab­schluß für den Kon­fe­renz­tag. Es ging um Fall­bei­spie­le, in denen es aus ver­schie­de­nen Grün­den zu Per­for­man­ce­pro­ble­men kam - und wie man sie auf­spü­ren konn­te. Zahl der SQL-Que­ries pro Sei­ten­auf­ruf, Da­ten­men­ge pro Query, etc. waren di­ver­se klas­si­sche Me­tri­ken. Beim Mes­sen im Code gilt häu­fig der Phy­si­ker-Spruch „wer mißt, mißt Mist“ - wer hän­disch im Code Start- und Stop­zeit er­mit­telt, mißt damit nicht nur die Lauf­zeit sei­nes Codes, son­dern eben auch Zeit in an­de­ren Threads oder Zwangs­pau­sen durch den Gar­ba­ge Collec­tor. An­sons­ten be­kommt die­ser Talk von mir den Preis für die lus­tigs­ten Sym­bol­bil­der zu den ein­zel­nen Ka­pi­teln:

(War nicht genau das Bild aus dem Talk, aber so ähn­lich ;-)

Fazit

Das Ja­va-Form war wie­der ein­mal große Klas­se. Cha­peau vor den Or­ga­ni­sa­to­ren, die für einen per­fek­ten, rei­bungs­lo­sen Ab­lauf ge­sorgt haben. The­men­tech­nisch war es eine gute Ab­de­ckung, le­dig­lich das Thema al­ter­na­ti­ve JVM-Spra­chen habe ich etwas ver­mi­ßt. Trotz­dem freue ich mich schon auf das nächs­te Jahr.

(Fotos von der JUG Stutt­gart)