av Kent Beck

ISBN: 9780321146533

Detta är en bok som i tre steg visar hur Kent Beck tycker man skall skriva kod. Boken är lättläst, enkel att förstå och Beck är ganska tydlig i vad  han menar och hur han föreslår att man skall jobba.

Min behållning av boken är den lilla privata lappen med “test att skriva” - något som han alltså förespråkar men som jag själv aldrig använt i större utsträckning. Jag petar istället ner alla test-idéer i kod, typ:

// FIXME: testa null

Om jag skall ge mig på att sammanfatta vad han förespråkar så är det:

• börja litet
• använd en lista där du skriver upp testfall som du vet eller kommer på behöver testas
• låt design växa fram
• använd refaktoreringssteget till att skriva den riktiga implementation
• misslyckas man med ett stort test, skriv ett mindre istället
• få hellre ett test till att gå igenom än att ha vacker kod

Jag rekomenderar boken till någon som har ett hum om vad TDD är men som inte sett hur det kan fungera i praktiken. Kodexemplen är visserligen ganska lätta men det intressanta är att se hur han jobbar med problemlösning, vad TDD-metodiken ger och att det banne mig inte är svårt att börja.

<build><plugins><plugin>
				<groupid>org.codehaus.mojo</groupid>
				<artifactid>maven-buildnumber-plugin</artifactid>
				<version>0.9.6</version>
				<executions>
					<execution>
						<phase>validate</phase>
						<goals>
							<goal>create</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
</plugins></build>

Denna plugin kräver att man satt upp SCM ordentligt så att versionnummer kan hämtas därifrån!

<build><plugins><plugin>
				<groupid>org.apache.maven.plugins</groupid>
				<artifactid>maven-war-plugin</artifactid>
				<version>2.0</version>
				<configuration>
					<archive>
						<manifestentries>
							<implementation -Build>${buildNumber}</implementation>
						</manifestentries>
					</archive>
				</configuration>
			</plugin>
</plugins></build>

	private String readBuildNumber(ServletContext servletContext) {
		try {
			URL resource = servletContext.getResource("/META-INF/MANIFEST.MF");
			InputStream manifestStream = resource.openStream();
			Manifest mf = new Manifest(manifestStream);
			Attributes atts = mf.getMainAttributes();
			String value = atts.getValue("Implementation-Build");
			if (value == null) {
				throw new IllegalArgumentException("Implementation-Build attribute is not set in MANIFEST " + resource.toExternalForm());
			}
			manifestStream.close();
			return value;
		} catch (Exception e) {
			throw new IllegalStateException("Failed to read Implementation-Build attribute from MANIFEST.MF");
		}
	}

Eller som vanlig resource (properties)

<build>
		<resources>
			<resource>
				<directory>src/main/resources</directory>
				<filtering>true</filtering>
			</resource>
		</resources>
</build>

public class EmptyMatcher extends TypeSafeMatcher&lt;Collection < ?>> {
 
    @Override
    public boolean matchesSafely(Collection< ?> c) {
        return c.isEmpty();
    }
 
    public void describeTo(Description desc) {
        desc.appendText("empty");
    }
 
    @Factory
    public static lt;T> Matcher< ? super Collection<?>> isEmpty() {
        return new EmptyMatcher();
    }
}

som gör att man kan skriva trevlig enkelt läsbar kod, t ex:

@Test
public void filteringAnEmptyListReturnsAnEmptyList() {
    List anEmptyList = new ArrayList();
    List result = testee.filter(emptyList());
    assertThat(result, isEmpty());
    // men helst: assertThat(result).isEmpty();
}

Lösningen fungerar fint och Tomas kunder (mäklare där två kontor nu kör för fullt) är nöjda, så pass nöjda att jag skall försöka se om vi inte kan få fler kunder att använda systemet.

Introduktion

