Visualising three years of development

About two and a half years ago I made a visualisation of the work on SYND so far. Much has happened since then, and with the three-year-anniversary of the first commits to the SYND repos rapidly approaching, I felt it was time to revisit gource and do another loop through the commit history. Presenting the three-year-mark of YDD development:

Much have changed since the previous visualisation, the biggest of the changes of course the creation of the two sub-branches of the project, SYND and FYND. It’s easy to see how much the project has expanded in scope and complexity since we started, something that would have happened even without the forking of the project.

Vad är en patch? Steg för steg guide hur du själv gör en till Drupal

En patch kan jämföras med ett plåster med en unik passform för ett unikt skrubbsår. Patchen bygger man för att fixa något som man tycker är fel i en modul (core eller contrib) som man använder. Då man listat ut hur man kan fixa den kan man först applicera den på sin egen sajt, och sedan dela den med communityn så att alla kan få nytta av den. Passar väl rätt bra ihop med public service eller hur?

Min första patch skapade jag förra veckan. Vi använder Redirect modulen för att hantera namnbyten på artiklar. Om en artikel byter namn på vår sajt ändras nämligen också adressen till artikeln, och om artikeln då redan hunnit delas i social medier så skulle besökare den vägen inte hitta artikeln utan redirect modulen.

Problemet uppstår ifall artikeln först döps till ”Kalle Anka är bäst!”, sedan döps om till ”Kalle Anka bäst!”. Då skapas en hänvisning från ”Kalle Anka är bäst!” till ”Kalle Anka bäst!”. Om man sedan döper om artikeln till ”Kalle Anka är bäst!” döps artikeln om, och det finns redan en hänvisning som pekar på ”Kalle Anka är bäst!”. En infinite loop har skapats, då besökaren skickas runt i en cirkel utan att någonsin kunna stanna (Sajten märker dock av felet och bryter loopen, men besökaren kan inte läsa artikeln).

Det felmeddelande som visades var inte särskilt tydligt för en icke tekniskt kunnig. Där stod ”Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!”.

Jag tänkte jag skulle översätta det till något tydligare, samt inkludera ett lösningsförslag åt den som skapade felet. Jag kunde dock inte göra det, för översättningsfunktionen kunde inte hitta meningen i fråga. Jag bestämde mig för att kolla på modulens kod, och kunde där konstatera att t() översättningsfunktionen saknades. Dessutom visades felet som ett grönt statusmeddelande. Jag ville ändra det till ett gult eller rött varningsmeddelande.

Genom en sökning på ”create Drupal patch” hittade jag en manual för att skapa en patch (Quick and simple patch). Man klarar sig med det som står på modulens ”versioner” sida, gör en patch för redirect. Följande Youtube video guidar dig genom git och drupal.org issue skapandet.

I korthet gjorde jag följande:

  1. Ändrade på min local dev version av redirect modulen för att kolla om jag överhuvudtaget kunde fixa problemet
  2. Installerade en ren version av Drupal 7.x (min local dev är så modifierad att det är bäst att testa och skapa patchen från en så ren install som möjligt
  3. Installerade git_deploy som behövs för att generera all info som behövs till patchen
  4. Installerade dev versionen av redirect (git clone av dev branch) och pathauto som behövdes för att testa den ändrade koden
  5. Gjorde ändringarna i filen
  6. Gå till modulens mapp med CMD, kör git status. Du ser då ett meddelande om att filen du ändrat har ändrats.
  7. Kör git diff > [description]-[issue-number]-[comment-number].patch (du kan testa att döpa den till vad som helst, för att se att det fungerar. Filen finns sedan i modulens mapp) Fortsätt sedan med följande steg och döp sedan om testfilen du skapade eller kör kommandot en gång till.
  8. Gick till drupal.org och redirect modulen och skapade en ny issue. Där beskrev jag problemet och hur jag tänkt lösa det. Ta issue nummern från url:en efter att du sparat din issue, och döp patchen enligt namngivningskonventionen. I mitt fall blev det missing_t_function-1903228-1.patch
  9. Skriv en kommentar och bifoga patchen, ändra status till needs review
  10. Vänta på att någon av upprätthållarna kollar på din patch och bifogar den först till dev branchen och sedan till den stabila versionen
  11. Om du inte kan vänta kan du också ta patchen i bruk bara på din egen sajt i väntan på att den blir tillgänglig via modulen
  12. Patchen denna bloggpost handlar om blev infogad i dev branchen efter en vecka

Här kan du läsa issuen jag skapade för patchen:
#1903228 – Missing t() function in drupal_set_message

Versionshantering till nytta och nöje

Inget utvecklingsprojekt borde vara utan ett system för versionskontroll, inte ens om man är den enda som jobbar på sitt projekt. Och när man är många som jobbar med samma projekt så är det idag nästan omöjligt att göra det på ett vettigt sätt utan att stöda sig på någon form versionering.

Vad får man då för besväret av att vara tvungen att börja bokföra vad och hur man lägger in kod i sitt projekt? Jo, inte minst en möjlighet till att gå tillbaka och ångra saker som gått sönder eller som någon av misstag skrivit över. Eftersom varje ändring i varje fil sparas så kan man enkelt gå tillbaka i filens historia och kolla vad som ändrat, när något ändrat och vem som gått och ändrat. Och när det uppenbarar sig nya och oväntade buggar i sajten så är det en lättare att felsöka den genom att kolla upp vilka ändringar som gjorts i historiken.

När vi började med projektet i oktober så stod valet mellan Subversion, som vi alla kände från förr och det nyare och modernare Git som för de flesta av oss var ett system vi kände till, men som knappt någon av oss hade använt från tidigare. Git har ändå så pass många fördelar framom Subversion att vi valde att använda det. Den främsta fördelen som Git har är att det är ett decentraliserat system, dvs att man inte är lika beroende av en central server för alla versionerna, utan hela projektets alla filers alla versioner finns hela tiden tillgängligt också på din egna hårddisk, och på en centralt ställe som alla i teamet har tillgång till, det som i git kallas origin-repositoriet. Den andra stora fördelen med Git är att det är enklare att jobba på flera utvecklingsspår (såkallade branches) samtidigt.

En liten del av projektets git-logg.

Fram tills vi publicerade den slutna betan så klarade vi oss ändå bra med en huvudsaklig master-branch som vi alla sparade våra ändringar till. Nu, i och med att vi har en sajt som i det närmaste kan räknas att vara i produktion så behöver ändå lite mer kontroll över vad som läggs ut på produktionsservern. För att göra det lättare att ha koll på just det så använder vi nu två huvudsakliga branchar; master-branchen och dev-branchen. Nu sker alltså det huvusakliga utvecklingsarbetet i dev-branchen och endast färdiga och testade helheter ska sparas in i master-branchen. På det sättet så försöker vi minimera att det smyger in fel som kan ta ner sajten eller orsakar annan otrivsel för redaktörer och besökare.

Det är ändå inte helt problemfritt att jobba med många branches, framförallt blir det väldigt viktigt att se till att man är i den rätta branchen då man hämtar in och sparar ny kod, de första dagarna med flera branches gick åt att lära sig att hålla reda på var man var, och vart man höll på att spara sitt material, men redan nu känns det naturligt och enkelt att jobba med flera utvecklingsspår.

En historik som sträcker sig tillbaka till projektets början ger också fina möjligheter att visualisera hur projektet vuxit sig fram från starten i oktober fram tills idag: