Google Fonts är en stor tillgång för mig när jag designar för webben. Jag tycker att det fungerar otroligt smidigt då jag kan vara säker på att texten faller väl ut på hemsidan och att de inte har några invecklade användarvillkor att ta hänsyn till. I skrivande stund finns det över 600 typsnitt i Googles bibliotek – och visst varierar kvalitén – men det finns tillräckligt många bra för att lyfta designen.

Tidigare var man tvungen att manuellt ladda ner typsnitten som man ville använda i designarbetet, vilket egentligen inte har varit något problem – ända tills man insåg att det fanns en bättre lösning.

Vad är Sky Fonts?

Sky Fonts är en tjänst som låter dig temporärt installera de typsnitt du vill använda. Använder du flera datorer så synkroniseras de mellan dem. Tidigare var det enbart kopplat till biblioteket Fonts.com, där man genom Sky Fonts kunde hyra de typsnitt man ville använda. Men nu finns också en koppling till Google Fonts, vilket öppnade mina ögon för tjänsten. Sky Fonts synkar inte bara teckensnitten mellan datorer, utan ser också till att de är uppdaterade till den senaste versionen.

Sky Fonts har främst kortat ner ledtiderna, från att man hittar ett typsnitt till det att man kan använda det i ett program. Efter installationen dyker en ikon för programmet upp i menyn hos OSX där man lätt kan se över sitt urval hos Google. Vyn visar hela katalogen ur Google Fonts och genom att klicka på ”Add” laddas det valda typsnittet ner och installeras  automatiskt.

I framtiden skulle jag också vilja se möjligheten att jobba med typsnitten direkt, utan att behöva ladda ner dem lokalt. En integration i exempelvis Sketch eller Photoshop som låter dig välja direkt ur Googles bibliotek hade varit otroligt smidigt. Jag tror också att det hade fungerat ganska bra, med tanke på att man ständigt är uppkopplad mot internet.

Om du är sugen på att prova Sky Fonts rekommenderar jag att du besöker deras hemsida och laddar ner det. Programmet finns både för Mac och PC. Skriv gärna vad du tycker om det i kommentarsfältet.

I ett tidigare inlägg berättade jag om hur jag provade programmet Sketch, en vektorbaserad bildbehandlare med fokus på webben. Mitt tycke för programmet var ingen kortvarig romans, utan jag har fortsatt att använda det i flertalet projekt. Här tänkte jag berätta om några funktioner som gör Sketch så trevligt att arbeta i.

Griddsystemet

Griddsystemet i Sketch är något mer avancerat än i exempelvis Photoshop och Illustrator. Här utgår man från de griddsystem som man ofta ser på webben, nämligen de kolumnbaserade. Man kan ange antal kolumner, dess bredd och hur bred sidan ska vara i sin helhet. Dessutom kan man välja att hantera rader på motsvarande sätt, vilket helt enkelt roterar gridden 90 grader.

Den klassiska gridden, som man kan se i Photoshop finns också att tillgå. Där kan man välja griddstorlek och hur förhållandet mellan tjocka och tunna linjer ska vara.

Smidig hantering av sidor

Sketch är byggt med webben i åtanke. Därför har programmet en enkel, men ack så användbar, sidhantering. I det övre vänstra hörnet av arbetsytan finns en dropdown-meny som låter dig växla mellan de sidor som utgör ditt arbetsdokument. Det går att duplicera, döpa om och ändra ordning på sidorna.

När man är klar med sitt arbete kan man exportera alla sidor till ett PDF-dokument. Här skulle det dock behövas lite fler inställningar för att  det dokumentet ska fungera perfekt. De exporterade bilderna blir nämligen något stora om man har sin PDF-läsare ”utzoomad”.

Enklare verktyg för att kombinera objekt

I Illustrator finns ett bra verktyg som (åtminstone i min engelska version) heter Pathfinder. Där kan du skapa nya former genom att kobminera banor (paths) från två objekt, låta formen av det ena objektet bilda ett hål i det andra, osv.

