Lebendig(en) Quellcode präsentieren

Prä­sen­tiert man im Bereich der Soft­ware­ent­wick­lung, ist es häu­fig sinn­voll oder gar nötig, „But­ter bei die Fische“ zu packen – direkt Quell­code zumin­dest aus­zugs­wei­se zu prä­sen­tie­ren. Ob auf Fach­kon­fe­ren­zen, im Rah­men von Code Reviews oder gar in Prü­fungs-Prä­sen­ta­tio­nen​¹: Es hat wohl fast jeder Ent­wick­ler schon hunderte​² Foli­en vol­ler „totem“, schlecht les­ba­rem und in viel zu klei­ner Schrift gesetz­tem Code über sich erge­hen las­sen müs­sen – weder wirk­lich beein­dru­ckend noch ernst­haft ziel­füh­rend. Davon, wie man Source­code bes­ser prä­sen­tiert, han­delt die­ser Arti­kel. Für den Eili­gen fin­det sich am Ende des Arti­kels eine kom­pak­te, prio­ri­sier­te Check­lis­te.

Source­code auf Foli­en ist ein wenig wie Tro­cken­blu­men: hübsch, aber tot. Nur leben­di­ger Quell­code lässt sich leben­dig prä­sen­tie­ren – und das geht nur in der IDE. Mit der eige­nen Ent­wick­lungs­um­ge­bung zu prä­sen­tie­ren, dürf­te fast immer authen­ti­scher wir­ken – und ermög­licht es, fle­xi­bel mit dem Publi­kum und sei­nen Fra­gen zu interagieren.

Nun könn­te man anneh­men, man kön­ne sich auf die­se Wei­se die unge­lieb­te Vor­trags-Vor­be­rei­tung spa­ren – schnell das Note­book an den Bea­mer anschlie­ßen, aus dem Stand­by auf­we­cken und ein­fach nur in der IDE da wei­ter­ma­chen, wo man gera­de auf­ge­hört hat. Das ist lei­der nicht der Fall – ein wenig Vor­be­rei­tung ist unver­meid­bar und das eine oder ande­re ist zu beachten:

Den Quellcode für die Präsentation vorbereiten

Nie­mand prä­sen­tiert den Inhalt z. B. eines Papers, indem ein­fach die PDF mit dem Bea­mer an die Wand gewor­fen wird. Eben­so wenig sinn­voll ist es, Quell­code unver­än­dert zu prä­sen­tie­ren – meist sind zumin­dest an den auf jeden Fall zu prä­sen­tie­ren­den Stel­len Anpas­sun­gen not­wen­dig, um den Source­code „prä­sen­ta­bel“ zu machen:

• Der Umbruch soll­te ange­passt wer­den. Was wäh­rend der Ent­wick­lung hilf­reich ist, kos­tet beim Prä­sen­tie­ren u. U. schlicht zu viel Platz: Die Brei­te der Zei­len soll­te so gering sein, dass eine les­ba­re Schrift­grö­ße mög­lich ist – die Tie­fe der Ein­rü­ckun­gen soll­te also ggf. redu­ziert wer­den. Mit der Höhe – der Anzahl der Zei­len – muss eben­falls sorg­sam umge­gan­gen werden​³: Öff­nen­de und schlie­ßen­de Klam­mern bei­spiels­wei­se in eige­ne Zei­len zu set­zen, erhöht zwar die Les­bar­keit des Codes am Bild­schirm unge­mein, nimmt aber beim Prä­sen­tie­ren meist zu viel Platz weg – mehr Code am Stück zei­gen zu kön­nen, ist i. d. R. wich­ti­ger und für das Ver­ständ­nis hilfreicher.

{
     abort();
}

{ abort(); }

