Debugging konference 26. oktober - uden titel?

Hvad blev det til med tilmelding?

Kenneth og jeg har lavet første version af konferenceprogrammet. Der var flere talere end vi havde plads til, så nogle har vi måtte sige nej tak til. Planen er fortsat at åbne op fredag med program og billetter.

Kneth og jeg har lavet titel for konferencen

• Titel: Debugging - for rigtige programmører.
• Undertitel: En dag fyldt med fejl

Vi laver program i aften og vi har mange gode forslag til at lave et godt program så er sidste chance i dag for ekstra talere :)

Anyone?

Jeg har desværre ikke mulighed for at deltage, da jeg har eksamen i den periode. Bliver der noget livestream eller upload af foredragene bagefter?

Det ku' være godt med så'n en konference, så godt initiativ herfra.

Jeg bruger primært gdb og Immunity Debugger til alt lowlevel debugging og de kommer med Python bindings, som jeg har haft glæde af, men desværre ikke nok til at kunne sige meget intelligent om det :-(

Men det kunne andre måske?

• og når alle de smarte værktøjer kommer til kort - eller at produktiondkoden er udviklet på så gammel en platform, at der ikke findes seje værktøjer til at debugge. Min erfaring siger at debugging handler mere om at tænke sig om end at benytte smarte værktøjer. Det kan også nemt være, at smarte værktøjer påvirker produktionsmiljøet for meget. Det dur ikke at pause en enkelt proces ud af de mange kørende processer, det skaber i sig selv en stribe andre problemer.

Så:

1. hyppigheden af fejlen siger en hel masse om hvilken klasse af fejl det kan være. Memory leak, race conditions, overflow, ...
2. Del og hersk: Smart brug af print/printf debugging deler problemet i 2 eller 3 halvdele. Efter et par omgange med binær søgning er der meget lidt kode tilbage at debugge ved nærlæsning.

Debug

Evt. @DebugCph

Med underteksten:

• Find fejlene før din chef
• Find fejlene før din kunde
• Find fejlene før din kunde's chef
• Find fejlene før din kundes advokat

:)

Jeg har udviklet web-applikationer i over 10 år - og som du ganske rigtigt fremhæver, så hører det ikke hjemme i skolen (eller mange af de bøger man kan læse om udvikling).

Selv er jeg resultat af en tid, hvor vi livligt delte kode med hinanden. Det var før Open Source var noget man talte om, man delte blot kode med hinanden og opdagede man at nogen havde stjålet ens kode... ja, så blev man med stor sandsynlighed venner. For blot 10 år+ siden, delte man kode og man fik feedback til sin kodning. Den feedback jeg fik fra online-venner dengang, har været uundværlig. Uden den ville jeg fortsat lave applikationer der var åbne for "code injection".

Når det kommer til debugging i dag, er det "sjove" at mange begår fodfejl. Ofte der er tale om at udviklerne ikke kender til kvalerne for ti år siden. Skal en udvikler i dag tage en query-string og komme den ind i en database, er det langtfra sikkert at udvikleren undgår "code injection". Der er meget fokus på "standard" sikkerhedshuller, hvilket også er begrundet, men der er sjældent fokus på dårlig programmering.

Jeg vil derfor håbe, at der er nogle dygtige folk, som kan fortælle om sikkerhedshuller i forbindelse med dårlig programmering.

"Segfault"

Jeg er på nuværende tidspunkt i gang med at udvikle et større mini framework til C programmering og jeg er faktisk ikke stødt ind i de helt store problemer i forbindelse med fejlfinding, en af grundene til dette er at jeg har tænkt en del over hvordan de forskellige komponenter skal designes såleles at fejlfinding er relativt nemt, og det på trods af at der mit første relle C program jeg har programmeret, derfor burde komponent design eller design af kode ligeledes være en del af konferencen ellers ved jeg ikke lige hvad jeg kan bidrage med.

Hilsen en hobby programmør

Det ville være rigtig fedt med et indlæg om håndtering af debug symboler og crash dumps herunder opsamling. Emner kunne inkludere

• symbol servere på Windows og hvad der findes på Linux (e.g debuginfo rpms)
• abrt på Linux (fedora/redhat)
• Windows Error Reporting (WER)
• cross-platform i form af google breakpad

Jeg synes at konferencen kunne hedde:

• Debug++
• Fejlfindingskonference med undertitlerne:
• "Det virker hos mig"
• "Det var da sært..."
• "Fejl kommer ikke alene"
• "Det har jeg ikke set før"
• "Det er en kendt fejl"
• "Det har det aldrig gjort før"
• "Det sker nok ikke igen"
• "Det virkede i går"

Må jeg foreslå ovenstående emne.

Jeg underviser på en ingeniøruddannelse. Jeg giver en introduktion til debugning på embedded systemer sammen med en kollega. Jeg - kan man sige - fra software siden og min kollega - som er mere hardware orienteret - mere low level.

Vi har ikke så meget lækkert grej, som man måske har til rådighed i industrien, hvor man måske sidder med opgaven i lang tid. Vi har ikke tid til en længere seance med opsætning og konfiguration. Vi hænger oftest ikke så længe ved emnet, da der jo er meget andet stof, som skal undervises. Samtidig er de projekter, som vi roder de studerende ud i oftest ikke af større omfang end at man kan overskue dem og måske klare sig med "printf" og loggen.

Jeg introducerer forskellige debug-teorier og gdb-server og gdb/Eclipse introduceres, som anvendelige værktøjer, og en simpel opstilling øves. Men mere bliver det oftest ikke til på grund af tidsnød. Det kunne sagtens blive et et helt fag for sig selv er min vurdering.