Ich war die­ses Jahr ein­ge­la­den, auf dem Herbst­cam­pus einen Vor­trag über Ja­va-Se­cu­ri­ty zu hal­ten und konn­te bei die­ser Ge­le­gen­heit zwei wei­te­re Kon­fe­renz­ta­ge „mit­neh­men“. Ins­ge­samt konn­te ich so den ers­ten Work­shop-Tag sowie die dar­auf­fol­gen­den bei­den Kon­fe­renz­ta­ge be­su­chen.

Was zählt ist auf’m Platz

Als Work­shop hatte ich mir die „Test­au­to­ma­ti­sie­rung im Brow­ser“ aus­ge­sucht. Einen Tag lang domp­tier­ten wir den Brow­ser mit Hilfe von Geb, einer Groo­vy-DSL/Bi­blio­thek für Se­le­ni­um. Geb mach­te einen gut ab­ge­han­ge­nen und so­li­den Ein­druck; die Do­ku­men­ta­ti­on („the Book of Geb“) ist aus­führ­lich und hilf­reich.

Um Tests mög­lichst sau­ber zu struk­tu­rie­ren und eine hohe Wie­der­ver­wend­bar­keit zu er­rei­chen, ist es sinn­voll, seine Tests mit­tels Mo­du­les und Pages zu or­ga­ni­sie­ren. In letz­te­ren wer­den die ei­gent­li­chen Ak­tio­nen auf der Seite ab­ge­bil­det, die ei­gent­li­chen Unit-Tests rufen die se­man­tisch höher ge­stell­ten Funk­tio­nen die­ser Klas­sen („trage als Name XY ein“ oder „sende das For­mu­lar ab“) auf.

In mei­nem ak­tu­el­len Pro­jekt kommt das Play Frame­work zum Ein­satz; ich konn­te keine Mög­lich­keit fin­den, Groo­vy ge­eig­net in das SBT-Build­sys­tem von Play zu in­te­grie­ren. Glück­li­cher­wei­se gibt es hier als Al­ter­na­ti­ve Flu­ent­le­ni­um. Flu­ent­le­ni­um fühlt sich sehr ähn­lich zu Geb an, al­ler­dings scheint hier die Tren­nung in Mo­du­les und Pages zu feh­len (es gibt nur Pages).

Dabei würde sich ins­be­son­de­re bei Play die Glie­de­rung in Mo­du­les an­bie­ten: Jedes Sei­ten-Snip­pet, das von an­de­ren Sei­ten in­klu­diert wird, wird auf ein Mo­du­le ab­ge­bil­det; ent­spre­chend der In­klu­die­rung wer­den Pa­ge-Ob­jek­te zu­sam­men­ge­stellt, wel­che dann letzt­lich für die Tests ver­wen­det wer­den. Ob sich das Er­zeu­gen des zu­ge­hö­ri­gen Codes (zu­min­dest teil­wei­se) au­to­ma­ti­sie­ren läßt? Ein Ge­dan­ke, den ich mal im Hin­ter­kopf be­hal­te ;-)

In den Fän­gen des Wirt­schafts­dar­wi­nis­mus

Auf­takt zur Kon­fe­renz bil­de­te der Vor­trag von Uwe Fried­rich­sen; den Vor­trag hatte er unter dem Titel Dr. hec­tic und Mr. Hype be­reits an an­de­rer Stel­le ge­hal­ten. Sei­ner Be­ob­ach­tung nach sind agile Ent­wick­lungs­me­tho­den zwar der zu be­vor­zu­gen­de Weg, den man mo­men­tan be­schrei­ten soll­te, in der ak­tu­el­len öko­no­mi­schen Si­tua­ti­on reicht das al­lei­ne al­ler­dings nicht mehr. Agi­li­tät ist auch an wei­te­ren Stel­len er­for­der­lich. Sein Vor­trag war ein Plä­doy­er war für den Ein­satz von agi­ler Soft­ware­ent­wick­lung zu­sam­men mit De­v­Ops, Con­ti­nuous De­li­very, der Ent­wick­lung für De­ploy­ment in Cloud-ar­ti­ge In­fra­struk­tur (und ei­ni­ge wei­te­re Schlag­wor­te).

Ich gebe Uwe recht, vie­les wird in Zu­kunft in diese Rich­tung gehen.

Macht der Ge­wohn­heit