Samma funktionalitet finns också i Sketch, fast den är enklare att jobba med. Här kan man nämligen redigera förhållandet mellan objekten efter att man har kombinerat dem.

När man använder verktyget i Sketch bildas det en grupp av de objekt man arbetar med. Gruppen bildar det nya objektet, men om man öppnar gruppen kan man fortfarande komma åt orginalobjekten. Man kan också i efterhand lägga till fler objekt i gruppen.

Om jag ska förtydliga med ett exempel kan du alltså skapa en fyrkant med ett hål i (visst låter det snyggt?) och sedan i efterhand redigera hålet eftersom det bara består av en cirkel. Du kan flytta, ändra storlek på det och lägga till flera hål genom att dra in fler objekt i den grupp som har skapats.

Är allt verkligen bra?

Nej, det finns en hel del som behöver förbättras i programmet. Det händer tämligen ofta att programmet kraschar. Av vad jag har märkt är det när allt för stora och många pixelbaserade bilder kommer in i dokumentet som det blir riktigt tungrott. Många gånger har jag tackat Apple för Mountain Lions fina autosparfunktion som låter mig fortsätta jobba där jag var, trots att Sketch har kraschat.

Det som dock är härligt med Sketch är att de ofta uppdaterar programmet. Den senaste tiden har uppdateringar kommit ut ett par gånger per vecka, vilket ger mig känslan av att de jobbar aktivt med att förbättra programmet.

För de som designar för webben är Adobes programserie Creative Suite troligen vardagsmat. Vi är många som har spenderat massor av timmar i InDesign, Illustrator och kanske framför allt Photoshop.

För egen del har det ofta handlat om just Photoshop, ett oerhört kraftfullt och kompetent bildbehandlingsprogram som få designers kommer att kunna växa ur. Utöver själva programmet är en rejäl fördel med Photoshop det stora antalet användare som har genererat mängder av templates, tutorials och fantastiska tillägg. Photoshops kraft och kompetens har lockat många – allt från webbdesigners till fotografer och konstnärer. Men varför är det så? Behöver alla samma funktionalitet? Behöver vi som ska designa webbsidor verkligen kunna lägga på ett sepia-filter eller simulera linsoskärpa på vår ”kontakta oss”-knapp? Svaret är naturligtvis nej.

Dessa funderingar fick mig att se mig om efter alternativ. Ett intressant sådant är programmet Sketch.

Vad är Sketch?

Sketch är ett vektorbaserat bildbehandlingsprogram för Mac med fokus på webbdesign. Funktionaliteten är ganska begränsad, men ofta räcker det. Många gånger handlar själva designfasen om att formge enklare element, som knappar och typografi. Mycket av det kodar man senare upp i ren CSS – och det är just kopplingen till CSS som är Sketchs ess i rockärmen.

Låt säga att du ska designa en knapp. I Photoshop brukar man då jobba med lagereffekter för att bland annat skapa skuggor och gradienter. Motsvarande funktionalitet finns i Sketch, fast i ett begränsat utförande. Här är de flesta av effekterna begränsade till vad man kan göra i ren CSS. Det betyder att mycket av designen går att koda istället för att spara ut som bilder.

Jag tänkte lista några funktioner som gör Sketch extra intressant.

Export till CSS

En funktion som har fått viss upmärksamhet är möjligheten att hämta själva CSS-koden från de element man har skapat. Som jag skrev så matchar mycket av det man gör befintlig funktionalitet hos CSS och ett snyggt funktion är att man kan högerklicka på ett element och välja menyalternativet ”Copy CSS Attributes”. Detta funkar ganska bra, men jag saknar exportmöjlighet till SASS.

Exportera retinaanpassade bilder