Måns Jonasson (@mansj) från .SE började med att jämföra med webben 1996, en tid då alla satt med 14.4-modem och bandbredd var både långsamt och smalt. På den tiden optimerade alla sina webbsidor för att ladda snabbt - optimering var naturligt och vanliga webbkonton hos t ex Algonet tilldelades hela 5 MB lagringsplats. Nu för tiden är disk på servrar billigt, liksom bandbredd (trafik och kapacitet) och Måns pekar på någon form av “alla har ju bredband ändå”-mentalitet. Tre saker utpekas som orsaker till att optimering inte genomförs:

• tidsbrist nedprioriterar optimering,
• erfarenhetsbrist - “varför skall man bry sig om att vinna en sekund snabbare laddning”?
• pengar - det kostar.

(Jag hade ju hävdat att tid är pengar och därför är det bara två punkter som pekas ut … :)

Hälsoläget

Patrik Wallström (@pawal) från .SE tog därefter över stafettpinnen och berättade om vad “Rapport Hälsoläget” är och hur .SE mäter och utvärderar hur “internet” fungerar. Bl a innehåller rapporten analys av DNS-delegeringen (dnscheck) av domäner under .se, kontroll av e-postsystem (mailcheck) inkl anti-phishing-tekniker som SPF, DKIM, TLS*, ADSP.

Hälsoläget är numera data-insamlad en gång i månaden. Medelstorlek på en webbplats under .se ligger på ca 200KB, fler och fler använder gzip. De 100 snabbaste siterna var i princip “It works!”-sidor från Apache (föga intressant) så Patrik hade istället tittat på de 100 långsammaste, som alla var långsamma CMS-installationer (Joomla, WordPress, Sharepoint). För identifiering har trends.builtwith.com använts hittills, men whatweb kommer nog användas (och utökas) i framtiden. Förslag på vad som kan och bör mätas mottogs tacksamt och jag föreslog att man försöker mäta upp hur dåliga DNS-servrarna är hos ComHem de få ISP:er vi har i landet (eftersom ISP:erna själva inte ser det som ett problem tycker jag det skall lyftas fram av de som kan lyfta fram det i ljuset).

Optimera WordPress

Erik Torsner från LoadImpact.com pratade om problemen som WordPress dras med och det främsta är minnesförbrukning för att generera sidor. En ren 2.9-installation kräver 16 MB per anrop till en sida med ett bloginlägg. Plugins som All-in-one SEO och Similar Posts lägger vardera på 1 MB. Värstingen är WPML (flerspråksplugin) som trycker upp minnesförbrukningen till 70 MB per anrop!

Ett par tips lämnades. Först ett par allmäna som att se över databas och mäta minnes- och CPU-förbrukning (lägg in en memory_get_peak_usage() i footern). Därefter tipsades om att använda en cache-funktion, t ex någon av alla de WP-plugins som finns. W3 Total Cache (W3TC) kan komprimera, minifiera, kombinera script-anrop och stödjer hosting av media på CDN. Dessutom kan den “kortsluta” (kringgå hade jag kallat det) PHP-stacken genom att skriva ner resultatet för en sida till disk och låta Apache serva den direkt (via mod_rewrite-magi).

Ragnar Lönn från samma bolag fortsatte sedan med att tipsa om mätverktyg. Påminde också om att Google sedan 2008 väger in landningssidans laddtid i AdWords quality score. Han nämnde också Shopzilla som genom att sänka sin laddtid från 7 sekunder till 2, såg:

• 25 % fler sidvisningar,
• 10 % ökade intäkter, och
• fick 50 % lägre infrastrukturkostnader.

Sidanalys

• Firebug med
  • YSlow och
  • Google Page Speed.

(Ragnar påstår i förbifarten att POST för Ajax är lika bra som GET(!) - YSlow hävdar motsatsen.)

Extern sidanalys (alla gratis i viss omfattning, men inte fria)

