Bitnami installationspaket för Open Source program

Bitnami är ett ”open source”-projekt som skapar färdiga installationspaket för många ”open source”-lösningar. Installationspaketen är kompletta med alla beroenden som behövs och väldigt enkla att installera. Mycket användbart om man behöver en testmiljö. Det finns installationspaket för Windows, Mac OS X samt Linux.

Exempel på applikationer som Bitnami har skapat installationpaket för:

  • WordPress
  • Drupal
  • Joomla
  • Git
  • Subversion
  • Jenkins
  • TestLink
  • Ruby
  • WAMP
  • LAMP
  • MAMP
  • Magento
  • Tomcat
  • Solr
  • JBoss

Alla installationspaket finns att ladda ned från Bitnami.com

Faran med code coverage som kvalitetsmått

När man skriver enhetstester så brukar man mäta hur stor del av koden som täcks av enhetstester. Detta ger en möjlighet att identifiera ställen i koden där man behöver komplettera med testfall.

I en del projekt sätter man upp krav att code coverage ska uppnå en viss nivå. Genom detta vill man säkerställa att lösningen ska hålla en hög kvalitet. Sannolikt så är ett projekt med högre coverage bättre testat än ett projekt med låg coverage. Code coverage är dock ett kvantitativt mått som inte säger så mycket om kvalitet. Det är möjligt att uppnå hög coverage utan att testerna för den delen håller en hög kvalitet eller tester rätt saker. Däremot är det ett utmärkt verktyg under utvecklingen för att identifiera ställen i koden som behöver testas mer.

Det är också viktigt att mäta coverage över rätt del av systemet. Om man bygger på en plattform som automatgenererar kod så tillför det inte så mycket att skapa testfall för dessa klasser och då bör de uteslutas helt från mätning för att inte snedvrida coverage för de kritiska delarna.

Det finns också flera sätt att mäta coverage. Till exempel kan man mäta antal metoder som täcks av tester, antal kodrader, antal klasser, antal villkorsgrenar, antal kombinationer av parametrar en metod kan ta emot m.m. Dessa mått ger olika information om vad som testas. Att ange ett generellt mått för coverage utan att veta vilken aspekt av coverage som avses är inte till så stor hjälp.

Code coverage är ett kraftfullt verktyg när det används rätt. Det ger möjlighet att analysera vilka delar av koden som täcks av tester och på vilket sätt de täcks. Däremot kan det bli väldigt missvisande om det används som ett generellt mått för kvalitet.

Kryptering av bärbara enheter

Det är alltid tråkigt när man blir bestulen eller tappar bort sin bärbara dator. Tyvärr kan det bli ännu tråkigare om en obehörig kommer åt innehållet på din dator. Till exempel kan mail-, facebook-, twitterkonton m.m. kapas. Om det dessutom finns känsliga dokument på hårddisken så kan det innebära enormt stor skada. Det är därför att rekommendera att kryptera bärbara datorer, surfplattor och mobiltelefoner.

iPhone och iPad

Apples iPhone och iPad krypteras enklast genom att aktivera låsskärmen som kräver att användaren anger en PIN-kod eller lösenord. Detta kommer att kryptera iMessages, mail och bifogade filer samt en del information i appar som har stöd för kryptering.

Androidenheter

Från och med Android 3.0 så har operativsystemet stöd för kryptering av hela enheten. Som standard så är all data okrypterad och användaren måste själv aktivera kryptering. När enheten startas måste man ange ett lösenord för att dekryptera informationen. P.g.a. av denna lösning så kommer enheten att ta något längre tid på sig att starta.

Windows

Från och med Windows Vista så finns BitLocker som kan kryptera hela hårddisken. BitLocker är endast tillgänglig i versionerna Ultimate och Enterprise av Windows Vista och Windows 7 samt Pro och Enterprise av Windows 8. Om man vill ha kryptering av andra versioner så finns det andra lösningar som TrueCrypt (OBS! TrueCrypt utvecklas ej längre från och med den 28:e maj 2014).

Mac OS X

FileVault är OSx lösning för att kryptera hårddisken. Den senaste versionen heter Filevault 2 och aktiveras i systeminställningar under ”Säkerhet och integritet”.

Linux

Det finns ett antal lösningar för att kryptera filsystemet i Linux. TrueCrypt fungerar bra för linuxbaserade system. (OBS! TrueCrypt utvecklas ej längre från och med den 28:e maj 2014)

Lagar kring kryptering

Något att tänka på är att lagstiftningen för kryptering ser olika ut i olika länder. I en del länder är man t.ex. skyldig att lämna ut sina krypteringsnycklar om myndigheterna begär det.