I Sketch jobbar man med vektorgrafik och en smart funktion som utnyttjar det är möjligheten att exportera bilder som är retinaanpassade. När det är dags att spara ett element i PNG-format finns en checkbox med alternativet ”Export @2x version”. Med det alternativet valt sparar Sketch ut två bilder – en vanlig och en i dubbel storlek.

Stilmallar för typografi

När man skriver text i Sketch så kan man tilldela den texten olika stilmallar. Detta enkla, men geniala knep gör att man snabbt kan definiera rubriker, brödtext och annan text. Om man sedan vill byta utseende på sina rubriker behöver man bara göra det på ett ställe, sen slår det igenom överallt.

På tal om typografi så kan det vara värt att nämna att renderingen av typsnitt i Sketch utklassar den i Photoshop. Detta genom den enkla detaljen att det faktiskt ser ut som det gör i webbläsaren. Typografin har länge varit dålig i Photoshop och det känns skönt att Sketch inte har samma problem.

Slutsats

Sketch känns som en kaxig uppstickare och på många områden är det en värdig utmanare till Photoshop, på vissa är det till och med bättre. Det är kul att jobba i ett program som fokuserar på webben. Att sidmallarna är anpassade efter mobiltelefoner och surfplattor gör att valet mellan pappersformat (A3, A4, osv.) i Photoshop känns förlegad. Programmet har fortfarande en del buggar och barnsjukdomar, men det är likväl en fröjd att arbeta i det.

Det är kul när det dyker upp utmanare till jätten Adobe, ett företag som egentligen inte borde ligga mig så varmt om hjärtat med tveksamma lösningar som Business Catalyst och Dreamweaver i katalogen.

Sketch är ett bra program, men det klarar inte av allt. Mycket av det som gör en bra webbsida är ett snyggt och genomarbetat bildmaterial. Här kommer Adobe troligtvis behålla ledartröjan ett bra tag framöver, även om uppstickaren Pixelmator kan vara värt att kika på.

En viktig faktor, som åtminstone kan tilltala småföretagare och privatpersoner är priset. Istället för de 6000 kr som man får pröjsa för Photoshop betalar man ungefär 300 kr. För den som vill testa programmet finns en kostnadsfri version att köra i 30 dagar. Den kan du ladda ner här.

Sajterna vi bygger innehåller ofta en slider av något slag. Vi brukar mestadels använda oss av bxSlider som är ett väldigt enkelt och smidigt jQuery-plugin. bxSlider tillåter en hel del anpassningar och kan ha slides med olika typer av innehåll, vilket är väldigt trevligt.

Ett av våra nuvarande projekt har dock haft krav som går bortom bxSlider. Projektet består av att utveckla en slideshow med bilder som ska stå och snurra på sju iPads sittandes på en vägg. Varje iPad ska ha olika bilder men övergångarna i de olika bildspelen ska vara synkroniserade.

Kunden vill att man för varje bild ska kunna ställa in hur länge bilden visas samt vilken övergångseffekt som visas när nästa bild kommer. Det var dessa två krav som gjorde att bxSlider föll bort.

Vid lite letande fann jag ett antal premium-jQuery-plugin som möjligtvis löste vad vi var ute efter. Men att köpa ett sådant script känns lite som att köpa en såndär gris i en påse som folk brukar prata om. Jag valde att leta vidare.

jQuery Cycle kan anpassas till många behov

Till slut fann jag pluginet som kom till min undsättning. Pluginet heter jQuery Cycle och är ett väldigt anpassningsbart skript skrivet av en kille som kallar sig @malsup. Författaren började med pluginet redan år 2007 men är fortfarande aktiv med utvecklingen. Senaste versionen kom den 26 oktober i år.

För våra krav med inställningar per slide har Cycle ett par passande attribut att skicka med till konstruktorn.

