Dette indlæg er alene udtryk for skribentens egen holdning.

Skal vi lave en mini-konference om debugging?

3. juli 2013 kl. 18:4150
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Som I nok ved har jeg i mange år været med til at lave Linuxforum/Open Source Days konferencer i et fantastisk team.
Forrige år lavede min gode ven Kenneth Geisshirt og jeg Emacsforum-konferencen - lille, sjov og markant nemmere at arrangere.
I samme "mindre" niveau vil jeg gerne lave en konference med fokus på "Debugging med Linux/BSD".

Min pointe er at "debugging" bare ikke læres på universiteterne - og det er skammeligt. Jeg har skrevet om dette tidligere.
Derfor må vi samles fra tid til anden og udveksle erfaringer - og i denne kontekst UNIX/Linux/BSD-værktøjer. Jeg forestiller mig, at det med fordel kan blive en dag, hvor der lægges vægt på hands-on erfaringer, praktiske teknikker, og gerne focus på værktøjer, der kan hjælpe til at finde fejl automatisk.

Jeg forestiller mig, at der kommer 50-100 Linux/BSD folk og meget gerne jer, som har "skidt på hænderne". Jer som har debugget grimme ting, som har lært en masse af det og gerne vil præsentere hvordan I kom igennem, så andre kan lære af det.
Eventen kan vi holde i september eller lignende, omkring København - gratis - enten hos et firma eller på en læreanstalt. Hvis I har lyst til at være vært for det - skriv til mig :-)
Hvis der kommer begræsninger på antal sæder, så bliver det "bedste foredrags-bidrag" kommer først ind.

Lad mig endda lave et eksperiment af de sjove:

  • Grov-planlægningen kan ske (indtil videre) i et Google-dokument, jeg har delt.
  • Egentlig diskussion kan f.eks. nedenfor eller på min Google+ profil
  • Det som er meget vigtigt de næste par uger er at få lavet nogle grove rammer for et dagsprogram, og hvis I kan og vil bidrage, så skriv jer på eller stik mig en email om det .

Er I friske?

Artiklen fortsætter efter annoncen

/pto

50 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
49
24. september 2013 kl. 08:49

Deltager

48
16. august 2013 kl. 16:41

Jeg ved skam godt hvor vigtigt der er debugge, eller blot fejlfinding på dansk, hvilken det vel egentlig handler om.

Jeg ved godt at C programmering stort set er fortid ligesom hestevogne og lignende ting, men!, er der noget man som programmør eller blot hobby programmør, nu er jeg ganske vist hobby programmør i fritiden, og så er det udfordringer altid en lærerig process. Jeg har i et stykke tid haft gang i et mini framework til C programmer, og der er da heller ingen tvivt at fejlfinding er godt ting, men godt skrevet kode er nogen gange bedre end fejlfinding, hvilken jeg kan give et godt eksempel på.

Sidst jeg havde gang i mit mini framework stødte jeg på et tidspunkt ind i den klassiske 'index out of bounds' fejl, jeg var 100 procent sikker på at der ingen fejl var, og det var der så heller ikke, fejlen lå i den nye kode, fordi jeg have glemt trække 1 fra bruger input hviklen resultere i index 1, som ikke eksisterede der da kun var et element i den pågældende array jeg havde fat i.

Jeg er ganske vist selvudlært programmør og administrator, men jeg vil da alligevel gerne deltage i den der mini-konference hvis det bliver til noget.

47
16. august 2013 kl. 14:40

Jeg så at der er kommet mange gode forslag i Peters Google+ dokument. Er det snart tid for en dato ? Der er vel nok på programmet til en hel lørdag eller søndag ?

46
13. juli 2013 kl. 20:03

Uden tvivl. På en hverdag er jeg 100% med. Men i weekenden er det ikke helt sikkert.

45
9. juli 2013 kl. 09:23

Jeg foretrækker hverdag. Og jeg ser frem til en dato/tilmelding. Jeg foretrækker helt klart også at fokus er på "erfarende folk, der deler erfaring". Niveauet må godt være så højt som muligt. (Det skal være højt.)

42
9. juli 2013 kl. 07:57

Det ville jeg være meget opsat på at være med som tilskuer.

41
9. juli 2013 kl. 00:55

