Dessa ytliga sociala medier

Jag fick nyligen barn och då började min ”fritid” krympa betydligt. Jag måste därför prioritera och välja bort de saker som inte tillför så mycket till mitt och familjens nya liv. För ett tag sedan ifrågasatte min fru om jag borde spendera så mycket tid på Twitter och Facebook, eller på att blogga.

Det är en bra fråga. Hur mycket sociala medier är tillräckligt? Är det ens nödvändigt? Vad är det egentligen bra för? Är det bara ett meningslöst tidsfördriv?

I senaste numret av tidningen Success skriver Darren Hardy om skillnaden mellan att kommunicera och att faktiskt bygga relationer:

While I might be communicating with tens of thousands of people every day, outside of encounters with my immediate family and business team, I am not really connecting or fostering very many real relationships at all. I’m what’s called a mile wide and an inch deep, and that’s not how you strike oil! I’ve been mistaking communication for connection.

Den alltid lika kloke Seth Godin använder inte Twitter, och han pratar i den här videon kort om att sannt nätverkande är bra, men falskt nätverkande är meningslöst:

Networking is always important when it’s real, and it’s always a useless distraction when it’s fake. What the Internet has allowed is an enourmous amount of fake networking to take place, and it’s so easy to be seduced by it because there’s a dashboard, a scoreboard. ”Look how popular I am!”

Han berättar också i en intervju varför han inte använder Twitter (men har en av världens mest besökta bloggar och svarar på hundratals personliga mail varje dag). Mycket tänkvärt!

Susan DiMickele på The High Calling träffar mitt i prick i ett blogginlägg och beskriver ett fenomen som jag känner igen alltför väl från de svenska events som jag har varit på:

Sometimes the irony of it all smacks me right in the face. Like during a recent conference. We broke for lunch, and I couldn’t contain my glee when I learned the hotel had free wireless. Yippee! I could spend my lunch hour catching up on my blogging and even send a few Tweets! Then it dawned on me. I’m here to network with people, not sit behind a computer. What’s the best use of my time? I should probably introduce myself to that woman in the back of the room. I think I recognize her.

Den tid jag spenderar på Twitter kan jag inte spendera på annat. Den fråga jag nu brottas med är hur använder jag min tid på bästa sätt? Hur får jag och familjen största möjliga ROI på min tid? Har sociala medier en plats, och hur använder jag dem på bästa sätt?

Hur resonerar du?

WebAppers

Bloggen WebAppers är ett mycket bra ställe att få tips på resurser som är användbara när man bygger webbtjänster. De tipsar om alla möjliga Javascript-bibliotek för olika ändamål, men också en del PHP, ikoner och annan grafik. Jag ser alltid fram emot deras inlägg, och bloggen är även en bra resurs för att hitta rekommenderade bibliotek i efterhand.

Pangram

För att verifiera att en webbtjänst som jag utvecklar fungerar bra med exotiska tecken brukar jag använda pangram. Ett pangram är ett ord eller en mening som innehåller alla tecken i alfabetet.

Exempel på ett pangram på svenska är: ”Gud hjälpe Zorns mö qvickt få aw byxor”.

På Wikipedia hittar vi en mycket bra lista med pangram som det bara är att plocka av. De mest intressanta i det här sammanhanget brukar vara japanska, arabiska, ryska, thai, grekiska, tjeckiska diakritiska tecken etc.

  • とりなくこゑす ゆめさませ みよあけわたる ひんかしを そらいろはえて おきつへに ほふねむれゐぬ もやのうち
    鳥啼く声す 夢覚ませ 見よ明け渡る 東を 空色栄えて 沖つ辺に 帆船群れゐぬ 靄の中
  • صِف خَلقَ خَودِ كَمِثلِ الشَمسِ إِذ بَزَغَت يَحظى الضَجيعُ بِها نَجلاءَ مِعطارِ
  • В чащах юга жил бы цитрус? Да, но фальшивый экземпляръ!
  • นายสังฆภัณฑ์ เฮงพิทักษ์ฝั่ง ผู้เฒ่าซึ่งมีอาชีพเป็นฅนขายฃวด ถูกตำรวจปฏิบัติการจับฟ้องศาล ฐานลักนาฬิกาคุณหญิงฉัตรชฎา ฌานสมาธิ
  • Τάχιστη αλώπηξ βαφής ψημένη γη, δρασκελίζει υπέρ νωθρού κυνός
  • Příliš žluťoučký kůň úpěl ďábelské ódy