• ‘fx’: Bestämmer vilken effekt som ska användas för bildövergångar. Anger man en kommaseparerad lista kan man bestämma övergången för varje enskild bild.
• ‘timeoutFn’: Attributet ‘timeout‘ används för att ange hur många millisekunder varje bild ska visas om alla bilder visas lika länge. Med ‘timeoutFn‘ skickar man en callbackfunktion som har hand om att returnera det antal millisekunder som gäller för aktuell bild.

I vårt fall blev lösningen som följer nedan. Vi gjorde en enkel array som innehåller timeout och övergång för varje slide så att vi lätt kan komma åt att ändra inställningarna efter kundens önskemål.

Som du ser skickar vi med de olika övergångarna som en kommaseparerad sträng med attributet fx medan timeouts sköts av timeoutFn.

Det här visar en bråkdel av alla anpassningar man kan göra med jQuery Cycle. Ska du ha en slider med lite speciella funktioner eller avancerade övergångar rekommenderar jag att kolla in dokumentationen för att se om Cycle passar dina behov.

David Batra döpte sin bok om arga lappar till ”Den som inte tar bort luddet ska dö!”. I min tvättstuga finns en arg lapp med versal text om hur otrevlig man är som människa om man inte gör rent torktumlaren efter sig. Luddet är onekligen ett laddat ämne.

Något som kan vara ännu värre är commits till ett projekt där koden faktiskt inte validerar. I projekt där kodbasen är interpreterad, istället för kompilerad, kan det var så illa att man skickar upp otestad kod till produktionsservern och eventuell får sajten att krascha. Den passerar ju inte kompilatorfiltret, som har en scanner och parser.

Därför vill jag berätta för dig som använder git om hur du ser till att du bara skickar in kod som validerar. Nu är det inte så enkelt att koden passerar ett filter, som rättar till eventuella fel, så lite jobb får du göra själv.

JSHint validerar dina JavaScript

Först börjar vi med att välja våra verktyg som ska kontrollera koden. Det finns en uppsjö specifika verktyg för olika språk. Jag väljer att gå igenom JavaScript. För JavaScript finns det gudomliga JSHint. Det är baserat på JSLint, som är skrivet av Douglas Crockford. Dock lyckas inte ens Douglas själv skriva kod som godkänns av JSLint (påstås det). Därmed är JSHint ett bättre val. Några andra anledningar är att det tar hänsyn till mer kontroversiella design patterns och att olika utvecklare har olika stilar.

JSHint är ett paket till Node.js. Därför krävs det att du har Node.js installerat för att kunna använda JSHint. Om du, som jag, kör ett UNIX-baserat operativsystem installerar du JSHint med pakethanteraren npm:

$ sudo npm install -g jshint

Går allt vägen har du nu jshint tillgängligt som en vanlig binär. Testa att analysera ett script (ex. app.js) med

$ jshint app.js

Kontrollera automatiskt vid commit

Så, nu har vi verktyget, men inte metoden. Det vi utnyttjar hos git är så kallade hooks. Vi väljer att skapa ett script som körs vid varje commit. Om något fel skulle uppstå i scriptet använder vi ett returvärde som är skiljt från noll. I roten av ditt versionshanterade projekt har du en sökväg som heter .git/hooks/. Om du kikar i den ser du att det finns några exempel-filer där.

Starta upp din favoriteditor och skapa följande script.

Spara det sedan i .git/hooks/ med namnet pre-commit och gör det exekverbart:

$ chmod a+x .git/hooks/pre-commit

Testa nu att modifiera ett JavaScript, lägga till det och gör en commit. Om allt är rätt ska du se ett meddelande i stil med detta i konsolen:

Det innebär att dina JavaScript validerar! I annat fall stoppas commit-processen och du får rätta till felen:

Alltså, JSHint validerar dina script och bestämmer huruvida du ska får göra en commit eller ej.

Anpassa din validering

I vissa fall vill du exkludera vissa filer från validering. Exempelvis genererar UglifyJS kod som inte släpps igenom. Däremot fungerar koden utmärkt i browsers och därmed vill vi skicka upp den ändå. Hur du gör sådana inställningar finns i JSHints dokumentation.