In­te­gra­ti­ons­ser­ver mit einer An­bin­dung an Sonar, Check­style, etc. sind si­cher gut, um eine „Ver­schmut­zung“ der Quell­text­ba­sis zu ver­hin­dern; ins­be­son­de­re für Pro­jekt­neu­lin­ge wäre es aber sinn­vol­ler, dem Ent­wick­ler ein un­mit­tel­ba­res und di­rek­tes Feed­back in der IDE zu geben, ähn­lich den rot un­ter­rin­gel­ten Wor­ten mit Recht­schreib­feh­lern in einer Text­ver­ar­bei­tung. Diese Idee ver­folgt das Pro­ject Usus. Usus ist ein Eclip­se-Plu­gin, das au­to­ma­ti­siert Code­ana­ly­se aus­führt und den Ent­wick­ler über Feh­ler sowie über den Trend sei­ner Code­qua­li­tät in­for­miert.

Klingt in­ter­es­sant, habe ich auf meine Liste der aus­zu­pro­bie­ren­den Dinge ge­setzt.

Hallo JS

Ja­va­script ist an­ders ;-) Da ich nicht der JS-Rou­ti­nier bin, dach­te ich mir, ein Ein­stiegs­vor­trag in die Spra­che kann nicht scha­den. Das Pro­to­ty­pen-Ob­jekt­mo­dell von JS war mir zwar schon be­kannt, über die Sicht­bar­keit von Va­ria­blen (es gibt nur Func­tion Scope und Glo­bal Scope) wäre ich aber si­cher frü­her oder spä­ter ge­stol­pert. Nein, ich glau­be nicht, daß JS in naher Zu­kunft meine Lieb­lings­spra­che wird.

Unter Be­ob­ach­tung

Die­ser Vor­trag stell­te unter dem Un­ter­ti­tel „Aus­weg aus der Call­back-Höl­le“ einen Über­blick über die Idee des „re­ac­tive Pro­gramming“ und dem Re­ac­tive Ma­ni­fes­to vor. Eine der Grund­ide­en ist es, die Denk­wei­se und Sicht des Ent­wick­lers von Pull-Me­cha­nis­men auf Push-Me­cha­nis­men zu ver­schie­ben. Als Bei­spiel wurde im Vor­trag ein Iterator mit einem Iterable ver­gli­chen. Der Ite­ra­tor durch­läuft eine Da­ten­men­ge, die Pro­gram­mie­rung ist im­pe­ra­tiv und üb­li­cher­wei­se syn­chron. Bei einem Iterable hin­ge­gen wird der Code immer dann auf­ge­ru­fen, wenn Daten zur Ver­fü­gung ste­hen – der Pro­gramm­code „re­agiert“ (asyn­chron) auf die ein­ge­hen­den Daten, an­statt zu war­ten.

Die Rx-Do­mä­ne scheint zu einem guten Teil von Scala be­legt zu sein, der Vor­trag ver­wies auf meh­re­re Sca­la-Bi­blio­the­ken:

• dire
• Re­ac­tive Web (ins­be­son­de­re für Lift-An­wen­dun­gen)
• sca­la-re­act, das bei Mar­tin Oder­s­ky und einem Dok­to­rand ent­stand

Aber auch für Java gibt es eine Bi­blio­thek, die nach Aus­sa­ge des Re­fe­ren­ten gut ab­ge­han­gen und an­ge­nehm zu be­nut­zen ist: Rx­Ja­va.

JS on Ste­ro­ids

Ty­peScript ist eine Ober­men­ge von Ja­va­script, das zu rei­nem Ja­va­script kom­pi­liert. So kön­nen auf der einen Seite be­ste­hen­de JS-Bi­blio­the­ken 1:1 über­nom­men wer­den, Er­wei­te­run­gen mit der er­wei­ter­ten Syn­tax und Ty­pen­prü­fung von Ty­peScript im­ple­men­tiert wer­den. Für viele be­ste­hen­de Bi­blio­the­ken ste­hen zu­sätz­li­che Ty­pen­in­for­ma­tio­nen be­reit, um auch hier von den Vor­zü­gen von Ty­peScript pro­fi­tie­ren zu kön­nen.

Ty­peScript wird von Mi­cro­soft vor­an­ge­trie­ben und be­sitzt ins­be­son­de­re in der Mi­cro­soft-Ent­wick­lungs­um­ge­bung eine gute Un­ter­stüt­zung. Mit ähn­li­chen Zie­len (ein „bes­se­res JS“) sind auch Cof­fee­Script und Dart an­ge­tre­ten – Cof­fee­Script über­setzt eben­falls nach JS, Dart bie­tet ent­we­der seine ei­ge­ne VM oder einen Com­pi­ler nach JS; im Vor­trag gab es lei­der kei­nen Ver­gleich der Tech­no­lo­gi­en, was für ein Pro­jekt am bes­ten ge­eig­net ist, hängt von ver­schie­de­nen Fak­to­ren ab.

