Medudvikling af Ding! sites
En af formålene ved Ding!-projektet er at åbne op for udviklingen af bibliotekswebsites, så det enkelte bibliotek har bedre mulighed for at bestemme, hvordan deres site skal se ud og fungere, hvordan udviklingen skal foregå, og hvem den skal foretages af.
Indtil videre har dette udmyndiget sig i 3 modeller:
- Biblioteker, der designer og implementerer deres site selv (fx. Randers og Aarhus)
- Biblioteker, der designer deres site i samarbejde med en leverandør, der efterfølgende står for implementationen (Helsingør og Esbjerg)
- Biblioteker, der køber sig til et færdigt design og implementation (fx. Fredericia)
De tre modeller kan samtidig betragtes som frihedsgrader, hvor de biblioteker, der har kræfterne selv (model 1), har størst mulighed for at at ændre på deres deres site.
Ewan Andreasen fra Vejle har i sidste uge holdt kurser i brug og udvikling af Ding sites. Det har bevist at selvom et bibliotek har valgt model 2 eller 3, betyder det ikke at, der ikke sidder webkyndige biblioteksansatte, som har blod på tanden i forhold til til at arbejde videre med sitet.
Vi vil jo gerne et frit bibliotekssystem, så spørgsmålet er: Hvordan kan vi bedst bedrive medudvikling af Ding-sites hvor biblioteksansatte også har mulighed for at arbejde videre med et Ding-site?
Problematikker
Som teknisk udvikler og leverandør for en række biblioteker, der har valgt model 2, skal jeg være ærlig og sige, at jeg ser en række problematikker ved medudvikling:
- Versionering af kode: Som udvikler vil jeg gerne vide hvordan koden har ændret sig over tid. Derfor benytter jeg et versionsstyringssystem (git og GitHub), hvor jeg kan se hvornår koden senest er blevet ændret af hvem og hvorfor. Hvis biblioteker skal bidrage med medudvikling kræver det altså at biblioteksansatte har styr på disse værktøjer og teknikker. Det er ikke lige til.
- Versionering af miljøer: Som udvikler vil jeg gerne vide hvilken version af koden, der ligger på hvilket miljø. Derfor kobler jeg mine opdateringer til mit versionstyringssystem. Det gør det lettere for mig at se hvilke ændringer der er blevet foretaget siden websitet fungerede sidst, og dermed identificere problemet. Hvis bibliotekspersonale begynder at modificere kode direkte på serveren via SSH eller FTP, mister jeg denne historik og fejlsøgning bliver meget sværere. Derudover risikerer vi at overskrive ændringer foretaget af biblioteksansatte, hvis disse ikke ligger i versionsstyringssystemet.
- Automatisk deployment: Som udvikler vil jeg gerne have at opdatering af et miljø er så automatiseret en process som muligt. Det kan være en kompliceret proces, og hvis der skulle gå noget galt, vil jeg gerne have elimineret så mange manuelle processer og dermed fejlkilder som muligt. Hvis biblioteksansatte kunne opdatere et eksisterende miljø kræver det altså også viden om disse systemer.
- Fejlsøgning: Som teknisk leverandør står jeg på mål for den løsning vi har leveret. Hvis der skulle opstå problemer, vil vi gerne kunne gå ind og hjælpe med at løse dem så hurtigt og mest effektivt muligt.
Løsningsmodeller
I forhold til pkt. 1-3 ser jeg to komplimenterende løsningsmodeller:
- CSS modul: Som jeg forstår det er en række af de ændringer, det enkelte bibliotek har lyst til at indføre reelt set ændringer til style sheets, hvor man bl.a. styrer font, farver og baggrundsbilleder. Derfor kunne man i Ding! implementere et CSS editor-modul, hvor biblioteksansatte i administrationen kunne arbejde med en separat CSS fil til sitet. Der vil som udgangspunkt ikke være mulighed for versionering, men kildekoden vil være adskilt fra Ding-koden og biblioteksansatte vil slippe for at skulle lære git og deployment. Modulet kunne muligvis baseres på det eksisterende Live CSS-modul.
- Medudvikling: Hvis biblioteksansatte vil kaste sig ud i mere end stylesheet ændringer, så må de deltage på linie med udviklerne fra den tekniske leverandør. Det vil altså kræve at de kan sætte et lokalt udviklingsmiljø op og sætter sig ind i git, deployment etc. Jeg tror det for mange vil være en stor udfordring, men jeg ser ingen mellemvej her.
Ift. pkt. 4 skal bibliotekerne være klar over at medudvikling ligemeget hvad stiller højere krav i forhold til samarbejdet med leverandøren. Leverandøren vil sandsynligvis også skulle bistå med hjælp til at få udviklingen til at glide og fejlsøgning bliver mere kompliceret idet problemer nu både kan skyldes de bagvedliggende webservices, Ding-kernen, kode udviklet af leverandøren og kode udviklet at biblioteksansatte.
Jeg vil meget gerne høre med om hvilke behov, udfordringer og løsningsmodeller I ser, hvad enten I er biblioteksansatte eller leverandører?
Recent members
 |