För kinesiska finns förstås inga pangram, eftersom ingen mening kan innehålla alla tusentals tecken som ”alfabetet” består av. Men Wikipedia har ett exempel ändå:

  • 視野無限廣,窗外有藍天

Och du kan alltid hitta fler tecken att använda genom att gå till en webbplats på språket och kopiera något ord eller stycke.

(En bra anledning till att använda exotiska tecken utöver vårt svenska alfabet är hur UTF-8 fungerar och hur Unicode-tecken kan representeras numeriskt med html. Alla tecken tar inte lika mycket utrymme; vissa kan kräva 2, 3 eller 4 bytes. Jag har skrivit mer om teckenkodning här.)

Permalänksstruktur för bloggar

De permanenta länkarna till inlägg på din blogg bör följa någon av dessa strukturer:

  • /2011/04/05/permalanksstruktur-for-bloggar
  • /2011/04/permalanksstruktur-for-bloggar
  • /2011/permalanksstruktur-for-bloggar

Det finns flera bra anledningar till varför just dessa strukturer är rekommenderade för bloggar, istället för något av dessa sämre val:

  • /214/permalanksstruktur-for-bloggar
  • /214 eller /?p=214
  • /permalanksstruktur-for-bloggar

De rekommenderade adresserna innehåller relevant information om blogginlägget. Det kanske inte ser så viktigt ut vid en första anblick, men läs Kyle Neaths inlägg om URL-design så kanske du ändrar dig.

URLs are for humans. Design them for humans.

En länk som innehåller datum talar om för besökaren (eller den som ser adressen utan att besöka sidan) att det är ett blogginlägg eller en daterad artikel samt ungefär när den skrevs. Länkar som bara innehåller inläggets titel ger ingen ledtråd om att det är ett blogginlägg eller när det skrevs.

Om man tar bort delar av adresserna, får man fortfarande begripliga adresser som leder till något meningsfullt. /2011/04 leder till ett arkiv med alla inlägg från april 2011 och /2011 leder till ett arkiv med alla inlägg från 2011. De sämre alternativen är meningslösa om man bryter isär dem, och det är inte uppenbart vad adressen till ett arkiv är.

På bloggen Entreprenörd har jag av SEO-skäl använt adresser av typen /permalanksstruktur-for-bloggar, men på mina nya bloggar har jag gått över till /2011/04/permalanksstruktur-for-bloggar. Matt Mullenweg gillar också detta format.

En ytterligare bonus är att WordPress kan få prestandaproblem med vissa av de sämre permalänkarna:

For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields.

Grymmaste svaret på Stack Overflow

Läs först frågan:

”A man in the United States popped out to his local petrol station to buy a pack of cigarettes – only to find his card charged $23,148,855,308,184,500.”

Anyone have any thoughts about what programming error would have caused this?

Det här måste vara det grymmaste svaret på Stack Overflow någonsin, skrivet av Göran Andersson (som är den svensk med högst reputation på webbplatsen):

Add the cents to the number and you get 2314885530818450000, which in hexadecimal is 2020 2020 2020 1250. Do you see the pattern? The first six bytes have been overwritten by spaces (hex 20, dec 32).

Jag har dock ingen aning om ifall det är sant, och det finns andra svar som hävdar att det inte verkar vara hela sanningen.

Skalbarhet, eller hur mycket server behöver jag för min webbapplikation?

Prestanda är viktigt på webben. Om din webbtjänst eller webbplats är bara en aning långsam, kommer användarna sticka därifrån. Det har skrivits en del om hur prestanda påverkar besökarna, exempelvis av Jakob Nielsen och Stoyan Stefanov. Vet du hur länge dina besökare får vänta på din webbplats, och hur du snabbar upp den?

Du bör inte fundera så mycket på prestanda och skalbarhet från början; du vet ju inte hur många besökare du kommer få. Då är det bättre att fokusera på att över huvud taget komma ut på marknaden, och sedan hoppas att du får så många besökare att prestanda blir ett problem. Övervaka belastningen och laddningstiderna och förbättra prestanda så fort det börjar bli segt. Inte tidigare (om du inte har för lite att göra och för mycket pengar).