Jeg har et enkelt spørgsmål som jeg gerne vil have meget feedback på: Skal vi holdet eventen en lørdag eller en hverdag?

Tidligere har vi holdet meget i weekender - men er det ved at være lige meget?

44
9. juli 2013 kl. 08:40

Jeg stemmer godt nok for en weekend, da det ellers kan være svært at nå.

43
9. juli 2013 kl. 08:37

Jeg stemmer for en hverdag

40
9. juli 2013 kl. 00:48

Det tegner til at blive et meget lærerigt arrangement. Jeg deltager meget gerne, hvis det kan passe i min kalender.

39
8. juli 2013 kl. 09:11

De steder hvor jeg synes det trækker flest tænder ud at debugge er, når fejlen viser sig at være i noget af den standard funktionalitet / system libraries som man normalt antager er velfungerende. Specielt når fejlene er inkonsistente.

Man kan ikke have styr på hele kode-stacken. Og slet ikke på andre maskiner, hvor der måske er en patch mere eller mindre.

36
6. juli 2013 kl. 22:45

Hej Sune

Det synes jeg fremgår af Peters oprindelige blogindlæg: Et oplæg for folk som ikke har lært at bruge debugging til dagligt, gerne hvor oplæg holdes af folk som har erfaring. Synes du at brainstormen i kommentarerne antyder at et andet slags oplæg ville ende med at blive afholdt?

35
6. juli 2013 kl. 21:30

Jeg er kommet lidt i tvivl om - er målet at lære nye folk at debugge eller er holde hyggearrangement for den gamle garde?

/Sune

34
6. juli 2013 kl. 12:30

Jeg håber, der er nogen som føler sig inspireret til at snakke om nogle af følgende emner. :-)

Valgrind og memory profiling i forskellige sprog (gerne .NET, Haskell, Erlang), git commit hooks, Coccinelle, anvendelse af quickcheck i erhvervslivet (hvis det findes?), og meget gerne nogle succesfulde erfaringer fra erhvervslivet om hvordan man vender en virksomhed til at lave afprøvning -- hvordan man måler den økonomiske gevinst, hvad der skulle til for at ændre kulturen på alle niveauer i virksomheden.

28
5. juli 2013 kl. 15:03

Hej, jeg vil meget gerne være med som tilskuer, selvom jeg ikke er haj til hverken 'nix eller git.

27
5. juli 2013 kl. 13:34

Jeg kan se i dit dokument at du har listet "LLVM - deres statiske kodeanalyzer." Til dagligt bruger jeg Flexelint - ville det være interessant? (ganske vist payware men meget billigt i forhold til insure++/fortify/...)

Det kunne også være interessant med en gennemgang af systemværktøjer til at debugge i et produktionsmiljø (pstack, pstree, strace, ltrace, lsof, ...)

25
5. juli 2013 kl. 11:55

Kan emnet udvides lidt ? Hvad med noget om at skrive bedre kode ? Jeg kan bidrage med et foredrag om forbedring af shell-script kode.

26
5. juli 2013 kl. 12:56

Martin, skriv det ind. Det er selvfølgelig lidt afhængig af hvor mange der byder ind så hellere have lidt for mange tanker/ideer

23
5. juli 2013 kl. 08:26

Giver gerne en hånd med hvis der er noget praktisk der skal klares. (På dagen dog kun hvis datoen har lidt WAF)

22
4. juli 2013 kl. 13:31

Jeg synes det er en rigtig god ide! Det har også undret mig, at man ikke underviser i debugging m.v. på universiteternes IT-uddannelser (jeg kender kun RUC, men jeg kunne regne ud at det var det samme andre steder).

Må jeg have lov at bruge denne invitation i DK-uug Nyt blad nr. 171 (som snart skal laves færdigt)?

24
5. juli 2013 kl. 10:18

Jepper

20
4. juli 2013 kl. 13:07

I kan debugge Darkleech

18
4. juli 2013 kl. 12:13

Jeg vil meget gerne med som tilskuer

15
4. juli 2013 kl. 11:36

Jeg er ikke helt klar over forskellen på preventiv og anti debugging. Google har ikke rigtigt hørt som Preventiv debugging før :-)

Er det anti-debugging som f.eks. følgende Windows link:http://www.symantec.com/connect/articles/windows-anti-debug-reference

