Letz­te Woche war ich auf dem Java Forum Stutt­gart, einer der pro­mi­nen­tes­ten Ja­va-Kon­fe­ren­zen in Süd­deutsch­land, als Spea­ker ein­ge­la­den. Die mit 1200 Be­su­chern aus­ge­buch­te Ver­an­stal­tung ver­sprach et­li­che in­ter­es­san­te The­men. In sechs par­al­le­len Tracks gab es ins­ge­samt 42 (wie­vie­le auch sonst ;-) Vor­trä­ge zu hören - hier meine Aus­wahl:

Die TOP 10 der Tools & Me­tho­den für mehr Spaß beim Ent­wi­ckeln
Ich muß zu­ge­ben, da hatte ich mir ein klein wenig mehr er­war­tet. Con­ti­nuous In­te­gra­ti­on, au­to­ma­ti­sier­te Unit tests, ir­gend­ei­ne Form der Team- und Selbst­or­ga­ni­sa­ti­on - klar, daß das sehr sinn­voll ist (und es sich lohnt, dafür zu kämp­fen, so etwas zu eta­blie­ren). "Art­ge­rech­te Hal­tung von Nerds", also ge­le­gent­li­ches Co­mi­cle­sen oder Blät­tern im Heise Newsti­cker oder bei InfoQ, ist eben­so wich­tig... nett war dafür das De­tail, das Co­mi­cle­sen zum Grup­penevent zu ma­chen und als Ein­stieg für den Daily Stan­dup zu nut­zen :-)
Die Spiel­chen um "you broke the build" sehe ich ein Stück weit kri­tisch - so etwas darf nicht dazu füh­ren, daß sich die Ent­wick­ler nicht mehr trau­en, ihren Code ein­zuch­ecken. "Com­mit early, com­mit often" ist aus meh­re­ren Grün­den wich­tig - Co-Ent­wick­ler kön­nen sich so auf Än­de­run­gen zei­tig ein­stel­len, Feh­ler (mit)ent­de­cken... und zu­letzt ist das zen­tra­le Code­re­po­si­to­ry häu­fig die ein­zi­ge Ma­schi­ne mit wirk­lich guter Da­ten­si­che­rung.
Be­züg­lich der pro­duk­ti­ons­stei­gern­den Me­tho­den würde ich die an­ge­spro­che­nen Tas­ten­kür­zel un­be­dingt um einen ge­eig­ne­ten Win­dow­ma­na­ger und/oder ein "Wohl­fühl-Be­triebs­sys­tem" er­gän­zen.

Ef­fek­ti­ve Scala Ent­wurfs­mus­ter
Ur­sprüng­lich woll­te ich mir die Con­cur­ren­cy-Pa­ra­dig­men an­hö­ren, habe mich dann aber spon­tan um­entschie­den... bin immer noch un­schlüs­sig, ob es ein Feh­ler war. Der Vor­trag schil­der­te, wie di­ver­se Pat­terns der Gang of Four in Scala aus­se­hen (oder auf­grund des Sprach­de­signs kom­plett ver­schwin­den). Für Sca­la-Neu­lin­ge (ver­mut­lich der über­wie­gen­de Teil des Au­di­to­ri­ums) war das ziem­lich er­schla­gend, ich schät­ze mal, die meis­ten von ihnen waren nach 10 Mi­nu­ten 'raus... für die­je­ni­gen, die sich mit Scala schon ein wenig aus­ein­an­der­set­zen, waren die ers­ten 30 Mi­nu­ten ein kon­ti­nu­ier­li­ches Ab­ni­cken ("seen it, done that"); und für die ver­blei­ben­de Zeit war Cake Pat­tern und Type Clas­ses de­fi­ni­tiv star­ker Tobak :-)