För enkelhets skull utgår jag i resten av artikeln från att du har en enkel webbapplikation som körs på en Apache-webbserver med PHP och MySQL. Vi tar en titt på den enklaste arkitekturen, där allt körs på samma server:

Apache+MySQL-arkitektur

På webbserven finns ett antal Apache-processer som lyssnar efter förfrågningar från webbläsarna. (Om förfrågningarna blir fler än antal processer, bildas en kö där de tas om hand successivt. Om kön blir för lång får besökarna felmeddelanden.) Varje process levererar statiska filer som bilder, stilmallar och Javascript, men exekverar också PHP-skript och levererar resultatet till webbläsaren. Filerna ligger på hårddisken, som processerna får turas om att läsa från.

På samma server körs också en MySQL-databas, som processerna skickar SQL-frågor till. Databasen analyserar och exekverar frågorna, plockar fram det data som efterfrågats och levererar det.

När du nu har konstaterat att du behöver förbättra prestanda gör du så här, om och om igen:

  1. Mät prestanda i hela kedjan och hitta den största flaskhalsen.
  2. Förbättra bara den största flaskhalsen, och mät effekterna efteråt. Blev det bättre, grattis! Om det inte blev bättre, återställ och försök på ett annat sätt.

Om du inte följer den här metoden kommer du nog bli galen förr eller senare. Arkitekturer med många led och parallella processer är så komplexa och svåröverskådliga att du måste gå metodiskt fram för att vara säker på att dina ändringar faktiskt är förbättringar. Dessutom riskerar du annars att lägga onödigt mycket tid och pengar på prestandaförbättringar som inte får någon effekt.

Var flaskhalsarna sitter beror på vilken typ av belastning du har, hur din webbapplikation fungerar och mycket annat. Men här är några typfall av flaskhalsar:

  • Överföring av filer från webbservern till webbläsaren
  • Exekvering av PHP-skript
  • Exekvering av databasfrågor
  • Rendering av html-sidor med CSS-regler
  • Exekvering av Javascript
  • Hämtning av externa widgets och annonser

Så, hur åtgärdar vi dem? Jag går igenom några enkla tips för de allra vanligaste, nämligen de tre första.

Överföring av filer från webbservern till webbläsaren: Du kan exempelvis dela upp webbservern så att vissa processer levererar statiska filer såsom bilder, CSS och Javascript, och andra exekverar PHP-skript.

Statiska filer kan nämligen levereras många gånger snabbare än ett PHP-skript exekveras, och en Apache-process som kan exekvera PHP-skript kräver mycket mer minne än en som ”bara” levererar filer. Alltså kan du köra många fler processer som levererar filer än som kör PHP, vilket leder till högre prestanda för besökaren. (Titta exempelvis på Varnish som ett komplement till Apache.)

Statiska filer kan dessutom komprimeras för att ta mindre utrymme och därmed gå snabbare att överföra från webbservern till webbläsaren. Även en liten minskning i storlek kan ge stora tidsvinster om filen överförs tusentals gånger per sekund. Komprimering kan ske både med en så kallad minifierare för textfiler (exempelvis YUI Compressor) och genom att aktivera Gzip-komprimering i Apache. Bildfiler kan också komprimeras med Smush.it.

Exekvering av PHP-skript: PHP-exekvering kan snabbas upp flera gånger genom att aktivera en PHP-accelerator såsom APC. När PHP-skript ska köras, kompileras de nämligen av servern varje gång, och resultatet slängs bort. APC ser till att cacha resultatet av kompileringen så att det inte behöver göras om vid varje anrop.

Du kan också se om det går att skriva om din PHP-kod på ett mer effektivt sätt. Undersök vilka delar av koden som tar längst tid och skriv om dem. Det här är dock svårare än det låter.

Självklart exekveras PHP-skript också snabbare om webbserverns processor är snabbare (om de inte är så att PHP-skriptets flaskhals är när det läser från hårddisk eller liknande).

Exekvering av databasfrågor: Eftersom man kan hämta samma data från databasen med helt olika databasfrågor, är det absolut värt ett försök att skriva om dem. Undersök vilka frågor som tar mest tid och se om det finns några alternativ som du kan prova. (Exempelvis har jag själv delat upp en ganska komplex fråga i 30 enkla, och exekveringstiden minskade flera gånger!) Du kanske också behöver lägga till fler index för att snabba upp frågorna?

