Det här är ett ganska gammal plugin till jQuery som jag hittade i helgen av en slump som jag börjat leka med. Efter att ha tittat lite mer på hur det fungerar måste jag säga att jag är imponerad över hur välbyggt det faktiskt är. Det är ett mycket rikt funktionsutbud som gör att det här pluginet kan användas för att illustrera flera olika linjekartor. Inte bara tunnelbanetrafik. Här finns flera exempel på hur man listar inte bara tunnelbanor utan även trender, teknikleverantörer och böcker.

Jag gjorde ett litet test över en begränsad karta av kollektivtrafiken i Hammarby Sjöstad. Lite stökigt att få till alla böjningar av linjer men jag tror att jag fill till det någotsånär.

http://www.kalyani.com/2010/10/subway-map-visualization-jquery-plugin/

För att ändå kunna fortsätta dela länkar från en RSS-läsare till WordPress har jag löst det på följande sätt:

• Läs rss-flöden via Feedly.com istället
• Dela blogginlägg med kommentarer via Tumblr
• Komplettera delning genom att använda Tubmlr’s booklet som gör att man kan dela vilken länk som helst med en kommentar via bokmärksraden i webbläsaren
• Använd min egen modifikation av SharedItems2WP så att den istället blir TumblrItems2WP. Ange RSS till dina inlägg som input-data i modulen. Exempel: http://pmnordkvist.tumblr.com/rss

I snart ett år har jag haft en idé om att bygga en automatisk Twitterskrivare baserat på en standardiserad kvittoskrivare för kassasystem. Att så fort jag får ny info på mitt twitterkonto så skrivs det ut ett kvitto med informationen i meddelandet. Jag har som haft en hookup på detta och gillar på något sätt enkelheten i det. En skrivare som bara finns till för att skriva ut tweets. Lika enkelt som Twitter självt på något sätt.

Vad jag gillar med just en kvittoskrivare:

• Skriver ut snabbt
• Har automatskärare. Klipper av när den är klar
• Har bra API’er för integration
• Kan köras standalone över ethernet utan bökig USB-koppling

Att börja leta rätt skrivare var inte det enklaste. Det finns en myriad av dem men jag fastnade tidigt för Epsons produktutbud. Dels har man många bra skrivare men man har också en inbjudande attityd till andra utvecklare som behöver integrera mot enheterna. Vidare är man aktiv inom Javacommunityn mot POS-enheter www.javapos.com. När jag till slut landade på en Epson TM-T88V var detta starka attribut:

• Ethernet-uttag
• USB-uttag
• Hög skrivarhastighet-uttag
• Beprövad modell, i version 5
• Drivrutiner för Mac OS X
• Påvisat fungerande med Java POS

Min idé var först att bygga en Java-app som ligger och snurrar och hämtar information från Twitters API’er och sedan skriver ut dessa på skrivaren. Jag började i tron om att jag var tvungen att använda mig av Java POS. Ganska snart insåg jag att integrationen blev mycket enklare än så. Kvittoskrivaren fungerar som vilken annan skrivare som helst så det blev mycket enklare att använda sig av Javas standardiserade skrivarklasser och bara skriva ut direkt mot dem. Enda trixet var att få bort skrivardialogrutan som by default visas vid Java-utskrifter. När detta väl var klart räckte det med att jobba med de grafiska detaljerna för själva utskriften.

Det krångligaste bestod ironiskt nog inte i att bygga själva appen som skrev ut utan i att få skrivaren att fungera med min Mac. Förstås. USB-anslutningen fungerande inte och inte heller Ethernet-kopplingen. Efter ett par timmars laborerande med DIP-switchar insåg jag att det fanns odukumenterade funktioner i skrivaren för att göra systeminställningar via några udda knappkombinationer där jag snart insåg att fabriksinställningen för skrivaren var att USB var avslaget och att Ethernet-enheten hade ett fast IP i en range som min router inte stödde. Efter aktivering av USB-sladden var allt uppe och rullade.

Twitter-skrivaren står och surrar i ett närliggande rum och det är faktiskt ganska kul att gå förbi och titta till lapparna som skrivs ut i jämn takt. I skrivande stund jobbar jag med att integrera skrivaren mot Magento-butiker så att den istället för att skriva ut tweets printar ordrar som läggs i en webshop. Känns som en väldigt läcker lösning för den som driver en webshop och vill få en mer direkt feedback på vad som säljs i butiken.

Jag återkommer när jag har något att visa där.