• Sie haben wirk­lich wenig Platz: Meist sind nur die obe­ren zwei Drit­tel des Bild­schirms wirk­lich für das gesam­te Publi­kum sicht­bar (s. u.).
• Kom­men­ta­re sind im prä­sen­tier­ten Code aus­nahms­wei­se über­flüs­sig. Auch, wenn man gern zei­gen möch­te, dass man lege artis kom­men­tiert: Die meis­ten Men­schen kön­nen nicht gleich­zei­tig lesen und zuhö­ren – und das, was nor­ma­ler­wei­se in Ihren Kom­men­ta­ren zu lesen sein soll­te, gehört im Fal­le der Prä­sen­ta­ti­on von Code auf die „Ton­spur“. Eben­so, wie eine Prä­sen­ta­ti­on kein Hand­out ist (vgl. hier), ist prä­sen­tier­ter Source­code eben etwas ande­res als der „ech­te“ Code, den man (natür­lich wohl­kom­men­tiert) in das Repo­si­to­ry übergibt.
• Zu guter letzt: Der Code soll­te mög­lichst noch funk­tio­nie­ren. Ein Vor­teil des Prä­sen­tie­rens mit der IDE ist ja gera­de das fle­xi­ble und leben­di­ge Prä­sen­tie­ren – und dazu gehört m. E., qua­si in vivo arbei­ten zu kön­nen, bei Bedarf den Code auch aus­füh­ren oder debug­gen zu kön­nen. Wenn irgend mög­lich, soll­te der Code also das Umfor­ma­tie­ren „über­le­ben“ – „toten“ Code kann man auch mit Power­Point präsentieren.

Die IDE für die Präsentation einrichten

Eine IDE ist von Haus aus kein Prä­sen­ta­ti­ons­werk­zeug. Um sinn­voll mit einer IDE zu prä­sen­tie­ren, sind meist Anpas­sun­gen notwendig:

• Die Schrift soll­te so groß wie irgend mög­lich gewählt wer­den. Die maxi­mal sinn­voll nutz­ba­re Schrift­grö­ße hängt natur­ge­mäß sehr stark vom zu prä­sen­tie­ren­den Code ab – die Schrift­grö­ße soll­te also erst end­gül­tig fest­ge­legt wer­den, nach­dem der Code für die Prä­sen­ta­ti­on vor­be­rei­tet wur­de (s. o.). Eine „Faust­re­gel“ für die mini­ma­le Schrift­grö­ße anzu­ge­ben, erscheint mir übri­gens wenig sinn­voll: Was noch erkenn­bar ist, hängt stark von der Grö­ße des Rau­mes ab.
• Das GUI der IDE soll­te mini­miert wer­den, es soll­te kein Platz für wäh­rend der Prä­sen­ta­ti­on nicht benö­tig­te Werk­zeug­leis­ten o. ä. ver­schwen­det wer­den. Even­tu­ell bie­tet der Edi­tor sogar einen „full-screen mode“, der zum Prä­sen­tie­ren geeig­net ist – dann soll­te man aller­dings beach­ten, dass der unte­re Teil des Bild­schirms u. U. aus den hin­te­ren Rei­hen nicht sicht­bar ist (s. u.).
• Die Syn­tax­her­vor­he­bung soll­te ggf. ange­passt wer­den. Was am eige­nen Moni­tor gut erkenn­bar und gut unter­scheid­bar ist, ist als pro­ji­zier­tes Bea­mer-Bild unter Umstän­den kaum noch erkenn­bar oder nicht aus­ein­an­der zu hal­ten. Gibt es (z. B. durch die Defaults einer extrem ver­brei­te­ten IDE) einen Stan­dard, soll­te man die­sen aller­dings mög­lichst nur behut­sam ver­än­dern – die (Code‑)​Lesegewohnheiten des Publi­kums sind meist recht aus­ge­prägt; das Publi­kum zu irri­tie­ren, ist wenig hilf­reich. Exis­tie­ren für die Syn­tax­her­vor­he­bung kei­ne Qua­si-Stan­dards, soll­ten erkenn- und unter­scheid­ba­re Far­ben gewählt wer­den. In jedem Fall emp­fiehlt es sich, die Farb­wahl mit dem für die Prä­sen­ta­ti­on vor­ge­se­he­nen Bea­mer zu tes­ten – am bes­ten unter rea­lis­ti­schen Licht­ver­hält­nis­sen. Zeigt man „klas­si­sche“ Foli­en (und nicht direkt die IDE), emp­fiehlt es sich, Screen­shots aus der IDE zu prä­sen­tie­ren – auf die­se Wei­se kann mit wenig Auf­wand die „nor­ma­le“ Syn­tax­her­vor­he­bung über­nom­men wer­den. Auch für Screen­shots aus der IDE gilt übri­gens natür­lich alles hier Gesag­te – und zusätz­lich der Hin­weis, dass die­se am bes­ten in der Ziel-Auf­lö­sung ange­fer­tigt (und nicht nach­träg­lich bis zur Unschär­fe ver­grö­ßert) wer­den sollten.

Raum und Bildschirm sinnvoll einrichten