Nu är det bara att skapa hooks för dina favoritspråk och smyga in på dina kollegors datorer. Nästa steg är att fixa torktumlarna.

I måndags deltog vi i WordCamp Stockholm. En av föreläsningarna som jag uppskattade mest var Jonas Lejons om optimering av WordPress-sajter. Här handlade det inte om att installera några kända plugins, utan att anpassa din server och den kodbas du redan använder till sajten.

Jonas pratade om verktyget Xdebug som mäter kostnaden för alla funktionsanrop vid en session, loggar det och låter dig som användare analysera resultatet. När jag kom tillbaka från Stockholm bestämde jag mig för att utreda en långsam WordPres-sajt som vi aldrig riktigt har hittat roten till problemet med.

Kort om Xdebug

Innan vi hittar roten till all ondska (i den här sajtens värld) vill jag berätta snabbt vad Xdebug är. Det är ett verktyg som erbjuder debbuging och profiling av PHP-script. Informationen som den ger är kostnad för varje funktionsanrop (som även går att spåra via call stack), information om minnesallokering och eventuella eviga loopar.

Xdebug körs serverside i någon lämplig UNIX-miljö eller under Windows. Du måste därför ha tillgång till ett shell på servern. De flesta webbhotellen med shared hosting erbjuder inte något sådant, utan detta verktyg kräver sin dedikerade server.

Problem

Problemet du har är att din sajt laddar långsamt. Du bestämmer dig då för att undersöka vad orsaken är. Ett sätt att testa är genom att inaktivera din WordPress-installations tillägg, ett efter ett. Det här är en enkel lösning, som inte ger så uttömmande information om det egentliga problemet. Vore det inte då bättre att gå till botten med orsaken med problemet och till och med ha möjlighet att rapportera en eventuell bugg till tilläggets författare?

Installera och konfigurera

Istället bestämmer du för att att testa Xdebug. Ladda hem och installera det på din server med PECL: pecl install xdebug

Redigera sedan din php-konfiguration. I vårt fall kör vi Apache som webbserver i en Debian-miljö. Därför är sökvägen till filen /etc/php5/apache2/php.ini. Lägg till inställningarna nedan och starta sedan om Apache.

zend_extension="/usr/lib/php5/20090626/xdebug.so"
xdebug.profiler_enable=0

När PHP nu körs, vid en sidladdning, skriver Xdebug till loggfiler i sökvägen med temporära filer (/tmp i Debian). Varje request från en klient skrivs till en separat fil.

Analysera

Det är dags att analysera filerna. Jag använder Webgrind, som är ett webbaserat verktyg. Det finns program som kan köras lokalt på vilken dator som helst. Fördelen med Webgrind är att du inte behöver ladda ned logg-filerna, utan kan analysera så fort en skrivning har gjorts.

Webgrind installerar du genom att hämta hem filerna som finns i git-repositoryn på GitHub, https://github.com/jokkedk/webgrind. Lägg dem i valfri sökväg och peka en vhost i Apache på denna. Sen är det bara att surfa in på vhosten med valfri webbläsare. Webgrind känner själv av var filerna sparas (sökvägen för temporära filer) och låter dig välja vilken logg-fil du vill ha informationen från.

När du har valt logg-filen renderas en tabell med alla funktioner som kallas. Kolumnen ”Total Inclusive Cost” är den som är mest intressant. Genom att sortera raderna med avseende på den kan du se vilket funktionsanrop som har tagit längst tid på sig. Klicka på anropet för att länkas längre ned i call stacken. Till slut når du en fil eller ett funktionsnamn som förmodligen har betydligt högre värde än alla andra. Där är boven i dramat.

Åtgärda