Pro­duk­ti­vi­täts­schub mit Eclip­se Mylyn, Git, Ger­rit und Hud­son
Seit­dem ich vor ei­ni­gen Jah­ren Mylyn für mich ent­deckt habe, bin ich ein gro­ßer Fan davon: Das Ak­ti­vie­ren eines Tasks (ent­we­der lokal in Mylyn no­tiert oder aus einem Bug­tra­cker ge­synct) sorgt dafür, daß der ge­sam­te Edi­tor-Zu­stand (wel­che Da­tei­en wur­den an­ge­fa­ßt, wel­che Da­tei­en waren ge­öff­net, wo stand je­weils der Cur­sor) ge­spei­chert wird. Wech­selt man zwi­schen den Tasks wird der je­wei­li­ge Edi­tor-Zu­stand au­to­ma­tisch wie­der her­ge­stellt. Das läs­ti­ge "wo war ich denn?" beim Wech­sel zwi­schen Tasks wird so deut­lich schmerz­be­frei­ter.
Hud­son (bzw. Jenk­ins) hatte ich in jedem mei­ner letz­ten Pro­jek­te am Start (Con­ti­nuous In­te­gra­ti­on ist wiiiich­tig), git als SCM ist oh­ne­hin über jeden Zwei­fel er­ha­ben, und das Code-Re­view-Tool Ger­rit habe ich schon seit ge­rau­mer Zeit auf dem Radar.
Was ich nicht wußte: Die neu­es­te Ver­si­on von Mylyn in­te­griert auch Ger­rit kom­plett in die Ober­flä­che von Eclip­se. Im Ver­lauf des Vor­trags wurde ein sol­che Re­view-Durch­lauf kom­plett de­mons­triert, und ich muß sagen, daß das rich­tig gut aus­sieht.
Ger­rit sorgt dafür, daß jeder Com­mit zu­nächst durch ein Code Re­view muß, bevor die Än­de­rung im ei­gent­li­chen Mas­ter Re­po­si­to­ry lan­den. Das stei­gert si­cher die Code­qua­li­tät, al­ler­dings frage ich mich, wie das in einem rich­tig gro­ßen Pro­jekt ska­liert: Die Chan­ce von Mer­ge-Kon­flik­ten beim Über­neh­men von Än­de­run­gen in den Mas­ter dürf­te da stei­gen, was ma­nu­el­les Mer­gen und eine wei­te­re Schlei­fe durch den Ger­rit-Pro­zeß be­deu­tet.
Trotz­dem denke ich, daß der Ein­satz von Ger­rit eine Über­le­gung wert ist - je nach Pro­jekt­grö­ße muß man sich ge­eig­ne­te Work­flows über­le­gen.

An­dro­id Pro­gram­mie­rung leicht­ge­macht
Ah, Lars Vogel in Ac­tion :-) Ich habe schon mal einen vor­sich­ti­gen Blick auf die An­dro­id-Pro­gram­mie­rung ge­wor­fen, von daher gab's nichts Neues zu sehen... aber un­ter­halt­sam war es den­noch :-)

Safe­ty First - An­dro­id si­cher pro­gram­mie­ren!
Okay, das war der Vor­trag, der (im Ver­gleich zu den meis­ten an­de­ren Talks) tief ab­tauch­te :-) Ohne tief­ge­hen­de Kennt­nis­se über die Ent­wick­lung von An­dro­id-Apps war's gegen Ende schwie­rig zu fol­gen, den­noch lie­fer­te der Vor­trag eine gute Über­sicht über die Se­cu­ri­ty-Me­cha­nis­men von An­dro­id - und di­ver­se Pit­falls, die bei der An­wen­dungs­ent­wick­lung zu be­ach­ten sind. Soll­te einer der Zu­hö­rer mal an den ent­spre­chen­den Punkt kom­men, bie­ten die Vor­trags­fo­li­en einen brauch­ba­ren Auf­hän­ger für das je­wei­li­ge Thema.

