Fibrer

Tips för att lära sig Javascript

Fick en fråga om jag kunde rekommendera en bra kurs för att lära sig Javascript. Det kunde jag jag inte, men jag hade i alla fall lite tips:

Till att börja med är Javascript ett lite speciellt språk. Jag rekommenderar att man lär sig dess förutsättningar; som t ex att språket använder prototypiskt arv snarare än klassbaserat och att de har lite speciella regler för scope – globalt och lokalt plus closures.

Där är mitt bästa tips att se de föreläsningar Douglas Crockford hållit. Det finns ett gäng videoupptagningar. Börja med An Inconvenient API (tre delar) och fortsätt med Advanced Javascript (också tre delar).

Crockford har också skrivit en bok; Javascript: The Good Parts. Har inte läst den själv men Svante rekommenderar den; dock innehåller den inte så mycket som inte tas upp i hans föreläsningar.

Sedan använder man sig ofta av något slags bibliotek för Ajax. Det jag tycker är bäst är jQuery och då rekommenderar jag Peepcodes kurs i form av en film/screencast, Meet jQuery.

(Foto Franco Folini under Creative Commons-licens.)

Ray Ozzie: Google Wave är för komplext och går därmed stick i stäv mot webben

Har ännu inte sett introduktionen av Google Wave men är på förhand lätt skeptisk till satsningen.

Visst, det jag snappat upp är inspirerande och det verkar onekligen fiffigt, men vi har sett mycket fiffiga grejer genom åren och bara för att det är fiffigt betyder det inte att den stora massan kommer ta det till sig. Även om man är så stor som Google. Och något som Google Wave står och faller med just det.

Det Microsofts Ray Ozzie säger i det korta klippet ovan förefaller tänkvärt. Nämn något på nätet som fått genomslag och som bygger på komplex teknik!

Det gamla vanliga in och ut

37 signals skriver om sin interna applikation In/Out som är till för att alla inom företaget skall kunna hålla reda på vad som händer under dagen. Den skall förmodligen integreras en aning i Backpack framöver.

Jag tycker personligen att det verkar lite overkill att ha en applikation för det i dagens situation med alla fina tredjepartsverktyg (t.ex. Twitter & Jaiku) som finns idag.

I min värld skulle en "in/ut-applikation" kunna bestå av t.ex. ett twitter-konto som bara har mina arbetskamrater som kontakter och twitterriffic igång. Eller rent av en webbsida med teamets twitter-strömmar i olika div:ar rätt och slätt.

Men jag skall inte sticka under stol med att jag är lite nyfiken på hur det skall implementeras i Backpack, som är ett av de verktyg jag använder mest idag.

Det skall tilläggas att jag i dagens läge jobbar i ett så litet arbetslag att iChat räcker som kommunikationsverktyg.

Foto av identity chris is och skyddat av en licens från Creative Commons.

OpenID för domäner

Bara dagar efter mitt sena anammande av OpenID kommer myOpenId for domains som gör det ännu smidigare att ha ett myOpenId att minnas.

Via ownyouridentity.com som fick sin info från notsorelevant.com.

Rättelse: Denna funktionalitet har tydligen funnits länge, bara att man inte hört talas om den.

Riktigt sent anammande av OpenID

Jag vet att alla har använt det i flera år nu, det är bara jag som inte riktigt har vågat ta steget, men idag skaffade jag mig ett OpenID som jag tror att jag kan komma ihåg, nämligen http://svante.adermark.se.

Jag snubblade på en postning på ownyouridentity.com och kände att det var dags. Den i sin tur hänvisade till en gammal guide för att delegera ett OpenID som jag följde.

Kort sammanfattat i fyra steg:

1. Skapade en sida på http://svante.adermark.se
2. Sajnade upp för ett openid på myopenid.com (http://adermark.myopenid.com/)
3. Lade in koden nedan i head-taggen på sidan på http://svante.adermark.se
4. Testade http://twitterwhere.com med mitt fräscha OpenID.

Kod:

<link rel="openid.server" href="http://www.myopenid.com/server">
<link rel="openid.delegate" href="http://adermark.myopenid.com/">

Fungerar som en dröm alltså, nu kanske jag äntligen kan känna motivation att implementera en OpenID-lösning någonstans också.

Tom Coates om Fire Eagle

Tom Coates presenterar Fire Eagle på konferensen ETech och ger i samma svep en checklista att kolla av om man utvecklar för webb 2008.

(Fast det börjar bli dags att använda ordet internet igen, för det handlar inte längre bara om webb.)

Tom har tre punkter.

1. Vi ska bygga tjänster som sträcker ut sina tentakler överallt dit nätet når. Fysiska apparater, ubiquitous computing, skrivbordsapplikationer, mobila applikationer, instant messaging, dashboard widgets. Se t ex tjänsten Jaiku, som förutom webbgränssnitt har mobilklient, gränsnitt via instant messaging och SMS, flera typer av applikationer via sitt API, import av flöden från andra tjänster osv.
2. Vi ska fungera väl ihop med andra. Inte vara en silo utan korsbefrukta, ansluta, inte göra det andra gör utan utnyttja dem i stället. Se t ex Flickr på vars API mängder av tjänster bygger, och som utnyttjar andra tjänster såsom Picnic för bildredigering och QOOP för papperskopior, fotoböcker, t-shirts osv.
3. Vi ska bidra med data så att andra tjänster blir bättre. Vi ska skapa och låta andra använda datat (och vice versa). Se Fire Eagle självt, vars syfte är att erbjuda möjligheten att lokalisera användare geografiskt till andra applikationer.

Det här är principer som enligt Tom Coates genomsyrat Fire Eagle-projektet.

Och det intressanta är att Fire Eagle nästan bara är API:er. Loggar du in i Fire Eagle är det enda du ser en karta och ett textfält så du kan säga var du är. Vet du inte att de uppgifterna kan användas (om du ger tillåtelse) av andra tjänster via Fire Eagles API så verkar tjänsten helt meningslös.

(Foto Ed Schipul under Creative Commons-licens.)

Webben 2.0, i din ficka

Om man vill anpassa sin webbaplikation för Apples iPhone eller iPod touch finns ett antal detaljer att beakta.

Utvecklarna på trawlr delar med sig av sina anteckningar från när de uppgraderade sin applikation.

Marc Love kör på en liknande metod.

En kille som kallar sig ctran påstår sig ha en fungerande simplistisk metod.

Hur man löser det är väl mest en filosofisk diskussion. Skall man använda MIME-typer för att sniffa webbläsare? Å andra sidan hanterar man ju WAP på det sättet utan att blinka, så det kanske inte är så konstigt.

Begränsningen som kommer med storlek är ändå ganska inspirerande, det är trevligt om man kan bygga gränsnsitt som ser bra ut i iPhone och alla andra webbläsare. Tumblr är ett bra exempel på det.

Vad det är? Det är mashup!

Jag gillar verkligen inte ordet ”mashup”.

Lyckligtvis kommer jag inte behöva leva med det.

För det kommer bli så vanligt att sajter bygger på andra sajters funktionalitet att en särskild etikett är överflödig.

Det har snackats om ”mashups” i ett par år. Senaste halvåret eller mer har det snackats om portabla sociala nätverk eller portabelt data.

För att skynda på döden av begreppet tänker jag kalla allt detta för ”mashup”.

Det är mashup när videoklipp från YouTube bäddas in i blogginlägg.

YouTube-spelaren är funktionaliteten och videoklippet är datat. Funktionalitet plus data brukar kallas objekt. Portabla objekt. Mashup!

Det är mashup när du prenumererar på ett RSS-flöde.

Då är det bara data. Ingen funktionalitet finns i RSS-flödet. Det är bara en ström med ”innehåll”, med beskrivande rubrik samt URL för innehållet, tidstämpel när det skapades och annan metadata.

Förutom att leverera blogginlägg till RSS-läsare används det allt oftare för att leverera data från webbappar till andra webbappar. Då är det ännu mer mashup! Mashup gånger två!

Det var två former av mashups. Men det finns mer där det kom ifrån!

Det är mashup med API:er!

API:er är som en dubbeldajm. Det finns två sorters. Eller, de är samma sak men från två olika håll.

API är en med webbmått mätt stenålders förkortning som utläses ”Application Program Interface”. Det betyder att – häpp! – funktionalitet (och data – häpp-häpp!) görs tillgänglig för andra program att använda. Mashup!

Vad menar jag menar med att det finns API:er från två olika håll? Jo!

1. Först har vi den varianten där en webbapp utnyttjar funktionalitet och data från en annan webbapp via dess API. Tänk webbapp som utnyttjar Google Maps – mer än att bara bädda in en karta. Mashup!
2. Sedan finns den omvända, där man i praktiken gör data och funktioner i sin egen webbapp tillgänglig för en annan via ett API. Tänk FaceBook-app.

Hajar du? Från två olika håll?

FaceBook brukar man dock i det här sammanhanget tala om som ”en plattform”. Alltså lite som att FaceBook är ett operativsystem. Men jag kallar det: MASHUPSYSTEM! Mashup upphöjt till mashup!

Trodde du inte det kunde bli bättre så håll i dig nu!

En idé som ingår i det vi kallade webb 2.0 är att:

Hela webben blir en plattform!

Webbappar som bygger på andra webbappar. Data som flyter fritt mellan dessa. Widgets, flöden, portabla appar. Mashups här, mashups där.

Tänk dig en enarmad bandit där det rullar upp: MA! SH! UP! Ka-ching! Ka-ching! KA-CHING!

(Foto Todd Lappin under en Creative Commons-licens.)

Kvittra när du delar med dig av en bild

Äntligen kan man kombinera två av de webbappar jag mest frekvent utnyttjar på ett sätt som jag ofta gjort för hand innan. Skitch kan meddela via Twitter när du postar en bild.

De kallar det för MyTwitter och det går till så att vid postningstillfället klickar på på knappen Send to Twitter och skräddarsyr sitt kvitter som kommer med en tinyurl som pekar på din nyligen postade bild.

Här finnes en nedbrytning av det exakta förfarandet.

Genier runt lägerelden

Vi har automatiserat handhavandet av vår omåttligt populära fredagschatt och här är en kort genomgång av de teknologier vi utnyttjar för att få det att bli så smidigt.

• Ruby on Rails - En rails-applikation håller samman alla komponenter, lagrar information om tidigare sammankomster och ebjuder kommentarsmöjligheter. Dessutom kan intresserade anmäla sig innan chatt-tillfället och vid fler än fem anmälda kommer chatten att starta som planerat.
• Tinder - Ett ramverk/API som används av railsappen för att prata med Campfire. Vi har lagt till möjligheter att byta färg på en chatt till APIet.
• Mechanize - Används av ett script som uppdaterar en kopia av transcriptet på pågående chattar så att icke inloggade deltagare skall kunna följa vad som hänt.
• Jaiku och Twitter - Används för att meddela potentiella deltagare om hur prognosen för kommande chatt ser ut och vid start-tillfället av var chatt.
• crontab - Schemalagda jobb talar om för rails-appen att den skall starta och stoppa chatten samt meddela intressenter.

Foto av rolf_m.