eller lave programmer, der er lette at debugge som f.eks:http://www.cprogramming.com/debugging/debugging_strategy.html

Personligt foretrækker jeg mange meget simple if-sætninger. Ofte er det nok at køre en profiler for at finde fejlen.

NB: Bliver der snart frigivet nogle slides/videos fra Open Source Days 2013?

11
4. juli 2013 kl. 09:48

Her: https://plus.google.com/100210281016644182390/posts/p/pub

Bla. om debugning i (F)OSS webudvikling m. MySQL, PHP, Javascript HTML(5).

@Martin: Uddannelse i formelle metoder, software engineering og programmering forholder sig til realiterene ligesom køreskoleundervisning forholder sig til at manøvrerer en fyldt, lejet familieflytter med ikke-virkende AC gennnem en italiensk by i myldretiden for at nå et fly.

Det kan godt være dit design er lige i øjet og din kodning er pletfri, men det skal integreres med noget dine kollegaer har lavet for et par år siden og/eller et bibliotek eller bedre - en oversætter - med nogle subtile fejl. Samtidig står din ikke-tekniske chef og råber noget, hvor ordet 'deadline' indgår. Det er så her man debugger for at forstå, hvorfor skidtet virker, pånær når man henter record 25-30 samt 231, 452 og 100251 fra databasen - 452 er forøvrigt magen til record 2,3,7 og 45, der jo virker - go figure :)

10
4. juli 2013 kl. 09:35

Det kunne være fint med et indlæg om Coccinelle, som man kan bruge til at finde flere at samme type fejl når man har fundet den første.

Omkring fejlfinding, så er der også hele analyse tilgangen til problemet før man vælger værktøjer. Vi fik en gang sidste år en fejl rapportret fra en af vores kunder. Fejlen kom med måneders mellemrum. Ingen ande de mange andre kunder der benytter samme software har oplevet fejlen. Det væsentligste input til at finde fejlen var hyppigheden. Den var kun den ene kunde der så fejlen, da de har langt større produktion end de andre kunder. Altså statistisk set kunne det fint passe at alle kunder har fejlen, men at kun een kunde havde oplevet den. Det kunne ikke være et memory leak for det ville ske langt hyppigere. Det måtte være timingsrelateret. Dette var nok til at vi kunne lave en testopstilling med delsystemet kørende på mange CPU kerner og så reproducere fejlen i laboratoriet. Slutteligt fandt vi fejlen i en driver hvor der manglde den rette sem semaforbeskyttelse af nogle variabler.

9
4. juli 2013 kl. 09:18

No offense - men er debugging ikke mest for folk der ikke kan kode ordentligt?

Helt for egen regning vil jeg påstå at debugging er tests og designs grimme fætter, og at det derfor ikke er i fokus på læreanstalterne.

Hvis man designer sit stads ordentligt, er lidt omhyggelig med sin modularisering, har noget god kodepraksis hvor man får får ting der er forkerte til at se forkerte ud ("make wrong code look wrong"), og iøvrigt har nogle solide tests der viser at ens moduler gør det man beder dem om, så er debugging ikke fyldigt nok til at være en selvstændig diciplin.

... det var lidt tankegangen da jeg havde datalogi på universitetet. Fokus på design og test (og dermed kravspecs), og ikke andet end "debuggeren finder I her, hvis I har for vane at lave fejl" når det kom til debugging.

Nu var det også mest højniveau (objektorienterede) sprog man kylede efter os. Den smule erfaring jeg har med C (som jo nok er det der er jeres omdrejningspunkt), siger mig at C er kropumuligt at kode i efter devicen "make wrong code look wrong". Når C-programmører skal spille hårde overfor hinanden, er det jo noget med at vise hinanden noget minimalistisk og dybt kryptisk kode, som gør noget rasende smart, men som er helt umuligt for gennemsnitsprogrammører at gennemskue.

Jo tak, fordi I skal vise jer overfor hinanden, får vi noget kode der er kropumuligt at fejlfinde i og vedligeholde for den næste programmør, som måske ikke har jeres evner. Så hvis målet er jeres personlige jobsikring, er det da måden at gøre det på.

Og så kan jeg godt forstå at debugging bliver en stor diciplin...