Ist es im Fal­le „nor­ma­ler“ Prä­sen­ta­tio­nen manch­mal gera­de­zu eine Gna­de, nicht alle Zei­len der über­füll­ten Folie sehen zu müs­sen, ist dies beim Prä­sen­tie­ren von Code fatal: Prä­sen­tiert man Quell­code, kommt es auf jede Zei­le an. Pro­ble­ma­tisch ist nun, dass (abhän­gig davon, wie hoch die Lein­wand hängt) zumin­dest die hin­te­ren Rei­hen des Publi­kums meist nur die obe­ren zwei Drit­tel des Bea­mer-Bil­des wirk­lich sehen kön­nen – der Rest ist häu­fig von den Köp­fen der wei­ter vor­ne Sit­zen­den mehr oder min­der ver­deckt. In den meis­ten Vor­trags­räu­men lässt sich dem­entspre­chend nur der obe­re Teil des Bil­des wirk­lich für die Prä­sen­ta­ti­on nut­zen. Beson­ders fatal wirkt die­ses Pro­blem übri­gens bei „Live-Demos“ an der Kom­man­do­zei­le: Spä­tes­tens nach den ers­ten paar Befeh­len ist man am unte­ren Rand des Kon­so­len-Fens­ters ange­kom­men und das Gesche­hen fin­det womög­lich für gro­ße Tei­le des Publi­kums unsicht­bar statt. Es hilft nur eins: Beschrän­ken Sie sich auf den obe­ren Teil des Bild­schirms – und tes­ten Sie aus der letz­ten Rei­he, wel­chen Teil Sie trotz der vie­len Köp­fe zwi­schen Ihnen und der Lein­wand noch sicher sehen kön­nen. Die­ser Hin­weis gilt natür­lich auch, falls Sie Source­code mit „klas­si­schen“ Folien​⁴ prä­sen­tie­ren: Jede ein­zel­ne Zei­le muss auch von ganz hin­ten sicht- und les­bar sein. 

Gera­de bei „Live-Demos“ nei­ge ich dazu, das Pro­blem der hin­te­ren Rei­hen „im Eifer des Gefechts“ zu ver­ges­sen. Ich dis­zi­pli­nie­re mich falls nötig, indem ich die (Windows‑)​Taskleiste so ver­grö­ße­re, dass der unte­re Bild­schirm­be­reich davon ver­deckt wird​⁵. Die „work area“​⁶ wird dem­entspre­chend klei­ner und selbst maxi­mier­te Fens­ter wer­den nicht größer​⁷. Nun ist eine über­di­men­sio­na­le Task­leis­te zuge­ge­be­ner­ma­ßen nicht gera­de eine Zier­de. Ich habe mir des­we­gen ein klei­nes Script geschrie­ben, das die Task­leis­te tem­po­rär mit einem schwar­zen, rand­lo­sen Fens­ter über­deckt (sie­he Anhang 2).

Das Prä­sen­tie­ren von „leben­di­gem“ Quell­code ist eine der weni­gen Prä­sen­ta­ti­ons-Situa­tio­nen, in denen ich ein Red­ner­pult für sinn­voll (wenn nicht gar not­wen­dig) hal­te: Mit der IDE im Ste­hen zu prä­sen­tie­ren ist ohne Red­ner­pult nahe­zu unmög­lich. Ein­zig Ste­hen aber (im Gegen­satz zum Sit­zen des Publi­kums) erscheint mir für den Refe­ren­ten sinn­voll, es unter­streicht die Rol­le als Vor­tra­gen­der. Ein sit­zen­der Refe­rent wirkt auf mich, als wür­de die Rol­le nicht wirk­lich ange­nom­men oder gar abgelehnt.

Nicht nur Code

Prä­sen­tiert man mit der IDE, wird der Bild­schirm auf den Bea­mer gespie­gelt. Möch­te man nun zusätz­lich Foli­en zei­gen, erfor­dert dies min­des­tens einen Wech­sel des Pro­gramms und meist sogar eine Ände­rung der Bild­schirm-Kon­fi­gu­ra­ti­on – eine Ände­rung, die bspw. Power­Point unter Umstän­den sogar auto­ma­tisch durch­führt und die man anschlie­ßend müh­sam rück­gän­gig machen muss. Plant man einen sol­chen „Medi­en-Mix“, ist eine voll­stän­di­ge und rea­lis­ti­sche Gene­ral­pro­be drin­gend angezeigt.