Om du förstår vad problemet är och hur det åtgärdas är det nog bara att vidta åtgärder. Är det ett tillägg som trilskas kan det vara lämpligt att kontakta författaren av det. Vad de vanligaste felen för WordPress är vet jag inte, men jag kan tänka mig att många plugins kör funktioner utanför hookar och istället direkt vid initieringsfasen. Det kan vara förödande.

Slutord

Xdebug är alltså verktyget för dig som inte bara vill veta att, utan även varför och hur, din sajt kan optimeras. Ge det ett försök när du får chansen och hojta om du har några frågor.

I skrivande stund håller vi på med ett nytt och spännande projekt. Efter en tid av planering och tolkning av kravspecifikation är det dags att börja bygga en sajt. Det första vi brukar göra är att skapa wireframes som ska beskriva sajtens huvudsakliga strukur och flöde. Till detta brukar vi använda Apples presentationsprogram Keynote.

Varje gång det är dags för wireframes brukar jag ta en titt på vilka andra program man kan använda för detta ändamål. Men trots att alternativen är många så brukar jag alltid komma tillbaka till Keynote. Jag ska förklara varför.

Min filosofi  när jag utför denna typ av aktivitet är att använda de verktyg jag behärskar. Skapandet av wireframes ska vara en enkel process i avseendet att strukturera layouten för sajten. Energin ska istället spenderas på att fundera, diskutera och resonera. Hur ska strukturen se ut? Finns det ett naturligt flöde när man navigerar på sidan? Hur påverkas element av eventuell responsivitet? Därför finns det en stor anledning att använda program som man är van vid och där man snabbt kan producera ett resultat.

Bra funktioner i Keynote

Det finns några bra funktioner som gör skapandet av wireframe enklare. De sitter inte särskilt djupt under huven, men väcker ändå en “aha”-upplevelse när man använder dessa för wireframes.

Länkning

I Keynote kan man låta element fungera som länkar. Man kan välja att länka till en annan slide, ett annat dokument, en webbsida eller en e-postlänk. Vi brukar använda detta för att illustrera knappar. Rita ut en knapp och markera den. Klicka sedan på Inspector och sedan på fliken Hyperlink Inspector. Där finns en lista med alternativ för länkning.

Utnyttja Master Slides

Ovanför listan över slides i Keynote finns dokumentets master slides, alltså de mallsidor som man utgår från när man skapar nya slides i presentationen. Det fina här är att dessa är redigerbara och att materialet på dessa slides är låsta när man redigerar sina vanliga slides. Detta brukar vi utnyttja genom att exempelvis ha bilden som representerar webbläsarfönstret eller mobilenheten utplacerade i en master slide. Har man andra element som är genomgående för alla sidor, till exempel en meny, är dessa också lämpliga att lägga in i master slides.

Keynotes fina copy-paste-funktion

När du kopierar ett element i Keynote och klistrar in den på en annan slide, kommer den automatiskt att hamna på samma koordinater som på den kopierades ifrån. Detta adderar ytterligare till smidigheten, då man kan skapa puffar och knappar som man med enkel copy-paste kan få ut på exakt samma ställe i alla slides.

Exportmöjligheterna

I Keynote finns också möjligheten att exportera dokumenten till Powerpoint och som PDF, två format som täcker de flesta behov. Många av alternativen ger också möjligheten att exportera till fullt fungerande HTML, vilket hade varit smidigt vid delning. Dock sitter hela Webbgaraget i samma miljö, som tillsammans med Dropbox täcker detta behov.

Alternativen

Det finns en hel drös med alternativ som man kan kolla in. Det som är gemensamt för de flesta av dessa program är att de är mycket kraftfullare än Keynote – något som jag är kluven inför. Det man ofta ser är att tillverkare skryter med en gedigen lista av features och har den inställningen att ju fler funktioner desto bättre program. Jag tycker inte att detta stämmer, då wireframes ska vara enkla. För program att skapa wireframes med borde devisen vara ju enklare det är att jobba i programmet, desto bättre. Man bör se papper och penna som måttstocken när det gäller användbarhet.