Un­ab­hän­gig­keits­er­klä­rung

Wie sorgt man als Ar­chi­tekt in einem Team dafür, daß die Team­mit­glie­der Arch­ti­tek­tur­vor­ga­ben ein­hal­ten? Wie über­prü­fe ich, wel­ches Paket Ab­hän­gig­kei­ten auf wel­ches an­de­re Paket be­sitzt? De­graph bie­tet hier eine Lö­sung.

Mit De­graph las­sen sich so­ge­nann­te „Sli­ces“ an­hand von Pa­ket­na­men de­fi­nie­ren. Über sol­che Sli­ces las­sen sich dann er­laub­te Ab­hän­gig­kei­ten prü­fen. Die Tei­lung in Sli­ces er­folgt oft in meh­re­ren Ach­sen, so macht es bei­spiels­wei­se Sinn, in einer MVC-An­wen­dung Calls vom Model an eine der an­de­ren bei­den Schich­ten zu ver­bie­ten und gleich­zei­tig zwi­schen Views und Con­trol­ler ver­schie­de­ner Be­rei­che der An­wen­dung (z.B. Ad­min-Sei­ten und Rest der An­wen­dung) keine Quer­auf­ru­fe zu ge­stat­ten.

Wäh­rend des Vor­trags konn­te ich mehr­fach nur schwer den Im­puls un­ter­drü­cken, auf­zu­sprin­gen und laut „Ja! Genau so!“ zu rufen ;-) De­graph werde ich de­fi­ni­tiv auf dem Radar be­hal­ten.

You are not Face­book or Goog­le?

Die­sen Vor­trag habe ich lei­der als Ver­kaufs­ver­an­stal­tung ver­bu­chen müs­sen. Der Un­ter­ti­tel „warum Sie sich trotz­dem mit Big Data be­schäf­ti­gen soll­ten“ hatte zwar neu­gie­rig ge­macht, blieb mir per­sön­lich aber die Ant­wort schul­dig. „Kau­fen Sie nicht ir­gend­ei­ne Big-Da­ta-Lö­sung!“ lau­te­te der Auf­ruf zu Be­ginn des Talks, denn jedes Pro­blem sei in­di­vi­du­ell und es gäbe kei­nen Big-Da­ta-Al­les­kön­ner. Den­noch wurde spä­ter Ha­doop als der „De-Fac­to-Stan­dard“ an­ge­prie­sen. Es fan­den sich noch wei­te­re sol­cher Wi­der­sprü­che – an sich scha­de, gebe ich dem prin­zi­pi­el­len Tenor des Vor­trags (die Big-Da­ta-Tech­no­lo­gi­en sind einen Blick wert, aber be­trei­be kein Big Date um sei­ner selbst wil­len, son­dern be­trach­te den An­wen­dungs­fall) doch recht.

Web-An­wen­dun­gen? Aber si­cher!

Zum Ab­schluß mei­nes Herbst­cam­pus-Be­suchs durf­te ich mei­nen Vor­trag über Ja­va-Web­s­e­cu­ri­ty vom Ja­va­fo­rum in einer über­ar­bei­te­ten XXL-Fas­sung hal­ten – ein Hoch auf die 60 Mi­nu­ten lan­gen Slots! So war mehr Zeit für De­mons­tra­tio­nen, auch wenn die Vor­füh­run­gen einen Gro­ß­teil der Fra­ge­zeit kan­ni­ba­li­siert haben… ich hoffe, meine (rund 45) Zu­hö­rer sahen es mir nach. Den Feed­back-Bö­gen nach haben sie Milde wal­ten las­sen, wurde der Ge­samt­ein­druck des Vor­trags im Durch­schnitt mit einer 1,3 be­wer­tet. Ja, es stimmt mich ein klein wenig Stolz ;-)

Fazit

Alles in allem hat es mir auf dem Herbst­cam­pus wie­der sehr gut ge­fal­len. Im Ver­gleich zum Vor­jahr (da konn­te ich nur einen Tag be­su­chen) hatte ich den Ein­druck, daß das tech­ni­sche Ni­veau nicht mehr ganz so tief­ge­hend war; auch hatte mir der de­di­zier­te Sca­la-Track des Vor­jah­res sehr gut ge­fal­len. Den­noch hoffe ich, daß es 2014 wie­der mit einem Be­such klap­pen wird.