Havelund | |
 |
Emilia | |
 |
jyd | |
 |
sgl | |
|
|
Michael Trøstrup | |
|
|
RunePhilosof | |
|
|
StineWeymann | |
|
|
jesperjb | |
|
|
Gitte Barlach | admin |
 |
zorp |
- 1 of 9
- ››
Group admins
|
|
Gitte Barlach | admin |
Kommentarer
Jeg er enig i dine fire
Jeg er enig i dine fire pointer under 'Problematikker', men jeg kan ikke finde ud af, om jeg er enig i den bagvedliggende præmis.
Du forudsætter, at alle ændringer i kildekode foretages via versionsstyring og deployes på samme vis som hidtil. Så langt tror jeg, at vi er enige.
Men det virker til, at du også har som præmis, at bibliotekernes ansatte ikke kan komme til at bruge git til versionsstyring.
Min oplevelse er, at det er relativt ukompliceret at komme ind i git på det niveau, som er nødvendigt for at kunne foretage ændringer og gøre dem tilgængelige for deployment.
Point being: Hvis man ikke kan lære at bruge simple pull, add, commit og push via git, så er man formodentlig heller ikke i stand til kvalificeret at opdatere themet.
Medudvikling behøver vel ikke betyde, at man ikke må stille krav til medarbejdernes kompetencer?
Kunne man ikke forestille sig en model, hvor bibliotekernes medarbejdere kan foretage de ønskede ændringer, committe dem til en branch eller separat repository og fremsende en merge request til den person eller part, som alligevel er står for at deploye nye versioner på bibliotekets website?
Krav til biblioteksansatte
Min præmis er, at git er kompliceret - versionsstyring er kompliceret, git som versionstyringssystem er kompliceret og opsætning af git er kompliceret (især på Windows, som jeg tænker en del biblioteksansatte arbejder på til daglig).
Som jeg ser det, kræver det mere end bare git-færdigheder at være medudvikler med den nuværende udviklingsmodel for Ding. Man skal fx. også selv kunne sætte et udviklingsmiljø op lokalt eller på en separat server, så man har et sted at lave ændringerne, inden de er klar til at blive committed. Der skal altså sættes en L/M/WAMP server op, lave et lokalt build etc. Hvis man skal have kontakt til biblioteksystemet (Alma eller OpenRuth) skal der måske opsættes tunnels.
Min præmis er også, at biblioteksansatte ikke har speciale i IT-udvikling. Når vi skal sætte nye udviklere eller leverandører ind i Ding tager det tid. Det forventer jeg også det vil tage hvis biblioteksansatte skal være med i udviklingen.
Medudvikling betyder ikke at man ikke må stille krav til medarbejdernes kompetencer - derfor er medudvikling også med som løsningsmodel - men jeg mener ikke at det er noget man som bibliotek bare lige gør. Hvordan det så herefter skal gribes an ift. repositories, branches, pull requests etc. vil jeg gerne diskutere, hvis det viser sig at være en model som flere gerne vil benytte.
Forklar hvad problemet er tak ?
Det er klart der kan være problemmer med at pille ved kode.
Men der må da være ting vi kan pille ved som ikke er "Farlige"
Kasper hvis jeg nu installere dette "scheduler" modul
http://drupalmodules.com/module/scheduler
hvad er problemmet så set fra jeres side ?
For det er vel ikke alle moduler eller ting :-) vi ikke må pille i. ?
Versionering og styr på miljøer
Problemerne er dem jeg har har prøvet at opsummere i pkt. 2, 3 og 4.
Generelt har Drupals moduler indflydelse på hinanden. Selv om nogle moduler kan fremstå uskyldige, så kan det resultere i problemer, der kan være svære at identificere. Det gælder især, hvis man ikke har et fuldkomment overblik over, hvad der er installeret, og hvordan det er konfigureret.
Samtidig mener jeg ikke, det er alle biblioteksansatte, der har kompetencerne til at vurdere, hvorvidt et modul er "farligt" eller ej. Derfor har jeg opstillet høje krav til de udviklingsmæssige kompetencer, biblioteksansatte skal have for at deltage i reel medudvikling (løsningsmodel 2) med mulighed for selv at installere og konfigurere moduler - eller med andre ord "pille" udenfor Drupals administrationsgrænseflade.
Hvis ikke bibliotek ikke har kompetencerne til at bedrive medudvikling, mener jeg at de bør bede deres leverandør om at få moduler installeret i overensstemmelse med den nuværende udviklingsproces eller samle støtte på ting.dk for at få modulet til at blive en del af hovedsporet. Scheduler kunne være et oplagt forslag.
I forhold til eksemplet: Hvis I installerer scheduler modulet selv på alle jeres miljøer, dev, staging og prod, og vi efterfølgende opdaterer dev med et igangværende projekt - fx. lokalbibliografiske poster, og det viser sig at ændringerne i de lokalbibliografiske poster ikke virker, når de kommer ud på dev, så skal vi finde ud af om problemet er i vores egen kode, i en af de moduler, som I har installeret, eller konfigurationen af disse.
Det bliver kompliceret. Det er svært at få overblik over dels hvilke moduler, der er blevet installeret direkte på miljøet (en Ding installation består af over 300 moduler per default) og dels hvordan de er blevet konfigureret.
For at køre eksemplet videre, så lad os sige, at I i mellemtiden gør jer nogle erfaring med scheduler og derfor ændrer på konfigurationen af det på produktionsmiljøet, men I har glemt at opdatere staging og dev tilsvarende (tro mig - det er sket for os alle, når miljøer bliver konfigureret manuelt). Ved en senere opdatering til staging opfører tingene sig pludselig ikke længere, som I er vandt til. Problemet gentager sig: Er det i den opdaterede kode, i en af de moduler, som I har installeret, eller konfigurationen af disse der er årsagen? Endnu værre ville det være hvis situationen var omvendt og opdateringen virkede for forvemtet på staging med ikkke i produktion, fordi der var forskel på hvordan de to miljøer var konfigureret.
Jeg mener ikke at vores nuværende metoder udelukker, at problemer kan opstå i produktionsmiljøer, selv om de virkede på staging. Drupal kan virke simpelt - man kan jo bare skifte mellem temaer og slå moduler til og fra via administrationen - Ding er et komplekst system med mange niveauer, hvor problemer kan opstå.
Min pointe er at de værktøjer og metoder, vi normalt benytter i Ding-regi til at reducere denne kompleksitet, bliver sat ud af spil.
Jeg er en af de "halvkyndig webkyndige biblioteksansatte"
Et godt kursus som har rejst en række problemstillinger hos os og leverandørerne
Jeg deltog med stor fornøjelse i Ewans kurser i sidste uge, og kan til en hver tid anbefale andre at deltage hvis de kommer igen. Endelig et sted hvor der blev øst ud af vigtige informationer omkring opbygning, redigering m.m. Alt sammen ting som mange kan have glæde af.
Ewan's kusus indeholdt især en af de ting som jeg har savnet helt enormt siden vi som bibliotek først var med i Easysite og nu i ding.ting, nemlig adgang til mit css.
Nu er det så at at der er mange der får sved på panden når jeg begynder at snakke om at få shh adgang til mit biblioteks server på dbc. Der er nemlig ikke ftp adgang til serveren. Tanken om at jeg får adgang til css m.m er noget der vækker bekymring især hos min leverandør Reload. Citat "Dine idéer er gode men hvis jeg skal være ærlig så mener jeg som teknisk udvikler og leverandør ikke fremgangsmåderne er sund praksis."
Reload og undertegnet har i den anledning mailet en del og blevet enige om at diskussionen skulle være her så alle kan kommentere.
Jeg kan godt forstå Reloads bekymring. Jeg er selv bekymret. Men tilsvarende er det også meget frustrerende ikke at have nogen ”frihed” og hele tiden være afhængig af at skulle kontakte en leverandør for noget så simpelt som fx et mellemrum i en liste. Jeg er derfor blevet opfordret til at komme med de ønsker jeg har til en løsningsmodel til fremtidens ding.ting. Jeg vil opfordre jer andre til at komme med jeres ønsker.
Jeg anser selv denne diskussion som være meget vigtigt, og er glad for at Kapser og Reload har sat den i gang.
"Hvordan kan vi bedst bedrive medudvikling af Ding-sites hvor biblioteksansatte også har mulighed for at arbejde videre med et Ding-site?"
Først mine ønsker
Det jeg som "halvkyndig" biblioteksansat har brug for er at kunne lave effektivt genbrug af views m.m. At når nogen har fået en god idé til en "forsidekarrusel" at jeg kan få fat i den let og uden de store besværligheder.
Et eksempel kunne fx. være få en feature som personaleliste fx Vejle har udviklet. Det vil være en kæmpe hjælp. Det giver mening at jeg kan genbruge deres arbejde i stedet for at jeg sidder og udvikler et view. Min idé er jeg lige så godt få deres feature og tilpasse det til mit behov. Det er da ikke værre end jeg selv sidder og roder med at få det til at virke lokalt. Mig bekendt ødelægger det ikke kode mv. Det er bare en måde ikke at skulle opfinde den dybe tallerken.
Mit forslag er at man på en nem måde kunne få fat i hinandens features uden at skulle git osv.
Et andet ønske kunne være at man rimligt nemt kunne få et andet biblioteks theme fx. Helsingør eller Vejles og tilrette det selv på udviklingsservernen. Når det så er "klar" at ens leverandør tjekker det efter og gør det online i produktionsmiljøet alt efter ens niveau. I mit tilfælde vil det helt klart være en noget jeg ville gøre netop for ikke ødelægge noget.
Kommentarer til Kaspers forslag
Jeg syntes det lyder meget fornuftigt mht. Kaspers forslag. Det vil jeg godt kunne tilslutte mig.
Mht. kommentaren omkring medudvikling, så ved jeg ikke rigtigt hvad jeg skal sige til det. Jeg er ikke ude på at ødelægge kode, ding.ting elle noget. Jeg vil bare gerne have frihed til i ro og mag at "pille" ved mit design og tilpasse det til mine behov.
Jeg havde en naiv tro på at det var det ding.ting kunne da jeg gik ind i samarbejdet. Jeg har siden fundet ud af at ding.ting er meget kompleks og langt fra "de gamle dage med frontpage/ dreamweaver/ css og fpt adgang direkte til ens server. "
Jeg savner meget at kunne lave en lille finjustering, og hurtigt se om det var en god eller dårlig idé. Sådan er virkeligheden bare ikke og det forstår jeg også godt. Ding.ting opleves af mig som lidt firkantet og ikke særlig gennemskuelig. Men nøj hvor vil jeg gerne have adgang til at kunne gøre noget ved mit design. Jeg behøver ikke adgang til min server hvis bare jeg kan få noget frihed til at være kreativ og teste de idéer jeg måtte få fx i en editor.
Så et Css modul står højt på min ønskeliste.
Det handler om maintainability
Hej Mette
Rigtigt godt indlæg, du belyser problematikken fint.
I kan jo sagtens rode rundt i en ding.TING installation hvis i vil det, installere moduler, rode med stylesheets og lave nye views.
Problemet opstår først når vi skal opgradere jer til en ny version. Det handler altså i høj grad om "maintainability".
Fordi så kan vi ikke gøre andet end at overskrive systemet, og siden jeres theme også er i Git (således flere udviklere kan arbejde på det), så vil jeres ændringer også blive overskredet så længe i arbejde i de samme filer.
Der er muligvis forskellige tekniske workarounds, men jeg er ikke sikker på at nogen af dem er specielt nemme.
Så vores behov for at gøre koden nem at vedligeholde og opgradere konflikter med jeres behov og ønske for nemt at kunne ændre i ting.
mvh
Rasmus
Maintainability
En rigtig god diskussion du har startet her Kasper. Jeg synes også at den er en del af en større diskussion nemlig hvordan viderudvikler man sit enkelte site og giver det særpræg samtidigt med at vi udvikler i fællesskab. Som Rasmus siger så opstår problemet netop når man vil opgradere sit site til en ny version.
Jeg har problematikken klart ind på livet i øjeblikket som en som har lavet en del ændringer i forhold til hovedsporet. Det som kommet bag på mig er hvor dyr en lille ændring i koden er. F.eks vi lavade forfatternavnet i søgeresultatet om til et link som man kan lave en direkte søgning. En simpel opgave som tog højest en halv time at udvikle. Problemet er at hver gang der kommer en ny version af ding så bliver denne kodelinje flaget som forskellig fra den nye version af koden og jeg skal manuelt ind og tjekke om kodelinjen stadigvæk skal være der og om den virker som den skal. En anden lille ændring - vi viser kun tre arrangementer på vores forside, men nu er vores view konfiguration anderledes end hovedsporets og kodefilen bliver flagget som forskellig når der kommer en ny version.
Den umiddelbare strategiske konsekvens man kunne drage af det her er lægge sig klods op ad hovedsporet og kun vige meget lidt fra det. Det ville være den mest effektive måde at køre siden på. Når der kommer en ny version så ville man bare tage og køre den direkte på serven. Problemet er at så ville vi få en side som var en kopi af Københavns og ikke ville passe til os. Men det er ikke nogen tilfredstillende løsning. Det vi først og fremmest mister er lysten til at eksperimentere. Hvad nu hvis forsidekarusellen var dobbelt så stor osv. Det er netop den slag eksperimenteren som giver os mange gode og innovative bud på hvordan vores Ding hjemmesider skal udvikle sig.
Spørgsmålet er om der ikke er muligt at lave noget så at vi kan nyde godt af den fælles udvikling men samtidigt give gode rammer for at enkelte site har sit særpræg. Det kunne være at lave en arkitektur som i højere grad gav plads til variation.
Håndtering af overrides
Det bør være muligt at håndtere en række af disse ændringer uden konflikter vha. overrides.
Jeg tænker at links fra forfatternavnet kan håndteres vha. at override de eksisterende templates i jeres tema - fx. ting_object.tpl.php. I bliver dog nødvendigvis stadig nødt til at holde øje med ændringer i originaltemplaten, når der kommer nye versioner.
Ændringer i views skulle kunne klares ved at implementere hook_default_views_alter(). Ændringerne hober sig dog nogle gange op og så kan det bliver uoverskueligt. I disse situationer laver vi nye views og en ny variant for den eksisterende side, sørger for at den får en lavere vægt og dermed bliver prioriteret højere og placere eksisterende og nye panes her.
Det seneste eksempel på denne fremgangsmåde er på København, hvor de har erstattes bogkarussellen med Helsingørs og Vejles nyheder og opdateret arrangementslisten med mere information. Det er ikke live endnu, men koden er her.
Håndtering af overrides
Tak for tipset Kasper.
Deling af moduler og tilretning af views og temaer
Du rejser forskellige problematikker, Mette.
Overordnet set er mit svar reelt set det samme, som jeg har givet til Søren ovenfor: Hvis biblioteksansatte skal have mulighed for at installere og konfigurere moduler selv, så omgår de de værktøjer, vi benytter til at håndtere kompleksiteten i Ding: Fortegnelser over installerede moduler og konfiguration samt versionsstyring. Dette er helt standard metoder for professionel IT-udvikling.
Ding er meget langt fra de gamle dage med Frontpage/Dreamweaver og FTP adgang direkte til ens server.
Ift. de enkelte behov/eksempler du nævner:
Deling af moduler
Vi har i Core teamet anvist, hvad vi mener er sund praksis for deling af moduler i Ding. Hvis Ewans personalelistemodule er udviklet efter denne fremgangsmetode, bør det være så let som det er muligt og forsvarligt at genbruge hans arbejde på tværs af flere Ding sites. Samtidig kan Ewan også lettere opdatere modulet med rettelser og nye funktionaliteter som så kan til- og fravælges af andre.
Det indebærer selvfølgelig, at modulet bliver rullet ud på den rigtige måde ved hjælp af git og deployments, men det er min faste overbevisning at dette er nødvendigt for at kunne vedligeholde et Ding site.
Det eneste alternativ, jeg kan se, er at man lavede en Ding AppStore (af mangel på bedre navn), hvorfra man kunne dele og downloade prekonfigurerede moduler, der ikke er en del af Core. Det forestiller jeg mig ligger et godt stykke ud i fremtiden.
Tilretning af views og temaer
Opsætningen af et view er reelt set en masse konfiguration, så her gælder samme kommentarer som ovenfor.
Du har jo selv prøvet at arbejde med Views, så selv om du har oplevet hvor let, det er at klikke sig rundt til en ændring, håber jeg også, du kan se, hvor kompliceret det kan bive at holde konfigurationen synkroniseret på en række miljøer, hvis man ikke strukturerer sine ændringer.
Hvis du selv vil ind og tilrette eksisterende kode hvad enten det er temaer e.l. tror jeg din tid er bedst brugt på at du får et nyt miljø sat op enten lokalt eller på jeres server hos DBC og tager dig tid til at sætte dig ind i de værktøjer, vi bruger til Ding udvikling.
Som Jesper har pointeret ovenfor, så hvis du har mod på at opdatere et tema (altså ud over CSS), så kan du sandsynligvis også lære basal versionsstyring og git.
Jeg ved godt, at du og andre initiativrige biblioteksansatte ikke er ude på at ødelægge noget, men hvis I benytter andre værktøjer end dem, der bliver benyttet af udviklerne, gør det det sværere for udviklerne at arbejde videre med sitet, hvad end det er i forbindelse med fejlsøgning, vedligeholdelse eller videreudvikling.
CSS modul
Jeg er glad for, at mit forslag rammer nogle af jeres ønsker. Hvis det skal blive til noget er det et spørgsmål om, at du skal udviklere og andre biblioteker, der kan gå sammen om projektet.
I forhold til fremtidens Ding, så tror jeg Ding2 teamet holder øje med diskussionen herinde. Jeg forventer dog ikke, at der bliver de store ændringer ift. hvordan moduler og temaer tilføjes og konfigureres.
Spørgsmål
Først til Kasper - genial bemærkning omkring app store - den dag ser jeg frem til :-) Det ville da være en herlig "ting" som ville fremme kreativitet på alle sites.
Denne diskussion har lært mig en del om ding som jeg tror mange kan have brug for at vide inden de går ind i ding.
Jeg har en række spørgsmål, for nu vil jeg gerne finde ud af hvad jeg må i et system som syner fleksibelt og så alligevel er det modsatte når det kommer til stykket.
Pt. sidder jeg og føler mig lidt handlingslammet. Der er en masse ting jeg gerne vil, men som jeg frarådes. Så hvordan kan jeg let enkelt og billigt få fat i simple ting?
Alternativet er som nu hvor jeg betaler mig fra udvikling - og ja det har jeg god erfaring med. Samtidigt med at jeg knokler for at få mine views til at se "flotte" ud. Det er egentligt lidt frustrerende ikke at kunne få del i den dybe tallerken,
Mht. Randers som har lavet en genial lille rettelse i koden som gør at man kan søge på forfatteren. Hvorfor i alverden er det ikke en del af core? Det var da noget alle kunnne få glæde af. Det er noget kunderne bander over tit når man viser dem systemet.
Kunne det ikke være en god ting at bibliotekerne kunne "stemme" om ting som kunne komme med i core? Når der så var en form for "flertal" så betalte vi som samlet enhed for at kunne få det hurtigt på.
Hvis jeg har forstået det rigtigt samler man pt. rettelser og samler dem til næste opgradering. Det er også fornuftigt. Men når noget bliver udviklet "uden for sæson" så går der bare for lang tid inden det kan spredes.
Udvidelser, fleksibilitet og deltagelse
Den fleksibilitet, der er i Ding, i forhold til strukturen på et site, er rettet imod udviklere - ikke biblioteksansatte. De to gruppers behov er ikke nødvendigvis sammenfaldende.
Ding er et produkt bygget på Drupal til at løse en specifik opgave. Drupal er fleksibelt og hvis jeg skal lave et nyt site til et bibliotek med mulighed for login, søgning etc. så kan jeg downloade modulpakkerne fra GitHub og bygge sitet op fra grunden af. På den måde kan jeg selv bestemme hvor login- og søgebokse skal være, definere indholdstyper og designe mit eget tema fra scratch. I så fald må jeg så også selv håndtere opdatering af de enkeltestående moduler, flette nye funktionaliter ind i mit site efterhånden som de kommer til og de andre fordele, der er ved at følge et fælles spor.
Det forstår jeg godt. Jeg vil gerne understrege at det ikke er et spørgsmål, om at du ikke må. Grunden til at vi fråråder de ændringer, du gerne vil, er fordi den måde, du udfører dem, bryder med de værktøjer, vi som udviklere benytter. Som skrevet før: "Dine idéer er gode men hvis jeg skal være ærlig så mener jeg som teknisk udvikler og leverandør ikke fremgangsmåderne er sund praksis."
Ding er et system udarbejdet af udviklere og fleksibiliteten i sitets struktur er primært rettet imod dem. Derfor er der nogle kompetencer man skal have for at medudvikle og følge praksis for projektet.
Vi vil ikke stoppe dig i dine ændringer, men vi vil gerne fortælle dig hvilke konsekvenser det har, og hvorfor vi ikke mener det er hensigtsmæssigt.
Fordi der ikke er nogen der har rejst og prioriteret behovet og fori Randers ikke selv har submittet ændringen som pull request.
Det er netop noget af pointen med ting.dk. Hvis der er noget du ønsker, så kunne første skridt være at starte en diskussion her og se, om der er andre, der melder tilbage. Det kunne fx. ske med et CSS editor modul.
Manglende fleksibilitet eller blot krav om faglighed
Jeg oplever, at der sker en uhensigtsmæssig sammenblanding af krav til kompetence og så 'fleksibilitet'.
Du skriver:
Drupal stiller krav til kompetencerne hos udviklere og themere. Det er der forhåbentlig ikke nogen, som har været i tvivl om.
Systemet er komplekst og qua sin fleksibilitet og evne til at udfylde en lang række opgaver fra brochure-site (fx vigirbyenpuls.dk) til webapplikation (fx Podio) stiller det krav til de, der udvikler på det.
Samtidig har TING-partnerskabet valgt at udvikle en ret avanceret og igen kompleks webløsning til bibliotekerne, og har haft som målsætning at udvikle og drifte ting-websites efter professionelle standarder.
Det stiller krav til os, der udvikler på systemet, men det giver samtidig en lang, lang række fordele, vi ikke havde før.
Det er dog noget helt andet end at platformen er ufleksibel. Med Drupal og ding.TING har kunderne (os) ubetingende rettigheder til koden og til at udvikle og modificere den kode i præcis den retning vi ønsker som enten partnerskab eller individuelt.
Samtidig er ding.TING baseret på en af de mest fleksible og brede content-management-platforme på markedet i dag.
ding.TING kan jo netop levere alle de ønsker som er præsenteret både herover og herunder. Men det stiller krav til de faglige kompetencer hos de folk, der udfører opgaven.
Det er jo ikke spor anderledes, end når det stiller krav til de faglige kompetencer, at arbejde som bibliotekar på et professionelt niveau.
Hvis bibliotekerne ønsker at bedrive design og webudvikling, så er den naturlige konsekvens, at vi ansætter webdesignere og -udviklere til at løse opgaven - på fuldstændig samme vis, som vi ansætter bibliotekarer til at løse biblioteksfaglige opgaver og håndværkere til at renovere bygningerne.
Kurserne har startet en
Kurserne har startet en debat, som jeg synes er rigtig god at have. Inden jeg giver mit besyv med, vil jeg lige opsummere nogle pointer jeg gerne ville nå frem til under kurserne (se slides på slideshare):
Pointe A: With power comes responsibility
Justerer man ding, følger der et ansvar med, som man bør tage på sig. Det inkluderer f.eks. at hvis man kører med sit eget tema, så er man nødt til at se det efter når der kommer en opgradering. Som Kasper skriver: ".. I bliver dog nødvendigvis stadig nødt til at holde øje med ændringer i originaltemplaten, når der kommer nye versioner..". Et andet eksempel er at man selv tester drupal-moduler der ligger udenfor dings hovedspor - og bør være klar til at fjerne dem igen, hvis de ikke virker hensigtssmæssigt sammen med ding.
Pointe B: Man kan deltage i medudvikling på flere niveauer
Medudvikling af ding er ikke et spørgsmål om enten-eller. Jeg har prøvet at demonstrere, hvor meget man kan med CSS - og at dette i mange tilfælde er nok. Jeg har tidligere (på TING workshop i Vejle) foreslået en trappe med stigende sværhedsgrad indeholdende flg. niveauer:
Måske kan ovenstående bidrage til at afklare, hvor ens eget bibliotek ligger. De med "*"-markerede punkter er de niveauer, hvor brug af Git nok bør være et krav, hvis man vil bidrage til fællesskabet omkring ding.
Pointe C: Override - ret IKKE direkte
Kasper har opsummeret hvad det betyder, når der rulles opgraderinger ud. Man vil miste de ændringer, man har lavet til f.eks. eksisterende views. Derfor har jeg demonstreret, hvordan man kopierer de eksisterende views og dernæst peger på dem istedet for originalerne. Den praksis kræver så stadig at man tænke på pointe A ovenfor - og leder iøvrigt direkte til
Pointe D: Indstillinger/ændringer placeres i kode
Brug Features! Lokalt kan man selv gemme sine views og panels, og hurtigt gendanne dem hvis det har været nødvendigt at opdatere eller genoprette hjemmesiden. Bruges drupal moduler udover ding, er det også muligt at gemme indstillingerne for det modul i en feature (som f.eks. Scheduler, hvor Vejle gemmer en feature kaldet vejlebib_scheduler).
Efter kurserne kunne se konstatere, at jeg havde delt deltagerne i 2 lejre: Nogle er nu afklarede med, at man har en leverandør der håndterer tilretninger af ding-hjemmesiden - mens andre stadig ønsker at udvikle med. Forhåbentligt har jeg bidraget til at formidle god praksis, som også giver glade leverandører til disse medudviklende biblioteker.
Løsninger?
Tillid, aftaler og arbejdsdisciplin
Jeg mener at der i det enkelte tilfælde kan skabes den nødvendige tillid mellem leverandører/biblioteksansatte. Tilliden findes gennem gode aftaler om, hvordan man arbejder med justeringer af tema og kode. Kaspers bemærkninger vedr. at der må stilles krav til kompetencerne er et udtryk for, at en vis arbejdsdisciplin er nødvendig. Git og Github ser jeg som grundstenen i denne arbejdsdisciplin. Det er her min erfaring, at Git på Windows ikke er noget større problem at sætte op. Hvis det er svært i det enkelte tilfælde, så synes jeg at et tillidsskabende møde mellem leverandør og bibliotek bør inkludere at leverandør leder biblioteket igennem en opsætning af en Github konto, Git og SmartGit. I daglig brug er Git IKKE et krævende flow. Derimod oplever jeg at opsætning af et ding-website er vanskeligt på Windows, og jeg vil foreslår at en del af aftale ml. bibliotek og leverandør er FTP-adgang til et DEV-miljø.
I hovedsporet eller ej?
Kasper skriver: "de bør bede deres leverandør om at få moduler installeret i overensstemmelse med den nuværende udviklingsproces eller samle støtte på ting.dk for at få modulet til at blive en del af hovedsporet". Det er ikke altid den rigtige løsning på medudvikling-problematikken. At bruge den som kriterie for, om et modul skal med i hovedspor, er ikke helt korrekt. Core.Team vil heller ikke have ressourcer til at indlemme, teste og udrulle alle de moduler, bibliotekerne kunne tænke sig. Kriteriet for, om et modul skal med, bør udelukkende være hvorvidt modulet bidrager med noget som alle bibliotekswebsites har gavn af. Dermed vil der være moduler, som aldrig skal med, men som er nyttige for et mindretal. Hvad gør man så? Jo, her skal bibliotekerne selv på banen - vi skal tage ansvar for at teste de ekstra moduler, vi ønsker, og gøre det, der skal til. Det inkluderer at holde øje med modulerne, når ding opgraderes. Og laver vi selv moduler som biblioteksansatte, har vi også ansvaret for sådanne moduler. I Vejle står vi på mål med udviklingen af ding_place2book modulet.
Hvad mangler de biblioteksansatte for at kunne medudvikle?
Kurser. Vejle har bidraget, og vil vil holde kurser igen - muligvis foråret 2012. I mellemtiden vil I (snart) kunne se videoer fra kurserne i september.
Procedure-beskrivelser, så vi får indarbejdet en god arbejdspraksis, der ikke gør livet vanskeligt for leverandørerne. En god start til en procedurebeskrivelse af en arbejdsgang er indlægget strukturelle ændringer i ding-hovedsporet - her er det underforstået, at man bruger Git. Derudover kunne vi lige skrive ned, hvordan proceduren er hvis man vil 1) lave eget tema, 2) tilrette et view og 3) tilrette et panel. Det vil jeg gerne være med til at formulere - i Vejle bruges Git, og vores leverandør Bellcom har kunnet genskabe vores site med de Feature-moduler, vi har lavet, hvilket må betyde at vi er på rette vej med vores procedure.
Praktiske værktøjer: Live CSS!-modulet er ikke en dårlig idé - og kunne kombineres med, at standard-temaet kommer out-of-the-box med et subtema, der ikke indeholder noget, men er en pladsholder hvor den biblioteksansatte kan smide sit eget CSS og skabelon-filer.
"Medudvikling af ding er ikke
For at udgå begrebsforvirring vil jeg gerne afgrænse medudvikling til at være indeholde punkter 6-9 på din liste.
Dermed ikke sagt at de andre måder at bidrage er mindre værdigfulde, men snakken om medudvikling handler om kompetencer. Hvis ikke det bliver understreget, at det er en teknisk øvelse, så løber diskussionen af sporet.
Fint. Jeg er også blevet gjort opmærksom på at sitet http://buildamodule.com/ snart vil have video tutorials om versionsstyring og udvikling med features. Jeg kender ikke til kvaliteten, men det kunne måske være et udemærket supplement til dine kurser, Ewan.
Jeg tror, vi er enige. Et af kriterierne for om et modul skal med i hovedsporet er om modulet bidrager med noget som størstedelen (ikke nødendigvis alle) af bibliotekswebsites har gavn af. Derudover kommer hensyn så som kodekvalitet, sikkerhed etc.
Videotutorials om versionsstyring, git og features
Videoerne kan findes her.
Drupal training
Hvis I ikke skulle være klar over det, synes jeg lige jeg vil gøre opmærksom på denne fantastiske mulighed som Chris Chattuck giver adgang til for grupper til at få adgang gratis til videoerne i 8 dage m.m. Alt er forklaret her http://buildamodule.com/train.
Nederst på siden under Appendix http://buildamodule.com/ er et par videoer om disse trainings.
Medudvikling
Hej Alle
Det virker som om man lidt har glemt i diskussionen at alle sites får opdateringer løbende. Hvis man så benytter sig af muligheden af at lave lokale rettelser, så er det en selvfølge, som ved alt anden udvikling at det kan blive overskrevet, hvis man ikke har beskrevet hvordan man kan lave lokale rettelser uden fare for overskrivning.
Det betyder at man som Ewan har gjort, skal identificere hvad det er for noget man gerne vil kunne rette i og hvordan bedste praksis er. Angående bedste praksis foreslår Kasper nødvendige udviklingsværktøjer, men også forskellige moduler der kunne hjælpe til. Der er dog mange andre måder man kunne lave lokal udvikling, hvor sværhedsgraden ikke var så stor, hvor man får glæden af de mange gode opdateringer fra core, men det gælder bare om at identificere dem og overveje hvordan man laver "paralleludvikling" samt hvad skal ind i core.
Jeg tror bare man skal huske at opdateringer er et gode og det er fedt man faktisk kan påvirke processen, så man så nemt som muligt kan lave medudvikling.