REST­ful APIs - warum REST mehr als http und XML ist
Mein Talk! Über die­sen kann ich na­tür­lich nur aus einer an­de­ren Per­spek­ti­ve be­rich­ten :-)
Ich hatte den Ein­druck, daß Thema und Prä­sen­ta­ti­on gut an­ka­men (der Vor­trag fand im grö­ß­ten Saal der Kon­fe­renz statt und war rap­pel­voll), es gab am Ende in­ter­es­sier­te Rück­fra­gen. Spe­zi­el­le REST-Frame­works zur Im­ple­men­tie­rung konn­te ich nicht be­nen­nen (ich hatte bei der letz­ten grö­ße­ren REST-API JAXB und Jer­sey im Ein­satz), eine Emp­feh­lung aus dem Au­di­to­ri­um war RES­TEasy für JBoss.
Meine per­sön­li­che Kon­se­quenz des Vor­trags: Die Win­dows-In­stal­la­ti­on auf mei­nem Lap­top hat ihre letz­te Exis­tenz­be­rech­ti­gung (das ein­fa­che An­ste­cken eines Bea­mers und der Zwei­schirm­be­trieb mit Re­fe­ren­ten­an­sicht bei Power­point) ver­lo­ren, nach­dem sich Win­dows zu­nächst hart­nä­ckig wei­ger­te, in den Zwei­schirm­be­trieb zu wech­seln - und nach einem Re­boot die Ko­ope­ra­ti­on mit dem Prä­sen­ta­ti­ons­bea­mer kom­plett ver­wei­ger­te. Sowas pas­siert na­tür­lich immer im "Ernst­fall" - bei den Pro­be­läu­fen da­heim und im Büro gab es da nie Pro­ble­me :-/

Se­cu­re Soft­ware De­ve­lop­ment Lifecy­cle: Si­che­re An­wen­dun­gen von Be­ginn an
Es war der letz­te Vor­trags­slot, was so­wohl dem Re­fe­rent als auch dem Pu­bli­kum an­zu­mer­ken war :-) Ta­ke-ho­me-mes­sa­ge (für mich nichts neues): Soft­ware­qua­li­tät und Si­cher­heit sind keine "Fea­tures", die man nach­träg­lich noch "da­zu­kau­fen" kann - sie müs­sen Teil des ge­sam­ten Ent­wick­lungs­pro­zes­ses sein. Das be­deu­tet, daß hier­für im Vor­feld(!) ent­spre­chen­de Gui­de­li­nes auf­ge­stellt wer­den und die Team-Mit­ar­bei­ter ge­schult wer­den müs­sen.
Vom Re­fe­rent emfp­oh­len wurde Open­SAMM, ein "Soft­ware As­suran­ce Ma­tu­ri­ty Model" - eine Samm­lung von Emp­feh­lun­gen für das Auf­stel­len, Durch­füh­ren und die Be­wer­tung sol­cher Pro­zes­se. Bei der Re­cher­che hier­zu bin ich auch auf den Pe­ne­tra­ti­on Tes­ting Exe­cu­ti­on Stan­dard ge­sto­ßen - Pe­ne­tra­ti­on Tests kön­nen (soll­ten?) Teil eines Pro­zes­ses für die Ent­wick­lung si­che­rer Soft­ware sein; üb­li­cher­wei­se wer­den diese zwar ex­tern durch­ge­führt (wegen spe­zia­li­sier­tem Know-How und "Be­triebs­blind­heit" des ei­ge­nen Teams), aber den­noch kön­nen die In­for­ma­tio­nen sinn­voll sein, um die Güte der ein­ge­kauf­ten Leis­tung zu be­wer­ten.

Alles in allem war's eine schö­ne, in­for­ma­ti­ve Kon­fe­renz - die Or­ga­ni­sa­ti­on klapp­te ta­del­los, es gab le­cke­res Essen, und auch in den Pau­sen wur­den die Gäste prima ver­sorgt. Ich hätte mir ge­wünscht, daß ei­ni­ge Vor­trä­ge noch ein klein wenig mehr in die Tiefe ge­gan­gen wären - aber na­tür­lich ist so etwas immer etwas schwie­rig, da die Vor­kennt­nis­se der Zu­hö­rer im Vor­feld schwer ab­zu­schät­zen und fast immer eher in­ho­mo­gen sind.