Var det ikke en idé at få lidt input fra Anne Mette Hass fra bloggen om test og kravspecifikationer æltet ind i denne dej? Og så en Version2-blogger der kan sige noget fornuftigt om design (så vidt jeg kan se er der ingen V2-blog rettet specifikt mod design)?

Og igen - No offense! Selvom det måske ligner kritik af værste skuffe, så er det konstruktivt ment. Debugging er jo ret beset en uønsket aktivitet - det man ønsker er jo at lave noget kode der duer i første hug, og alternativt er til at fejlfinde i blot ved at kigge koden igennem eller køre en simpel test.

Så sagt med andre ord: Sidder man og opdager at man er blevet utroligt dygtig til at debugge, bør man overveje om man ikke hellere skulle smide ressourcer efter proaktivt at lave noget kode man har styr over og som virker, fremfor at jagte bugs i noget kode, som man åbenbart ikke har styr over.

Jeg har stillet den store spand frem, som kan indeholde downvotes, men jeg vil foretrække hvis I kan motivere og argumentere for hvorfor der skal så stor fokus på debugging - rent akademisk kan jeg ikke se det giver mening.

50
24. september 2013 kl. 10:31

No offense - men er debugging ikke mest for folk der ikke kan kode ordentligt?

+1

Jo det er.

Debuggeren skal man holde sig fra og bruge som last resort. Dog kan man jo have overtaget noget forfærdelig skrammel uden tests, der er den uvurderlig. Men jeg ser også alt for ofte folk der udvikler i debuggeren!!!

Den er til nedrivning af forkert byggede elementer så nye kan opføres korrekt. The right tool for the job. Unit tests mv. finder fejl i dag, ikke debuggeren. Den leder til at fejl rettes forkert.

En ofte set (af mig) practise er at debuggeren bliver brugt til at lokalisere en anormalitet, som så rettes med nogle betingede instruktioner, der tager højde for netop den tilstand programmet har opnået. Problematikken er dog oftest at det er fordi at de antagelse man havde gjort sig om hvordan verden hænger sammen, ikke holder vand og derfor må man "tegne" et nyt billede. Det sker bare ikke, man hacker bare løs i debuggeren til det bliver holdt sammen af ølkapsler, elastikker og tyggegummi.

21
4. juli 2013 kl. 13:18

Ud over de fejl-antagelser, folk allerede har påpeget, at du gør, så glemmer du også hardwaren. Software-debugging er en uundværlig disciplin for at finde fejl i hardwaren, det værende sig kontruktionsfejl, komponentfejl eller produktionsfejl...

33
5. juli 2013 kl. 17:11

Debugging er også for opgaver, hvor det er umuligt at forudsige alle fejlkilder på forhånd. F.eks. i forbindelse med kommunikation med eksterne blackbox-enheder.

Man kan aldrig teste i bund, eller designe robusthed overfor alle tænkelige og utænkelige eksterne parametre - Enig.

Men når du debugger står du med en konkret fejl, dvs en af dine antagelser i koden/designet/specifikationen ikke holder. Og så er det nok så værdifuldt lige at repetere disse antagelser for at se om man rent kognitivt kan gennemskue om de holder under et ændret verdensbillede.

29
5. juli 2013 kl. 16:02

Du mener ligesom "Gud skabte heltallene, resten er menneskeværk" ?

Nej, mere henad ligesom våde analogi-skruetrækkere.

Debugging er et fact of life, om ikke andet fordi folk rammer de forkerte taster når de er søvnige om morgenen eller hvis kaffe-indholdet i deres blod er udenfor tolerance.

Nu var min påstand ikke at debugging burde være ikke-eksisterende - blot at jeg er blevet skolet i at det ikke burde kunne fylde nok til at udgøre et selvstændigt akademisk emne.

Og da slet ikke, hvis det bedste du kan diske op med er slåfejl.

14
4. juli 2013 kl. 10:10

Dit indlæg forudsætter at der er tale om nyudvikling. Jeg kan ikke lige huske hvad kilden er, men jeg er en gang blevet udsat for den påstand at størstedelen af kodearbejde er vedligeholdelse af eksisterende systemer. Hvad hvis du skal arbejde med et 10, 20, 30 eller 40 år gammelt system hvor arkitekturen er ikke-eksisterende og den hyppigst forekommende instruktion er "G***-ordet"? Så hjælper det dig ikke særligt meget at sætte dig over i hjørnet og rokke frem og tilbage imens du messende gentager: "Det ville ikke være nødvendigt at debugge hvis arkitekturen var i orden."

