Die Computermaler

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​1: Es hat wohl fast jeder Ent­wick­ler schon hunderte​2 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 inter­agie­ren.

Nun könn­te man anneh­men, man könne sich auf diese Weise 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 beach­ten:

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:

{
     abort();
}
{ abort(); }

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 not­wen­dig:

Raum und Bildschirm sinnvoll einrichten

Ist es im Falle „nor­ma­ler“ Prä­sen­ta­tio­nen manch­mal gera­de­zu eine Gnade, 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 Zeile 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 vorne 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 obere 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 Teile 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 Reihe, wel­chen Teil Sie trotz der vie­len Köpfe 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​4 prä­sen­tie­ren: Jede ein­zel­ne Zeile muss auch von ganz hin­ten sicht- und les­bar sein.

Gera­de bei „Live-Demos“ neige 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​5. Die „work area“​​6 wird dem­entspre­chend klei­ner und selbst maxi­mier­te Fens­ter wer­den nicht größer​7. 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 (siehe 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) halte: 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 Rolle als Vor­tra­gen­der. Ein sit­zen­der Refe­rent wirkt auf mich, als würde die Rolle nicht wirk­lich ange­nom­men oder gar abge­lehnt.

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 ange­zeigt.

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 Thema 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: Beide ermög­li­chen das spon­tan-inter­ak­ti­ve, leben­di­ge Prä­sen­tie­ren!

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

Diese 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 erste Punkt der Check­lis­te ergibt sich damit quasi auto­ma­tisch:

  • Habe ich den voll­stän­di­gen Arti­kel gele­sen?
  • Den Code für die Prä­sen­ta­ti­on anpas­sen:
    • Unnö­ti­ge Zei­len­um­brü­che z. B. bei { } ent­fer­nen
    • Ein­rü­ckun­gen redu­zie­ren
    • Kom­men­ta­re ent­fer­nen
    • Ist der Code noch lauf­fä­hig?
  • Die IDE für die Prä­sen­ta­ti­on ein­rich­ten:
    • Schrift­grö­ße so groß wie irgend mög­lich wäh­len
    • Unnö­ti­ge Werk­zeugleis­ten etc. schlie­ßen
    • Die Far­ben der Syn­tax­her­vor­he­bung ggf. für den Bea­mer anpas­sen (tes­ten!)
  • Raum und Bild­schirm ein­rich­ten:
    • Die Unter­gren­ze des aus der letz­ten Reihe noch erkenn­ba­ren Bild­schirm­aus­schnitts tes­ten
    • Die Task­leis­te hoch­zie­hen und den nicht erkenn­ba­ren unte­ren Bereich bede­cken las­sen
    • Die Task­leis­te ggf. per Script schwarz über­de­cken
    • Steht ein Red­ner­pult zur Ver­fü­gung?
    • Steht zusätz­lich ein Flip­chart oder White­board zur Ver­fü­gung?

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 kurze und lange Scripts, inzwi­schen meist in PowerS­hell oder wie in die­sem Fall (gera­de beim rela­tiv sys­tem­na­hen „Bas­teln“) auch gern mal mit Auto­It https://​www​.auto​it​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 AppBar8 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 seine Prä­sen­ta­ti­on braucht, wird ver­mut­lich auch damit klar­kom­men.

#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)