• pingdom tools (minus är att de inte parse:ar CSS:en och därmed inte tankar grafik som tankas i vanliga fall)
• Load Impact Page Analyzer - emulerar olika klienter, kan begränsa bandbredd
• webpagetest.org - bara IE7 IE8
• browsershots.org

Lasttest

• grinder (saknar bra medföljande GUI)
• openSTA (windows only)
• Apache Bench
• Load Impacts eget verktyg
• browsermob.com
• loadstorm

Fikapaus med frukt, kaffe/te och småmackor.

Ajax och REST

Stefan Pettersson från Netlight pratade sedan om hur han föreslår att man kan “Snabbare tjänster med Ajax och REST”. Innehållet var det inget fel på alls men så basic att jag inte förde en enda anteckning (förutom på min frågelapp, nämligen att de “hajpade noSQL-alternativen” faktiskt också skalar bort en box i hans presentation - datakonverteringen, lite bakläxa där tycker jag på ett annars bra innehåll).

Mer data på kortare tid, tack!

Daniel Stenberg från haxx fortsatte sedan med den tekniktungaste presentationen som rörde sig på transportnivå och pratade om problem med TCP och möjligheter med nya protokoll och experiment. Han sammanfattade själv i följande punkter:

• RTT står i princip still trots att bandbredd ökar
• TCP har fördröjning och det drabbar HTTP (och alternativ finns, men till skillnad från IPv4-IPv6 så står ingen och säger “nu MÅSTE vi byta”, betänk t ex alla brandväggslösningar som inte vill ha SCTP)
• använda rätt API:er (libevent vs poll/select) - upp till 70 % bättre throughput
• WebSockets, SPDY, SCTP, MPTCP

Daniel skulle inte bli förvånad om MPTCP (multi path) blir verklighet snart, dvs att man kan nyttja t ex både WLAN och GPRS/motsv från sina mobila enheter samtidigt.

Lunch.

Skalbarhet i molnet

Martin Källström från Twingly gick igenom grunderna i skalbarhet och landade tillslut i att det finns ingen teknik som ger skalbarhet från början, utan detta är något man bygger in i s in applikation (om han inte kört dotnet så mycket kanske han vetat att JEE-specen tar upp horisontell skalbarhet och “ger” (säljer in) stöd för det).

Konkreta tips delas liksom erfarenheter av t ex Amazon S3 (dyrt, långsamt, support kostar extra). Det dyra för twingly är de ca 4 miljarder anropen man får per månad - datamängden är inte stor alls. För skalning av long-polling-lösningar (Comet) använder man Hetzner.de. Andra erfarenheter Martin talade om var problematik kring:

• nertid och serverflytt,
• Comet kräver systemkonfiguration som saknades i VPS,
• fluktuerande valuta (balansera med intäkter i de aktuella valutorna).

Klientsideoptimering

Svante Adermark (med kompis) från Trimlabb (del av Fleecelabs) var först ut på detta ämne och gav en presentation som innehållsmässigt var väldigt lik den presentation jag höll för dotnet- och JavaForum i februari! (Jag försökte ha bilder istället för text.) Vi hade nästan exakt samma rekomendationer om lågt hängande frukter och ev skillnader tjötade vi om under eftermiddagens

Fikapaus.

Optimering av stockholm.se

Isac Lagerblad från Creuna pratade sedan om hur man hade tagit steget ut ur garderoben och tagit tag i webbplatsens prestanda med bl a CSS-spriting, minifiering och konkatenering … Dyrast tyckte Isac att konkatenering varit, samt underhåll av CSS-sprites.

JavaScriptoptimering

Jacob Hansson från Skyforge och VoltVoodoo höll dagens intressantaste presentation (tyckte jag) med lite tips och nyheter som jag inte sett tidigare: Speedtracer för Google Chrome. Seesmic hade tjänat tre sekunder i uppstarttid på någon applikation genom att slå ihop Ajax-anrop istället för att skicka dem ett och ett. Rekomenderade också att man lägger tid på code-splitting (optimera startsida från de andra t ex).