Pointen er at det er ikke alt kode du skal arbejde med du selv har skrevet eller endda at nogen der stadig arbejder i firmaet har skrevet.

I øvrigt kan man også sagtens lave javakode med en voldsom accidental kompleksitet, det er bare nemmere i C.

13
4. juli 2013 kl. 10:09

Jeg er enig i at et godt design kan være med til at reducere mængden af fejl i koden. Jo bedre design, jo mindre spillerum er der til fejl der opstår på grund af forkerte implicitte antagelser.

Men jeg er ikke enig i din din opfattelse af test i forhold til debugging. Skal jeg være lidt fræk, så vil jeg påstå at test kun fanger indlysende fejl. Så hvis man kan nøjes med tests så er alle ens fejl indlysende.

Desuden er tests ofte kun den lette del af processen. Det handler bare om at opdage at der er en fejl, debugning går skridtet dybere og forsøger at forklare hvorfor der er en fejl og hvordan den rettes. Hvis man ikke er parat til at gå dette ekstra skridt, så kan man vel lige så godt droppe overhovedet at teste sit program.

Kort sagt: Debuggen er den process man begynder når ens tests siger at der er et problem. Og efter man har debugget sig til hvorfor man har et problem er det selvfølgelig indlysende og så bør man kunen teste automatisk for det.

Grænsen mellem de to aktiviteter er selvfølgelig flydende. I et vist omfang er debugning ofte "bare" at skrive flere tests. Regressionstests er så kunsten at vælge hvilke af disse tests man bør beholde efterfølgende.

32
5. juli 2013 kl. 17:02

Jeg er enig i at et godt design kan være med til at reducere mængden af fejl i koden. Jo bedre design, jo mindre spillerum er der til fejl der opstår på grund af forkerte implicitte antagelser.

Helt enig

Men jeg er ikke enig i din din opfattelse af test i forhold til debugging. Skal jeg være lidt fræk, så vil jeg påstå at test kun fanger indlysende fejl. Så hvis man kan nøjes med tests så er alle ens fejl indlysende.

Enig.

Desuden er tests ofte kun den lette del af processen. Det handler bare om at opdage at der er en fejl, debugning går skridtet dybere og forsøger at forklare hvorfor der er en fejl og hvordan den rettes. Hvis man ikke er parat til at gå dette ekstra skridt, så kan man vel lige så godt droppe overhovedet at teste sit program.

Delvis enig.

Du tester for at vise at dit program opfører sig i overensstemmelse med specifikation og design.

Betragt det som et laboratorieforsøg for at påvise din påstand om, at dit program virker i henhold til spec/design.

Du laver heller ikke laboratorieforsøg, fordi du forventer at tyngdekraften er gået i stykker, eller fordi du forventer vand er blevet uhyre brændbart. Du gør det for at underbygge en hypotese.

Men ja - hvis din test viser at din hypotese ikke holder, må du jo i gang med at kigge kode igennem. Hvis det ikke er lykkedes at få forkert kode til at se forkert (nok) ud, er der debugging for resten af pengene.

Nogle har sikkert tendens til at fare direkte i debuggeren. Jeg finder derimod den mentale øvelse i at køre koden i wetware meget mere givende: -Man tilegner sig koden langt bedre (apropos den fejlslutning om at jeg antager at man selv er forfatter til koden, ovenfor). -Man bliver uafhængig af om compiler, "runtime environment", hardware og debugger fungerer korrekt. Man er kun afhængig af sin egen abstraktionsevne - en evne som iøvrigt forbedres jo mere den trænes, og som kan bruges i ufatteligt mange andre sammenhænge end kodning.

Kort sagt: Debuggen er den process man begynder når ens tests siger at der er et problem. Og efter man har debugget sig til hvorfor man har et problem er det selvfølgelig indlysende og så bør man kunen teste automatisk for det.

Ja - eller efter kodelæsning/kørsel i wetware. Se iøvrigt ovenfor.

Grænsen mellem de to aktiviteter er selvfølgelig flydende. I et vist omfang er debugning ofte "bare" at skrive flere tests. Regressionstests er så kunsten at vælge hvilke af disse tests man bør beholde efterfølgende.