Eftersom Magento är ganska krävande som plattform gör det att APC får ganska stor betydelse på plattformen. Samtidigt kan det vara svårt att veta hur man skall konfigurera APC för access mot systemet. Därför vill jag passa på att tipsa om en bloggpost från Nexcess som har en bra bloggpost i ämnet. Framför allt är det cache-volymen som är viktig där standardkonfigurationen av APC är på 30MB. Nexcess rekommenderar 256MB och i de miljöer vi driftat har vi noterat att APC använder så mycket som 120MB av cache efter bara några timmar i drift.

Vi hjälper gärna till att svara på frågor om du kört fast någon gång.

http://www.facebook.com/home.php?sk=group_174149005966877

Missa inte heller vår bifogade exempelfil som vi refererar till nedan.

Kudos till Andreas för denna insats.

Bakgrund
Magento har allt sedan första versionen fått kritik för att vara ett otroligt resurskrävande sytem. I de första versionerna kunde en sidvisning ta upp till 2 sekunder utan att någon märkvärdig logik utfördes. I grund och botten beror detta på två saker:

• PHP i sig är det ganska tungt script-språk att exekvera. Mest på grund av att det är interpreterande och inte använder av bytekod som t.ex. Java eller C#.
• Magento har en väldigt komplex struktur och består av flera tusen PHP-filer vilket gör det långt mer krävande att exekvera än t.ex. WordPress eller Joomla.

Man kan säga mycket om detta men jag har alltid fått lära mig att det är bättre att ett system har bra struktur än hög prestanda. Man kan alltid köpa sig bättre prestanda genom cache-ning och dyrare hårdvara men man kan aldrig köpa sig bättre flexibilitet och struktur.

Så vad göra? Jag brukar rekommendera följande åtgärder:

1. Välj rätt hådvara och operativsystem
2. Trimma Apache/PHP/Mysql genom konfigurering
3. Snabba upp PHP genom kompilering eller cachemoduler som: eAccelerator/APC(alt APC)/XCache
4. Använd Magentos inbyggda cache-struktur
5. Använd Zend Frameworks underliggande cache-struktur
6. Använd Memcache för sessioner

Vår erfarenhet är att punkt 1, 3, 4 & 5 har påtaglig betydelse för prestandan i systemet medan konfigurationerna mer är lämplig vid väldigt stora trafikmängder. Skall man välja PHP-accelerator är vårt förslag APC som vi har bäst erfarenhet av. Alla presterar ungefär likvärdig prestanda men APC har visat sig vara mest kompatibel med uppdateringar av PHP och Apache.

1. Välj rätt hårdvara och operativsystem
Att snabba upp Magento handlar väldigt mycket om att snabba upp PHP generellt och därför är följande parametrar viktiga i val av hårdvara för Magento/PHP-plattformar:

1. Kör aldrig, aldrig Windows som operativsystem. Kör Linux eller Unix-baserade system. Linuxmiljöer vara upp till 6 gånger snabbare än windowsmaskiner.
2. CPU! Processorn är ofta flaskhalsen i hårdvaran eftersom varje sidvisning skall processa all kod varje gång. Ju fler kärnor desto bättre. Satsa på 8st om du har råd.
3. Accesstider på hårddiskarna. Eftersom det är så många olika filer som skall läsas in tenderar accesstiderna på hårddisken spela stor roll. Om du har råd: kör Solid State Disks(SSD)
4. Minne. Ju mer minne desto mer kan acceleratorerna cache’a. Snåla aldrig på detta. 12GB+ RAM kan vara en bra riktlinje.

2. Konfiguration av PHP/MySQL/Apache
Här rekommenderar vi Magentos officiella rekommendationer om konfiguration av primärt MySQL.

3. Installera en PHP-accelerator
Inga kommentarer. Installera en som passar dig. Kan bli 2-7 gånger snabbare. Detta gäller alla former av PHP-system, även WordPress. Lova att du gör detta och försök reservera minst 256MB minne för acceleratorn.

4. Magento Interna Cache
För att möta kritiken om den låga prestandan i systemet har Magento byggt en egen cache-struktur som snabbar upp följande delar:

• Configurationsinläsning
• Översättningsfiler
• Layout-konfigurationen
• Block-renderingar
• Collection-mängder
• Attribut-typerna(EAV)
• Webservice-konfigurationen
• I Magento Enterprise även Full Page Cache(Egentligen Zend Server Full Page Cache).