Använd en cache-server som Memcached för att lagra exempelvis resultatet av tidskrävande databasfrågor i minnet och få fram dem blixtsnabbt.

I extremfall kanske du till och med ska fundera på att byta från en ”vanlig” databas som MySQL till en som är bättre på att hantera enorma mängder besökare eller data. Exempelvis kör Google och Facebook helt andra databaser som gemensamt brukar gå under benämningen NoSQL. Titta exempelvis på Redis, MongoDB eller Cassandra. Men observera att du måste göra om hela databasmodellen och lära dig att tänka helt annorlunda.

Generella tips: Minne är vanligtvis ett enkelt sätt att snabba upp en server. Ju mer minne servern har, desto fler Apache-processer kan köras för att ta emot förfrågningar från webbläsarna. Ju mer minne, desto mer kan MySQL-servern cacha och slippa läsa från disk.

Istället för att samma server gör flera saker kan du förstås dela upp det så att olika servrar sköter olika uppgifter. Exempelvis kan en server exekvera PHP-skript, en annan leverera statiska filer och en tredje köra MySQL. Det här går att göra hur komplext som helst, läs exempelvis om Lunarstorms gamla serverarkitektur.

Du måste kanske heller inte köra Apache, utan kan använda Nginx istället. Det är en ganska ny webbserver som brukar vara mycket snabbare och används av fler och fler stora webbplatser.

Läs mer

Det finns mycket att lära om hur du kan göra din webbplats snabbare:

Surftown och Space2u är grymt bra på WordPress

I oktober publicerade jag ett test av WordPress-prestanda på fyra stora svenska webbhotell. Sedan dess har testerna (som utförs av Pingdom) fortsatt oavbrutet. Nu har jag tre månaders data att publicera, och det ser nästan likadant ut:

Webbhotell Svarstid Nedtid
Binero 1810 ms 14:22 h
Loopia 1859 ms 8:20 h
Space2u 401 ms 2:05 h
Surftown 508 ms 1:45 h

(För mer information om hur testet har gått till och annat, se den tidigare artikeln.)

Det är alltså ett stort glapp mellan två mycket bra bra och två mycket dåliga webbhotell vad gäller prestanda.

Space2u och Surftown är klara vinnare, som bjuder på riktigt bra prestanda. Å andra sidan har vi två webbhotell som i mina ögon anses mer populära, och de har märkligt nog hamnat i botten med riktigt dålig prestanda.

Det tar 4,5 gånger längre tid för besökarna att komma in på din blogg om du har den på Binero än på Space2u, dessutom kommer den vara helt otillgänglig 3 gånger så ofta. Hur kan det vara ”Bäst i test” enligt Internetworld?

WordPress-prestanda på webbhotell

För drygt en månad sedan installerade jag WordPress på ett par svenska webbhotell för att på något sätt mäta prestandaskillnader mellan dem på ett verkligt sätt. Jag skapade alltså identiska bloggar och använde sedan Pingdom för att mäta svarstiderna mellan 13 september och 20 oktober.

Resultat

Webbhotell Genomsnitt Min-Max
Binero 1644 ms 799-2540 ms
Loopia 1875 ms 1061-5498 ms
Space2u 539 ms 337-2300 ms
Surftown 515 ms 356-1417 ms

Svarstiderna gäller endast från Pingdoms servrar i Stockholm och Köpenhamn. Jag tycker inte att svarstiderna från övriga världen är lika intressanta.

Svarstiden är alltså den tid det tar från att Pingdom kontaktar servern till dess att bloggens förstasida har genererats och skickats tillbaka. Det inkluderar exekvering av PHP-kod och hämtning av data från MySQL-databas, men inte hämtning av bilder, Javascript, stilmallar etc.

Resultatet säger ju tydligt att Binero och Loopia är betydligt långsammare än Space2u och Surftown. Svarstiderna är också betydligt jämnare hos de snabbare webbhotellen. Jämför Loopia till vänster och Surftown till höger:

Loopia Surftown

Notera att det här testet inte är ett belastningstest, som visar hur webbsidan svarar under stor belastning med många besökare, utan endast testar en besökare i taget.

Upplevelser