Enig. Jeg håbede at "grim fætter" indikerede en form for familierelation mellem disse aktiviteter.

12
4. juli 2013 kl. 10:03

Hvem siger:

  1. At du har lavet koden, du skal rette fejl i?
  2. At fejlen i det hele taget ligger i den kode, du skal rette i, og ikke i et andet system, hvortil der er interface?
  3. At fejlen ikke er opstået som følge af ændringer i 3 parts libraries, operativ systemer eller databaser.

Debugging er et af de mest brugbare værktøjer, hvis man har kode der rent faktisk bliver brugt (af andre).

31
5. juli 2013 kl. 16:26

</p>
<ol><li>At du har lavet koden, du skal rette fejl i?

Den har jeg lige adresseret - det gælder om at have styr over den kode man roder med, uanset om det er ens egen eller Ruder Konges.

2) At fejlen i det hele taget ligger i den kode, du skal rette i, og ikke i et andet system, hvortil der er interface?

Det er en rigtig god pointe. Det er også der jeg af erfaring ser den største anvendelighed af debugging.

Det er dog tilpas sjældent jeg er rent ind i den situation, så det kan godt være at mit indlæg bærer præg af at jeg er forvent med at spille bold op ad kvalitetssoftware.

Jeg vil mene idealsituationen som vi bør søge hen imod er at blive bedre til at lave kvalitetssoftware, fremfor at acceptere lav kvalitet, og så brænde al produktiviteten af på at rende rundt og klaske hinandens bugs.

Måske er tilgangen for akademisk, men debugging er ikke værdiskabende som sådan, og fokus bør være på at forhindre det i stedet for at blive verdensmestre til det.

Altså mere fokus på at gøre de rigtige ting, fremfor at gøre debugging rigtigt.

3) At fejlen ikke er opstået som følge af ændringer i 3 parts libraries, operativ systemer eller databaser.

Det er vist en variation af 2)...

Debugging er et af de mest brugbare værktøjer, hvis man har kode der rent faktisk bliver brugt (af andre).

Opfattelsen af at jeg er imod debugging er forfejlet - jeg debugger jævnligt, og det er en helt nødvendig diciplin. Men slet ikke i det omfang som der lægges op til her.

Og idealsituationen er ikke at bruge kræfterne på at debugge, men på at lave og levere noget ordentligt software - og her er der altså langt mere perspektiv i design og test.

37
7. juli 2013 kl. 10:16

Den har jeg lige adresseret - det gælder om at have styr over den kode man roder med, uanset om det er ens egen eller Ruder Konges.

Du har vist ikke prøvet at arve kode, der er lavet af Indiske offshore udviklings ressourcer :-D

Der er ikke styr på noget som helst.

Jeg er for så vidt enig i din tilgang med testdreven udvikling, men der kan jo også være fejl i en testcase. Derfor vil test ikke kunne erstatte debugging.

Det er slutteligt den måde man finder frem til, om det er testen eller koden, der er fejlbehæftet.

7
4. juli 2013 kl. 08:26

Vil brug af automatisk test integreret i gits commit procedure kunne karakteriseres som en form for debugging?

I et nyt projekt, jeg deltager i, har vi indarbejdet automatisk integrationstest i gits commit procedure som en del af continues integration. Ideen er, at for samtlige komponent interfaces gælder, at disse skal have et sæt af unit tests tilknyttet, og når der committes til git, vil git automatisk afvikle samtlige tests for alle komponenter inden, en commit kan foretages.

8
4. juli 2013 kl. 09:10

det lyder som et oplæg og måske endda et open source framework :-)

6
4. juli 2013 kl. 08:14

Lyder da som en interesant ide man kun kan lære noget af! :)

5
4. juli 2013 kl. 00:13

I må meget gerne optage foredragene på video og offentliggøre dem, for eksempel på youtube. Glæder mig i særdeleshed til at se Kamp'ens Guldkorn (TM).

3
3. juli 2013 kl. 23:24

Super ide! Jeg kommer! :) Det kunne især være interessant at høre Poul-Henning fortælle om Varnish!

2
3. juli 2013 kl. 20:59

Jeg er frisk...

1
3. juli 2013 kl. 19:31

Jeg vil gerne presentere hvorledes Varnish er bygget for "preventiv debugging"