Nackdelar med kryptering

Beroende på vilken kryptering man använder kan det påverka prestanda på enheten. De flesta moderna enheter klarar av kryptering utan att prestanda går ned märkbart men för äldre enheter kan det bli en påtaglig försämring.

Att rädda data från en krypterad hårddisk vid haveri är mycket svårt. Om man inte har backup på data så kan det bli svårt att återställa.

Alternativ

Om man inte vill kryptera hela hårddisken kan man använda andra lösningar som endast krypterar delar av filsystemet. TrueCrypt har exempelvis stöd för att kryptera enstaka kataloger i filsystemet. Då kan man placera alla känsliga dokument där.

Automatisera från dag ett

Automatisering är ett bra sätt att minska tid och resurser som behövs för felsökning. En automatiserad process görs alltid på samma sätt och inga steg kommer att missas. Dessutom frigörs resurser till att göra viktigare saker då de slipper göra en massa manuella steg om och om igen. Ju tidigare man börjar automatisera desto bättre. Ju senare man börjar desto svårare kommer det att bli att eftersom de processer som skapats inte har designats för att automatiseras.

Automatiserade enhetstester

Om man inte har några enhetstester måste man testa koden genom att starta hela systemet och köra igenom olika testfall manuellt. Dels tar det tid att hela tiden starta systemet för att testa, stänga av systemet för att rätta eventuella fel, kompilera om och starta systemet igen och testa om. Då det blir för komplext och trögt att testa så kommer det inte att göras och eventuella fel upptäcks långt efteråt vid systemtestning. Dessutom finns en stor risk för att man glömmer något test eller inte utför det på exakt samma sätt som föregående körningar.

Automatiserade enhetstester kräver inte att systemet körs och kan ofta köras igång direkt från utvecklingsmiljön genom att trycka på en knapp. Testerna kommer alltid att köras på samma sätt och blir det fel så får man direkt feedback och kan rätta och köra om samtliga tester igen. På detta sätt så tar man effektivt bort småfel som annars skulle slippa igenom till systemtestning.

Enhetstester måste skrivas från dag ett i projektet. Att försöka skriva enhetstester i efterhand är komplext eftersom koden oftast inte skrivits på ett sätt som gör att den är testbar.

Blir det inte dyrt att lägga tid på att skriva automatiserade tester? Det är väl bättre att utvecklarna skriver ny funktionalitet? Automatiserade tester kräver naturligtvis en del tid att skriva men det är tid som sparas i senare steg genom att vi slipper lägga tid och resurser på komplex felsökning. Dessutom är det ett utmärkt verktyg att ha när systemet ska vidareutvecklas eftersom det också fungerar som regressionstest.

Automatiserat bygge

Att bygge ett system som består av flera olika moduler är en komplex uppgift. Om det dessutom är ett större utvecklingsteam som arbetar på olika delar av systemet så finns en risk att problem uppstår när de olika delarna ska integreras.

Det finns en hel del verktyg för att automatisera byggandet av system (ant, maven, msbuild o.s.v.). Det blir då enkelt att schemalägga byggen så att man bygger hela systemet åtminstone en gång per dygn och kör samtliga automatiserade tester för att fånga upp problem. Störst nytta får man dock om man dessutom använder en contiuous integration server som bygger systemet och kör alla enhetstester så fort en incheckning sker i versionshanteringssystemet. Då fångas eventuella integrationsproblem upp direkt.

Automatiserad deploy

När det närmar sig driftsättning av system så brukar det vara febril aktivitet. Det skrivs checklistor och planer för utrullning. Det bokas resurser som ska genomföra installationerna och testresurser som ska verifiera att allt ser bra ut. Nödvändig infrastruktur införskaffas och konfigureras.

I en del fall är driftsättning något som sker utan någon som helst generalrepetition för systemadministratörer och it-tekniker. Det är lite konstigt att ta en sådan risk med tanke på alla resurser lagts ned på att utveckla systemet. Även om det har funnits tillfälle att öva på processen i en produktionslik miljö så finns risken att man missar viktiga moment om det är mycket som ska göras.

Ju längre man väntar med att automatisera deployment och konfiguration av system desto svårare blir det att göra. Genom att redan från första dagen i projektet automatisera deployment processen så hinner man köra igenom den flera gånger under projektets gång. Målet bör vara att en driftsättning är så enkel att man bara trycker på en knapp för att genomföra det. Fördelen är att processen alltid kommer att genomföras på samma sätt vilket eliminerar att något steg missas och risken minskar för en misslyckad driftsättning. Dessutom är det ett utmärkt sätt att säkerställa att man kan återställa ett system vid en eventuell katastrof.