Övriga tips var att hålla sig under 50 millisekunder i all exekvering. Med QUnit och JSLitmus föreslog Jacob att man skall se till att man håller sig under den gränsen (regressionstester) och jake är ett byggverktyg som han förordade. För testning i multipla browsers nämnde han två lösningar: JS Test Driver och Mozillas croud source-baserade lösning.

Ingen nämnde under dagen lazy-laddning av JavaScript som kommer utkommenterad från serversidan, som sedan kan aktiveras vid behov genom att evaluera koden utan start- och slutmarkörer: eval(src.substring(2, src.length - 2)).

Squid och andra cachelösningar

Henrik Nordström avslutade dagen genom att titta på hur man kan sätta upp squid som reverse proxy för att avlasta, lastbalancera osv. Henrik gav sig också på att uppmuntra till alla att få Etag-headern rätt använd - modigt! :)

Sammanfattning

Detta var kanon och blev lite plåster på såren för att jag missar SWDC i år också. :P

• Google.com: +500 ms (speed decrease) -> -20% traffic loss [1]
• Yahoo.com: +400 ms (speed decrease) -> -5-9% full-page traffic loss (visitor left before the page finished loading) [2]
• Amazon.com: +100 ms (speed decrease) -> -1% sales loss [1]

[1] http://home.blarg.net/~glinden/StanfordDataMining.2006-11-29.ppt
[2] http://www.slideshare.net/stoyan/yslow-20-presentation

Hur som haver - efteråt gäller det att signera och få iväg de signerade nycklarna. Till detta finns caff, CA Fire and Forget, som just gör det man vill:

• hämtar hem nyckeln
• signerar den
• skickar den krypterad till mottagarens adress (bara mottagaren med rätt privat nyckel kan läsa signaturen).

caff -m yes -u 9B1E4234 `cat keys-to-sign.txt`

och detta kommer i paketet signing-party.

Det finns dock inget som plockar ut fingerprintdelen ur den ASCII-fil som distribueras, så jag fick hacka ihop detta själv med lite python:

#!/usr/bin/python
 
indicies = []
keysByIndex = {}
lastIndex = False
 
# get the indexes of the keys "verified", as they appear on the key paper (000, 001, ...)
for line in open("id-verified.txt"):
  if len(line) == 4:
    indicies.append(line[0:3])
 
# build up index > key part
for line in open("ksp-fosdem2010.txt"):
  if "Fingerprint OK" in line:
    lastIndex = line[0:3]
  else:
    if lastIndex:
      key = line[12:20]
      keysByIndex[lastIndex] = key
      lastIndex = False
 
# write keys out to file
print "You've mareked %s out of %s - verify this before running caff" % (len(indicies), len(keysByIndex))
out = open("keys-to-sign.txt", "w")
for index in indicies:
  key = keysByIndex[index]
  out.write(key)
  out.write(" ")

Efter det inträffade har sjukhuset fått installerat en så kallad spanning tree-funktion som förhindrar störningar på grund av felkopplade kablar.

Den visar sig inte vara översatt till svenska (använder gtranslator för detta) och den kommer inte förkompilerad som binär. Det var längesedan jag byggde debianpaket, men det brukar vara ganska enkelt. Låt oss se:

sudo aptitude install debian-builder

Efter uppackning av tar-bollen kör jag debuild som säger:

dpkg-checkbuilddeps: Ej uppfyllda byggberoenden: cdbs (>= 0.4.43) debhelper (>= 6) python-distutils-extra (>= 2.10)

Så vi drar in dem med: sudo aptitude install cdbs debhelper python-distutils-extra och kör debuild igen.

Bygget fungerade tyvärr inte ändå och fick rapporteras som en bugg. Använder tills vidare timer-applet.