Dessa olika cachenivåer har olika betydelse men jag skulle nog ranka de 6 första som viktigast(förutom punkt 8 som är by far den bästa). Något som ibland kan ställa till det betänkligt är den första punkten. Confiugrations-cache eftersom om ändringar i local.xml görs utanför själva systemet nollställs inte cache och därmed inte configuration och dina ändringar slår inte igenom. I vanliga fall är detta inte speciellt komplicerad utan det räcker med att radera filerna i /var/cache-mappen men vi skall senare återkomma till varför detta kan vara minst sagt komplicerat. Detta har gjort att vi på allvar har funderat på att bygga en modul som utesluter local.xml ur configurations-cachen eftersom detta skulle säkerställa att vi alltid har god kontroll över konfigurationen, något som annars har ställt till det för oss. Man vill dock inte stänga av konfigurationen helt och hållet eftersom det inte bara är local.xml som cache’as utan även alla modulers config.xml och system.xml-filer. Däremot kan det vara ett tips att stänga av just denna cache när man laborerar med inställningarna i systemet.

5. Zend Frameworks cache-struktur
Detta är den del av systemet som ställt till med mest problem för oss eftersom Magento använder sig av den utan att någonstans dokumentera hur den faktiskt fungerar. Eftersom Magento till stora delar är byggt ovanpå Zend Framework finns stor potential i att använda deras olika cachemoduler men då det sällan varit speciellt tydligt hur det faktiskt fungerar kan det dels ställa till det för dig då många default-inställningar kickar in som man sällan känner till.

Zend Framework har några väldigt viktiga funktioner som man bör känna till:

1. Full Page Cache
2. Zend Two Level Cache
3. DB-cache
4. Memcache-cache

5.1. Zend Two Level Cache
Den sistnämnda läser man bland om i forum på nätet eftersom den kan ha väsentlig påverkan på prestandan i systemet. Detta eftersom den kan ersätta fillagring av datacache med lagring direkt i minnet. Dels är det bra för prestanda på en lokal maskin men kan vara direkt avgörande när man bygger ett serverkluster. Jag vill understryka att detta är riktigt, riktigt bra men ofta väldigt bökigt att konfigurera och använda. Detta främst på grund av default-inställningar i Zends Two Level Cache. Zends Two Level Cache bygger på att man använder en så kallas ”fast backend” och en ”slow backend”. Principen är att ”fast backend” andvänds i första hand och ”slow backend” i andra hand. Detta gör att man kan starta om en ”fast backend”-server som t.ex. memcache utan att det påverkar driften och stabiliteten i systemet. Problemet med detta är att om man konfigurerar memcache som primär cache(fast backend) UTAN att konfigurera en slow backend så blir lokal fillagring per automatik default ”slow backend” och eftersom ”slow backend” i regel innehåller fler nycklar än ”fast backend” så blir denna inte bara en failover utan också ett cache-steg som faktiskt alltid kommer att användas om än inte alltid.

Detta resulterar i ganska märkliga beteenden när du konfigurerar t.ex. ett serverkluster med 2 webbfrontar och använder en central Memcache-server som ”fast backend” men inte explicit konfigurerar en ”slow backend”. Då kommer en del av cache-nycklarna lagras central på memcache-servern och några lokalt i filerna på respektive webbfront. Därför är det av största betydelse att inte bara konfigurera ”fast backend” utan också definiera ”slow backend” och då skall denna också vara någon variant av central lagring. T.ex. databaslagring eller en central filmapp på en gemensam filserver. Tänk på här att om du har memcache-som cache-steg och har Configuration-cache påslaget så lagras numera local.xml-filen i memcache-servern och läses inte automatiskt ut från disk när du gör ändringar. Det räcker inte heller att radera innehållet i /var/cache utan du bör också för säkerhetsskull invalidera memcache-servern(eller rent av starta om den) och göra samma sak med DB-cache om det används. Detta blir ofta väldigt komplext och svåröverskådligt varav rekommendationen att stänga av Configuration-cache när du jobbar med inställningarna.

Tro mig. Detta kan ställa till stort förtret och det är mycket märkligt att Magento inte dokumenterat detta bättre officiellt. Som Enterprise-kund kan man dock få tillgång till en ganska hygglig sammanställning som man får tillgång till som Enterprise-kund. Vill du ha ett exempel på hur man gör en bra konfiguration av slow resp. fast backend så kan du se detta i vårt exempel här. Nyttig läsning och det tog ett tag innan vi fick allt riktigt rätt.

5.2. Zend Full Page Cache
Denna funktion är lite av den heliga gralen när man skall uppnå prestanda i Magento-installationer. Denna funktion följer med Magento Entprise och betyder helt enkelt att all output från en sida cache’as direkt i minnet på servern och det innebär att renderingarna sällan tar längre än 50 millisekunder. Denna cache slutar dock gälla så fort man lägger en produkt i varukorgen eller loggar in t.ex. Då slås den av och renderar sidorna som vanligt. I nyare versioner av Magento Enterprise är dock denna funktionalitet ytterligare integrerade i Magento och fungerar så att den bara stänger av Full Page Cache för vissa template-block  i renderingen av sidor vilket betyder att prestandan ökar betänkligt även när man lägger produkter i varukorgen.