Hos alla webbhotell kunde jag installera WordPress med något slags installationsskript. Uppgradering av både WordPress och plugins fungerade också från start, men hos Space2u och Surftown måste man fylla i ftp-uppgifterna manuellt.

Uppgradering gick absolut långsammast hos Surftown.

Hos Space2u var jag tvungen att redigera wp-config.php och ändra variabeln WP_LANG för att kunna välja svensk WordPress, hos övriga behövdes det inte.

Binero aktiverade automatiskt tillägget WP Super Cache (jag avaktiverade dock det för testet).

Hos Space2u måste man betala 295 kr per extra domän och det dröjer till klockan 4 på morgonen nästa dag innan den aktiveras. Hos övriga kan man lägga till nya domäner direkt och utan kostnad.

Webbhotellen

Jag registrerade ett vanligt webbhotell hos fyra leverantörer. Några hade jag redan oanvända konton hos sedan tidigare, och använde då dem istället för att skapa nya.

Namn Kostnad Registreringsdatum
Binero 69 kr/mån 7 maj (nya plattformen)
Loopia 83 kr/mån 29 december
Space2u 119 kr/mån 10 september
Surftown 61 kr/mån 10 september

Till varje konto kopplade jag sedan ett oanvänt domännamn.

Det är förstås möjligt att de nyare kontona ligger på servrar som inte har så många andra konton, och de äldre kontona ligger på överfulla servrar. Det får gärna någon kommentera.

Bloggarna

Varje blogg har den svenska versionen av WordPress 3.01 och använder standardtemat Twenty Ten med standardwidgets. Inga tillägg är aktiverade.

Jag la in tre artiklar med varierande längd av Lorem Ipsum (dock exakt samma på de olika bloggarna).

Android är större än iPhone?

2010 är året då Android-telefonerna blev fler än iPhone. Exakt när det infaller beror på vem man frågar och vilket land man tittar på, men de flesta analyser är överens. (Några andra som nyligen skrivit om detta är Veckans affärer och Telekom idag.)

Detta innebär att du för första gången når fler människor om du utvecklar en Android-app än en iPhone-app. Men också att det inte längre finns bara en stor app-plattform. Du vill förstås nå så många som möjligt, och då måste du utveckla appar till bägge plattformar — till dubbla kostnaden!

Om man inte vill betala för dubbel app-utveckling, bör man istället satsa på webbappar som kan köras på alla smartphones. De är inte riktigt lika kraftfulla i dagsläget, men det kommer nog bli bättre.

De kommande åren fortsätter Android att öka och iPhone att minska:

Undersökningsföretaget IDC tror att Android kommer ha 25% av marknaden 2014, och iPhone 11%. Gartner tror istället att Android har 30% av marknaden och iPhone 15%. Vissa tror att det blir ännu större skillnad.

Alla webb-startups måste läsa Getting Real

Om du vill ta fram och tjäna pengar på en webbapplikation, bör du verkligen läsa boken Getting Real. Undertiteln är ”the smarter, faster, easier way to build a successful web application” och boken är skriven av killarna bakom det ganska välkända företaget 37 Signals. De tjänar idag väldigt mycket pengar på sina webbapplikationer, exempelvis Basecamp.

Boken är ganska tunn och du läser ut den fort. Den finns att läsa gratis på nätet eller köpa om du hellre vill ha en e-bok eller riktig bok.

Jag går ofta tillbaka till boken för att plocka ut citat eller idéer när jag diskuterar med andra. Den är en riktig guldgruva! Några av mina favoritcitat:

If your app doesn’t excite you, something’s wrong. If you’re only working on it in order to cash out, it will show. Likewise, if you feel passionately about your app, it will come through in the final product.

Don’t expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there’s no need to ship perfection.

Beware of the ”everything but the kitchen sink” approach to web app development. Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product.

People often spend too much time up front trying to solve problems they don’t even have yet. Don’t. Heck, we launched Basecamp without the ability to bill customers!

Boken är indelad i 16 kapitel och går igenom allt du behöver tänka på för att ta fram en webbapplikation:

  1. Introduction
  2. The Starting Line
  3. Stay Lean
  4. Priorities
  5. Feature Selection
  6. Process
  7. The Organization
  8. Staffing
  9. Interface Design
  10. Code
  11. Words
  12. Pricing and Signup
  13. Promotion
  14. Support
  15. Post-Launch
  16. Conclusion