Sofern der Raum nicht zu groß ist, um dar­auf auch aus den hin­te­ren Rei­hen noch etwas zu erken­nen, emp­fiehlt es sich m. E. immer, ein Flip­chart oder ein White­board bereit­ste­hen zu haben. Der hoch­gra­dig inter­ak­ti­ve Cha­rak­ter des Prä­sen­tie­rens mit der IDE erfor­dert die Mög­lich­keit, aus dem Steg­reif visua­li­sie­ren zu kön­nen. Damit schließt sich dann auch der Kreis hin zum eigent­li­chen The­ma von Buch und Blog: Dem spon­ta­nen Visua­li­sie­ren von IT-The­men an White­board und Flip­chart. Das Flip­chart steht hier im sel­ben Ver­hält­nis zu Power­Point wie die IDE: Bei­de ermög­li­chen das spon­tan-inter­ak­ti­ve, leben­di­ge Präsentieren!

Anhang 1: Checkliste „Lebendig(en) Quellcode präsentieren“

Die­se Check­lis­te ist der Anhang zum Arti­kel „Lebendig(en) Quell­code prä­sen­tie­ren“ – gewis­ser­ma­ßen die extrem ver­kürz­te Zusam­men­fas­sung. Der ers­te Punkt der Check­lis­te ergibt sich damit qua­si automatisch:

Anhang 2: Script zum Überdecken der Taskleiste

Vor rund 15 Jah­ren habe ich „die Sei­ten gewech­selt“ – weg von der (Datenbank‑)​Softwareentwicklung hin zu IT-Infra­struk­tur-The­men. Seit­dem ist es eher sel­ten gewor­den, dass ich Code schrei­be – und wenn, dann eher kur­ze und lan­ge Scripts, inzwi­schen meist in Power­Shell oder wie in die­sem Fall (gera­de beim rela­tiv sys­tem­na­hen „Bas­teln“) auch gern mal mit AutoIt <https://​www​.autoit​script​.com/>. Das fol­gen­de Script ver­deckt die Task­leis­te durch ein schwar­zes, rand­lo­ses Fens­ter, das sich bei Drü­cken von Esc schließt. Es ist weder „schön“ noch beson­ders inno­va­tiv; wie viel­leicht typisch für Scrip­te ist es wirk­lich nur „fit for pur­po­se“ – z. B. geht es davon aus, dass die Task­leis­te sich am unte­ren Bild­schirm­rand befin­det. Mir hilft es – aber viel­leicht fin­det sich ja bei­zei­ten jemand, der sich die Mühe macht, das Pro­blem über eine schwar­ze, rand­lo­se AppBar​⁸ ganz all­ge­mein und deut­lich ele­gan­ter zu lösen. Bis dahin kann ein Jeder gern auf eige­ne Gefahr und ohne jede Gewähr den fol­gen­den Code nut­zen, für sich anpas­sen und ggf. sogar der Ein­fach­heit hal­ber kom­pi­lie­ren – wer die­ses Script für sei­ne Prä­sen­ta­ti­on braucht, wird ver­mut­lich auch damit klarkommen.

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <WinAPIGdi.au3>
#include <WinAPISys.au3>

AutoItSetOption('GUICloseOnESC', 1)

$hWorkArea = _WinAPI_GetWorkArea()
$dwWorkAreaWidth = DllStructGetData($hWorkArea, 'Right') - DllStructGetData($hWorkArea, 'Left')
$dwWorkAreaHeight = DllStructGetData($hWorkArea, 'Bottom') - DllStructGetData($hWorkArea, 'Top')

$aCurrentDisplaySettings = _WinAPI_EnumDisplaySettings('', $ENUM_CURRENT_SETTINGS)
$dwDisplayWidth = $aCurrentDisplaySettings[0]
$dwDisplayHeight = $aCurrentDisplaySettings[1]

Global $dwWindowHeight = $dwDisplayHeight - $dwWorkAreaHeight
Global $dwWindowWidth = $dwDisplayWidth
Global $dwWindowX = 0
Global $dwWindowY = $dwWorkAreaHeight

Global $hWindow = GUICreate('HideTaskBar', _
   $dwWindowWidth, $dwWindowHeight, _
   $dwWindowX, $dwWindowY, _
   $WS_POPUP, _
   $WS_EX_TOPMOST)

GUISetBkColor(0x000000, $hWindow)

GUISetState(@SW_SHOW, $hWindow)

While 1
   $nMsg = GUIGetMsg($hWindow)
   Switch $nMsg
      Case $GUI_EVENT_CLOSE
         Exit
   EndSwitch
WEnd

GUIDelete($hWindow)