Rent teoretiskt kan du använda Zend Full Page Cache utan att köpa Magento Enterprise. Då genom att köpa en licens(från €1200) av Zend Server som är den programvara som faktiskt innehåller denna teknik. Det är delvis denna Magento säljer när man köper Magento Enterprise. Då blir den lite klumpigare framför allt jämfört med de senare versionerna av systemet där FPC är så sömlöst integrerat i Magento. Hur som helst. En direkt avgörande funktion om du på allvar vill få upp prestandan i systemet.

6. Memcache för sessionshantering
Till sist kan du boosta prestandan i systemet genom att lagra sessioner i memcache istället för på disk. Jag har varit med om sajter som haft 1.5 miljoner sessionsfiler i /var/session-mappen vilket uppstår när man har stora mängder besök, även om de inte handlar något. I mindre sajter märks inte detta i någon större utsträckning men så fort trafikmängderna ökar är det viktigt att lagra sessionvärdena mer effektivt. Det gör man enklast genom att flytta lagringen av sessioner från fil till memcache. Instruktioner för detta finns även det i vår exempelfil.

En varning dock: vi har vid ett par tillfällen varit med om att admin-inloggningen slutar fungera när man använder memcache för lagring av sessioner. Vi har inte något intelligent svar på varför detta inträffat ibland annat än att vi misstänker problem med konfigurationen. Vår bifogade exempelfil fungerar dock.

Det är inte ovanligt att de stora bolagen tillsätter egen personal i t.ex. Linux eller Apache-projekten. Jag har alltid hävdat detta utan att riktigt haft någon tillförlitlig statistik som bekräftat detta. Tills idag. Den här artikeln på Mashable visar hur många och vilka som jobbat på Linux-kärnan de senaste åren. Här framkommer att enbart 25% av linuxkoden(eller antalet utvecklare i alla fall) är skrivet av privatpersoner och entusiaster. Väldigt intressant.

Vilka Open Source-projekt bidrar ditt företag till?

Precis detta dilemma vill PhoneGap / @phonegap hjälpa oss att hantera. PhoneGap är ett(av många – Rhomobile Appcelerator) utvecklingsramverk(öppen källkod) i vilket en webbutvecklare kan utveckla mobilappar som använder sig av de etablerade mobilplattformarnas hårdvara. Det är alltså en HTML-app inbakad i en native-app med ett generellt API för att anropa den underliggande hårdvaran.

Riktigt spännande om du frågar mig. Produkten gillas på webben just nu och i brist på annat måste jag säga att detta låter riktigt intressant. Jag kan se att detta är användbart om man är i behov av:

• Bred spridning till samtliga plattformar
• Snabb utveckling(ej beroende av flera olika utvecklarkompetenser)
• Spara pengar
• Prototyputveckling

Även om inga stora varumärken byggt sina appar på Phonegap(Appcelerator har ett bättre trackrecord på denna punkt) tror jag att det här kan vara en rimlig väg att gå. Framför allt om man inte bestämt huruvida man skall satsa sin utveckling på iPhone eller android men vill komma igång redan nu.

Men som sagt. Kul att det rör på sig. Det enda vi vet om mobilutvecklingen är att den kommer att vara fortsatt intensiv.

Efter all den HTML5-hajp som rått under våren tycker jag det är lite märkligt att vare sig Flowplayer(även om det finns ett inofficiellt plugin) eller JW Media Player lanserat någon HTML5-fallback för sina videospelare. Jag känner själv att jag har behov av att erbjuda iPad-kompatibelt video på något enkelt sätt utan utveckla egna HTML5-spelare.

Därför har jag sammanställt några olika alternativ om du behöver en smidig HTML5-player.

Flare Video
Måste väl sägas vara en iTunes/Quicktime. Men det är snyggt och bra. Kanske den bästa.
http://flarevideo.com/

Video JS
Också denna vädigt stilren och smidig. Känns också som den snabbaste. Flare Video tenderar att lagga emellanåt.
http://videojs.com/

Sublime
Väldigt slick och snygg lösning, framstår som seriöst och välgjort. Ännu inte lanserat men det kommer de närmaste veckorna.
http://jilion.com/sublime/video

Idén som jag förstår det är att iPhone-appen inte bara synkar länkar utan även flikar och sessioner. Så om man har en sida uppe i sin webbläsare som man kanske behöver om ett tag ute på vift slänger man bara upp Firefox Home och navigerar utifrån det som finns aktiverat i browsern hemma.

1-0 till Firefox.

http://blog.mozilla.com/blog/2010/06/30/firefox-home-submitted-to-apple-app-store/