Oavsett detta så finns det en hel del intressanta alternativ att kolla in.

• Prototyper finns i både gratis- och betalversion, där skillnaden framför allt är längden på listan med features. Programmet är relativt lättanvänt och det är lätt att komma igång med förvalda templates för olika enheter
• Just Proto är programmet som satsar på kollaboration mellan flera användare. När man är klar kan man dela dokumentet som en fullt fungerande HTML-prototyp. Programmet är webbaserat, men trots det ganska kraftfullt. Personligen tycker jag att det finns lite väl mycket funktionalitet. Behöver jag verkligen sätta border radius och skugga på knapparna i ett wireframe?
• Framebox är något enklare än Just Proto. Programmet är också webbaserat och låter dig börja jobba direkt. Här är det enkelt att dela en länk till sitt projekt, vilket gör det enklare att få snabb feedback på en tanke, än exempelvis Keynote.

Prova dig fram och hitta det verktyg som passar dig bäst. Dock har jag en förhållningsregel som du kan tillämpa – om du börjar snegla på pennan och pappret när du jobbar så är det dags att byta program.

Igår hade vi ett litet dagshackathon där vi satte oss och slängde ihop en tjänst för Uppsalas cyklister: Cykelstaden Uppsala. Tjänsten visar publika cykelpumpar och verkstäder på en karta så att vi cyklister snabbt kan pumpa däcken eller laga cykeln om punkteringen är framme.

Vi använder oss av Google Maps API v3 för att ladda in karta och placera ut markörer för pumpar och verkstäder. Som backend har vi en WordPress-installation med en custom post type för Platser som är kategoriserad med taxonomin Type.

Vår man med estetisk ådra tycker inte om grundutförandet i Google Maps. Färgerna är helt enkelt för dassiga. Tur då att API:t låter oss förändra färgpaletten! Med Googles Styled Maps Wizard kunde vi sitta och laborera med alla olika färger på kartan. När vi (Andreas) var nöjda fick vi ett JSON-objekt som skickas med i kartinställningarna.

Så här initaliserar vi kartan på Cykelstaden. På rad 5-10 ser du JSON-objektet som modifierar kartans stil:

self.map = new google.maps.Map(mapCanvas, {
	center: self.mapCenter, // (En google.maps.LatLng med besökarens position)
	zoom: 15,
	mapTypeId: google.maps.MapTypeId.ROADMAP,
	styles: [{
		"stylers": [
			{ "gamma": 0.6 },
			{ "saturation": 30 }
		]
	}]
});

Kika gärna in på Cykelstaden och kom med ett bu eller ett bä!

För inte så längesedan blev det klart att ytterligare en funktion skulle läggas till i PHP v5.5. Den här funktionen var föreslagen av  utvecklaren ircmaxell och behandlade problemet med att generera lösenord i PHP. Vi har alla någon gång (och ibland flera gånger för mycket) skrivit en funktion för att generera ett säkert lösenord.

Betydelsen av ”säkert” i mitt fall var först inget alls. Sedan upptäckte jag envängskryptering med MD5-algoritmen. Sedan läste jag lite om saltning. Vidare tog jag baby-steps, för att slutligen landa hos bcrypt. Turligt nog fanns det färdiga implementeringar av algoritmen i PHP, så jag slapp lära mig den själv. Men som du märker var mina lösenord i början långt från säkra och jag kan vara glad att mina sårbara algoritmer inte användes på känsliga sajter som LinkedIn.

Det här förslaget från ircmaxell var på funktioner för att generera och validera lösenord, med en given algoritm. Äntligen ett inbyggt stöd i PHP med andra ord! När v5.5 släpps kan du kasta bort dina hembyggda funktioner och faktiskt förlita dig på de färdiga. Redan idag finns funktioner för att skapa en hash utifrån givet lösenord. Dock finns ingen generell valideringfunktion och de färdiga funktionerna saknar parameterar för salt och kostnad.

