Hoppa till innehåll

Webbutveckling, systemförvaltning och design

Our take on web, social media and other tech stuff. From the people behind www.kth.se

Tekniken bakom KTH Social

På förekommen anledning ska jag skriva lite om KTH Social och hur tekniken bakom ser ut. Så det här blir ett utpräglat långt, svamligt, tekniskt, torrt och nördigt inlägg på bred svengelska med mängder av länkar för den som vill gräva ner sig mer. Lite erfarenheter kommer på slutet, så snabbspola dit om tekniken inte intresserar er.

Teknik

Det hela är egentligen inte särskilt märkvärdigt, själva tjänsten är skriven i Django, ett python-baserat webbramverk. Det är ett rikt ramverk med template- och formulärhantering, en egen ORM och relativt avancerat stöd för cachning på olika sätt, vanligast memcached som är så gott som standard på Linux men även finns på olika sätt för andra Unix-derivat, Mac OS X, Windows, mfl. Vi driftar KTH Social på RedHat Enterprise Linux.

Det finns en omfattande ekologi med olika plugins till Django. Svårigheten ligger som ofta i att bedöma vilka av alla pluginer som har en vettig verkshöjd och underhålls ordentligt. Vi använder ett flertal pluginer bland vilka märks:

  • django-celery – Django-integration av celery, för köhantering och exekvering av asynkrona jobb i sajten som e-postutskick och periodiskt underhåll.
  • django-haystack – För sökning, med Apache solr som indexeringsmotor.
  • django-autoslug – För hantering av ”sluggar” för användarvänliga URL:ar.
  • django-rosetta – För internationalisering, vi stödjer svenska och engelska idag.
  • django_compressor – För effektiv hantering av JavaScript och CSS.
  • South – Databasrevisionshantering som ger möjlighet att effektivt och automatiskt hantera ändringar i databasschema och information.

Vi kan hantera de olika pluginerna och våra beroenden rent allmänt med hjälp av virtualenvpip och python package index, i sig goda anledningar till att överväga python som plattform. Vill ni veta mer om de pluginer jag nämnde ovan, så sök efter dem i pypi.

I början använde datalagret Djangos ORM rätt upp och ner mot en MySQL-databas. De delar som är en del av själva Django ligger fortfarande där, men vårt eget data har sedan dess flyttat över till en NoSQL-databas, MongoDB, ett val som är hajpat och något förklarat i Computer Sweden. I och med det har vi också i hög grad lämnat Djangos ORM. Det finns paket som försöker mappa ORM:en till MongoDB, men eftersom det är just en ORM och relationsdatabasen lyser igenom den en hel del blir det väldigt märkligt, så vi har istället gjort egna abstraktioner på pymongo.

Gränssnittet är Django templates rakt av och vi använder ganska lite JavaScript även om det finns en ambition att på sikt Ajax-ladda mer information för de som kan. De javascript som finns är primärt jQuery-baserade. Ett av de primära undantagen är TinyMCE, den javascript-baserade editor vi använder så gott som överallt och som vi också har skrivit vissa pluginer till, framför allt vissa förenklade versioner av formulär för uppladdning av bilder och filer, Dessutom en enkel matte-editor som kan ta TeX-uttryck och rendera ”snygga” formler, men den skulle må bra av lite mer kärlek.

Det andra undantaget är den ”personliga menyn” som finns längst ner på många webbsidor på KTH och som under sommaren hösten kommer att utvecklas till den systemomspännande resurs den är tänkt att vara. Den är gjord för att enkelt kunna skjutas in med javascript i befintliga system och det är också gjort i ett flertal. Den kommer att berikas med mer information, länkar till andra system och notifieringar och i samband med det ändra utseende en hel del till nästa år.

Systemintegration

Här är en någotsånär uppdaterad systemskiss över de olika komponenterna i KTH Social och hur data flödar mellan KTH Social och övriga delar av KTH:s webbplats, klicka på bilden för en förstoring.

  • UG är vår centrala katalog för användare och grupper i KTH:s system och KTH Social populeras med data därifrån med hjälp av en ”propagator”.
  • CAS är single-signon-lösningen för webbautentisering som används på KTH och många andra lärosäten.
  • WebTex är en egen, avsevärt enklare, implementation av den tidigare, mer öppna varianten, av Mathtran för generering av bilder av TeX-uttryck som vi använder för snygga formler.
  • Bilda (Ping-Pong) är det LMS som används på KTH.
  • Timeedit är det system som används på KTH för schemaläggning.
  • Kopps är kurs- och programkatalogen med information om våra utbildningar.

