Perl-folk kan lave Quality Assurance!
Når jeg over for fagfæller uddyber hvad jeg egentlig laver på mit arbejde, fortæller jeg blandt andet om kodestandarder, kodetest og dokumentation i Perl, hvorefter de kikker underligt på mig. - Sådan noget bruger man da ikke i Perl'!'
Perl har tiltrukket mange skod-programmøre, men hvis man fejer dem tilside er meget Perlkode faktisk af en ret høj kvalitet og Perl-communityet tænker meget på kvalitetssikring. I denne weekend var en række Perl-folk samlet til QA-Hackathon i Oslo.
Der blev diskuteret og hacket på mange områder, selv deltog jeg mest i diskutionen om den protokol Perls test-framework bruger til testresultater (Test Anything Protocol) og diskutionerne om distribuere Perl-moduler med Linux-distributioner og *BSD. Men generelt er det rart at se at der er en meget kompetent og dedikeret gruppe mennesker der tager sig af at højne kvaliteten af Perl.
Min store personlige succes var at efter at have single-steppet gennem hundredevis linjer af kode jeg aldig havde set før, fandt jeg grunden til at source-udgaven af debian-pakkerne på http://debian.pkgs.cpan.org/er højst mærkelige og ikke engang indeholder et detbian-katalog.
En stor tak til Salve Nilsen for at arrangere hackathonen og Linpro for at beværte os hele weekenden.
Om Peter MakholmKommentarer (7)
Der blev arbejdet på forskellige CPAN-relaterede services. Lige af hvad jeg kan huske der blev nævnt ved fællesmøderne var en række nye kvalitetsmål for CPANTS[0] og bedre moduler til indrapportering af CPAN Testers[1]
-
0 -
0
Hej Peter,
Blev der snakket lidt om hvordan man håndter at ens moduler kun kan køre på en platform, bestemte version af perl, fx. hvis de eksportere et Linux system kald og kræver min. 5.8? Og er den nogen nyere vejledning for best practices i forbindes med hvordan man laver et godt Perl modul som andre kan teste?
-
0
-
0
Lyder godt, at der er fokus på det, da CPAN godt kunne trænge til en overhaling, så man kunne få skilt fårene fra bukkene. CPAN er en blanding af godt og skidt, desværre.
-
0
-
0
Det er "desværre" en feature at der er skidt på CPAN. Ved ikke at have nogen barriere for adgang, får man mange flere folk til at publicere deres kode, om det er godt eller skidt. Mange af de gode ting i dag er skrevet af folk der sikkert havde en mindre heldig debut, men har taget kritik til sig.
Problemet med CPAN er snarere at det er svært at finde guldkornene inden for et givent område. Det er der folk der arbejder på at løse.
Kvaliteten af CPAN er generelt meget, meget høj. Ingen open-source tiltag har samme fokus på testing: http://qa.perl.org/
-
0
-
0
Jeg tror ikke der blev snakket noget specielt om platformspecifikke moduler. Har du noget specielt i tankerne?
Der blev snakket lidt om hvordan man i META.yml og i Makefile.PL/Build.PL kunne angive at en bestemt perlversion var påkrævet. Men jeg husker ikke om man kom til nogen bestem best practice.
Best Practice omkring testing handlede vist mest om test af POD og der blev diskuteret test der var spcifikke for forfatteren af modulet og for release-processen. Jeg ved ikke helt hvad resultatet blev. Mon ikke Module::Build, MakeMaker og Module::Install i nærmest fremtid bliver opdateret med disse practices?
-
0
-
0
Som Lars Balker siger, så er det mere at betragte som en feature end en bug at "adgangskravene" til at uploade et modul til CPAN er forholdsvis lav.
For selvfølgelig klør man sig lidt i hovedbunden første gang man støder på et modul som Chooser eller forsøger at søge efter XML. Så spørgsmålet er selvfølgelig om vi kan gøre noget der gør det lettere at finde de rigtige moduler.
http://cpanratings.perl.org/ er en god hjælp til at vælge brugbare moduler. Og ratings dukker op når man søger på CPAN, så de er forholdsvis tilgængelig. Der er dog stadigvæk en række rigtig gode moduler der hverken har ratings eller reviews.
Der er kommet en 'relaterede moduler' boks på search.cpan.org. Det vil nok også hjælpe med at finde det rigtige modul, hvis kvaliteten af de moduler den finder frem er god nok. Men det må tiden vise.
-
0
-
0