För att generera en hash med Bcrypt-algorithmen använder du password_hash($password, $algorithm):

$password = password_hash('foo bar', PASSWORD_BCRYPT);

Spara sedan $password för användaren i din väl valda databas. När användaren sedan ska logga in igen verifierar du att den har angivit rätt lösenord med password_verify($password, $hash):

<?php

$valid_password = password_verify($input_password, $password_from_$db);

if ($valid_password)
{
    echo "Rätt lösenord!";
}
else
{
    echo "Fel lösenord! Försök igen.";
}

Svårare än så kommer det alltså inte vara. Salt och eventuell beräkningskostnad kommer automatiskt och mina små trevande steg i början kommer vara ett minne blott.

Vill du veta mer föreslår jag att du läser RFC:n hos PHP.net.
Om du är nyfiken på vad mer som kommer i PHP 5.5 kan du ta en kik på nikics blogg: What PHP 5.5 might look like.

Webbsajter är numera allt mer beroende av JavaScript för sin funktionalitet. Oftast är det olika typer av moduler som är beroende av varandra. Kikar man på webbappar är de mer komplexa där bibliotek som jQuery, Backbone och Underscore används. Eftersom det finns ett beroende mellan dina egna script och de här modulerna, är det viktigt att de inkluderas i rätt ordning. Hur vore det med en lösning lättare än att ange varje script-tagg på rätt plats i head-scopet?

Vi löser det med RequireJS

RequireJS är ett bibliotek som låter din webbsajt ladda filer efter deras beroenden (Asynchronous Module Loading). Hängde du med? Vi exemplifierar det. Låt säga att vi har modulerna A.js och B.js, som används av app.js. I normala fall hade head-scopet sett ut såhär:

<script type="text/javascript" src="lib/A.js"></script>
<script type="text/javascript" src="lib/B.js"></script>
<script type="text/javascript" src="app.js"></script>

Besökarens browser laddar dem i tur och ordning. Allt bra. Men vad händer om du blandar in C.js, som B är beroende av? Jo, lägg det på rätt plats – innan B. Vi kan dock lösa det här lättare med RequireJS. Låt app.js se ut såhär:

require(["lib/A", "lib/B"], function(A, B)
{
   // App.js kod
});

require()laddar nu A.js och B.js, eftersom vi har definierat att app.js är beroende av dem. Ifall de returnerar något får vi returvärdet i parametrarna A och B. Själva appen (app.js) skriver vi i scopet för den anonyma callbackfunktionen. Vi är här garanterade att modulerna har laddats innan vi kör app.js. Det enda vi behöver lägga in i vår HTML-vy är taggen som laddar RequireJS:

<script type="text/javascript" src="lib/require.min.js" data-main="app.js"></script>

Men B var ju beroende av modulen C. Javisst, det löser vi såhär:

define(function(C)
{
   // B.js kod
   return B; // Returnera en handle som kan används av beroende moduler
});

Men vad är Asynchronous Module Loading?

AMD, som det förkortas, är ett format som gör det möjljigt att definiera beroenden mellan filer och moduler och låta dem laddas asynkront, som jag tidigare skrev om. Det har sitt ursprung i Dojos metod för att ladda filer via XHR och eval(), istället för att låta utvecklaren skriva script-taggar. Men eval() är som bekant evil och AMDs arbetsgrupp ville även att varje modul skulle ha sitt eget namespace.

Det finns två viktiga metoder i AMD: define() och require(). Det är allt du behöver hålla reda på. Lätt va?

Mer om AMD

Har det här lockat dig till att börja använda AMD i projekten? Läs isåfall mer om AMDs specifikation. Sedan går du vidare med en längre förklaring om varför du ska använda det i Addy Osmanis artikel Writing Modular JavaScript With AMD, CommonJS & ES Harmony. Slutligen laddar du ner RequireJS och tar en crash-course.