Vi har, i alla fall än så länge, ingen mer avancerad integrationsarkitektur på KTH i dagsläget utan integrationer görs huvudsakligen med enkla REST-baserade gränssnitt med mer eller mindre lösa kopplingar. Det är dock få system som integrerar med mer än ett annat, så det är inte riktigt så kaosartat som det skulle kunna vara.

Test och integration

Vi arbetar en hel del med automatiserade testsviter med runt sexhundra testfall och rimlig kodtäckning som körs med nose (se även django-nose) vilket ger oss en viss trygghet när vi gör större ändringar i systemet.  De flesta testfall har en hög abstraktionsnivå, dvs det är scenarier där en head-less webbklient gör olika requests och resultaten verifieras.

Vi har en Jenkins-server som bygger och testar alla brancher och driftsätter en del av dem till ett antal olika testmiljöer för manuell testning. Vi har även en nattlig prestandakörning som drivs av JMeter, mest för att övervaka att vi inte checkat in något dumt som drar ner prestanda markant för vanliga fall.

Metodik

Vi arbetar agilt med korta leveranscykler. I realiteten försöker vi leverera inkrement var eller varannan vecka. För att kunna göra det är installationen automatiserad och i de flesta fall blir det reella driftstoppet kort, i storleksordningen en halv minut. Görs det databastransformer säkrar vi upp med backup innan installationen görs vilket innebär att det kan ta några minuter. MongoDB dumpas väldigt snabbt och datamängderna är inte gigantiska. Media lagras direkt på disk och inte i databasen.

Däremot arbetar vi för närvarande inte enligt någon strikt metodik längre. Vi har arbetat med Scrum tidigare men haft svårt att få till det i det här projektet där ramarna är ganska flytande. Det har experimenterats med Kanban som konsekvens av det för att landa i något som kanske kan beskrivas som ett mellanting. Vi använder git och git-flow för att effektivt kunna svänga snabbt och prioritera om i utvecklingsarbetet.

Lite erfarenheter

Personligen tycker jag nog att det inte är helt lyckat att det slutade med att vi utvecklade detta helt själva istället för att utgå ifrån en av de produkter som finns på området. Samtidigt stödde jag i allra högsta grad beslutet när det gjordes och tror fortfarande att det var rätt givet den situation vi befann oss i. Å ena sidan kan man hävda att vi har kunnat och kan specialanpassa väldigt mycket mer utifrån KTH:s specifika behov och att vi lärt oss väldigt mycket på vägen, å andra sidan hade vi kanske kunnat fokusera på andra saker istället. Se för övrigt tidigare inlägg av mig om enkelhetsfällan och standardisering.

Eftersom vi har lämnat Djangos ORM börjar argumenten för att använda Django alls bli tunna. Django själv och många av dess fördelar liksom övriga pluginer och färdiga saker på nätet förutsätter att man använder ORM:en. Tänker man sig använda Django ska man nog ha väldigt starka skäl för att inte använda ORM:en också fullt ut. Tänker man inte använda den finns det andra, tunnare, pythonramverk för webbutveckling man nog ska överväga att använda istället.

Använder man Django är det lätt att trilla in i att använda app:ar som funktionsgruppering, kanske för att man är van vid t.ex packages i Java som ser lite lika ut. Gör inte det. En app ska vara en återanvändbar delmängd funktionalitet som man kan extrahera ut och stoppa in i någonting annat. Om det inte är det är det ingen idé och krånglar bara till. Vi har försökt slå ihop en del av alla våra app:ar vartefter.

Ska du utveckla med tekniker som Python, Django, MongoDB, memcached osv (och inte minst git) är det i realiteten Linux/Unix eller Mac OS X du vill använda. Det går att använda Windows som bas för utvecklingen, vi har sett till att det går att utveckla KTH Social och köra alla tester (utom fyra) i vår Windows 7-miljö på KTH, men det är mer eller mindre smärtsamt och bara för den händige.

Git är på sätt och vis trevligt men hajpat och ganska besvärligt på Windows. Man har återanvänt begrepp ifrån andra versionshanteringssystem till helt andra saker vilket förvirrar och de hundra och en kommandon och optioner som finns är semistrukturerade och omöjliga att överblicka och förstå. Google är din bästa kompis om du ska använda git. Funderar ni på git ska ni fundera på git-flow och deras modell för att hantera brancher i git.

Om ni letar efter en bra marknadsnisch att ge er in i, överväg schemaläggning och lokal/resursplanering för skolor och universitet. De flesta av oss använder samma system som alla hatar. Vi också.

Profilbild
Jag arbetar som chef över IT-arkitekturgruppen på IT-avdelningen på KTH.

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *