Google friend connect börjar funka

Jaha, tänker du. Orka fatta vad det där är, liksom. OK, liten grundkurs i hur det fungerar:

1) OpenSocial.

OS är en standard (ett JavaScript API från börjna, men numera med REST access från lite grand vad du vill) för att skriva gadgets (som google kallar dom) / widgets (som resten av världen kallar dom) som ligger i webb-sidor hos 'sociala sajter', och hur dom interageras med dessa.

Ett exempel kan vara en gadget som visar ordspråk från olika länder beroende på vilket land den som kikar på sidan är ifrån. Gadgeten laddas (som en xml-fil med inbäddad JavaScript) från din server och visas som en del av sidan på den sociala sajten. Din JavaScript-kod anropar då andra OpenSocial JavaScript-funktioner som redan har laddats i sidan, som returnerar t.ex. lite information om den inloggade (i den sociala sajten) användare som kika på sidan.

Ditt JavaScript använder sedan vanlig Ajax för att hämta rätt text från din server, där ett litet server-script snurrar igång och bläddrar fram rätt sak ur din databas.

Den sociala sajtenkallas 'Container' på OpenSocial språk, och tanken är att om man har programmerat en gadget so m funkar för Plaxo, så funkar den percis likadant på LinkedIn, eller på Orkut, et.c.

2) Google Friend Connect

GFC är OpenSocial. Det är precis samma API, samma funktioner och så vidare. Den enda skillnaden på upplägget är att Containern är Internet. Eller det som GFC gör tillgängligt, vilket är ganska mycket samma sak.

Det innebär att du kan ta vilken sida som helst, t.ex. en på din webb-server, och länka in en GFC gadget. När sidan laddas kontrollerar gadgeten om den vet vem personen som ser den är, och kan annars visa en inloggnings-dialog, där man kan "Join"-a sajten. När man gör det så får man välja på vilken identitet man vill logga in med; Google Mail, Google blogspot, Yahoo, OpenID eller AOL.

Andra GFC gadgets man kan lägga in är en Wall gadget, med twitter-liknande funktionalitet, en Rating widget, där man kan sätta betyg på sidan, och så vidare. Alla gadgets sparar informationen på GFC servrarna, så ingen interaktion krävs eller hålls tillhanda med den webb-server som egentligen har själva sidan.

Låter det knasigt? det är det! :) Men det är också en enorm fördel att snabbt kunna få upp speciella gadgets på en sajt där man inte behöver hålla reda på in och utloggningm byte av lösenord, et.c. Dessutom är en central funktion i GFC att definiera vilka 'vänner' man har. Den listan, och all annan information (som användaren tillåter genom att joina sajten) kan man läsa och använda sig av i en egengjord GFC/OpenSocial gadget.

Nyligen så aktiverade Google möjligheten att skicka tillbaka såkallade "signed requests" till den server (eller någon annan för den delen) som sidan laddades ifrån, vilket innebär att GFC servrarna som hanterar all kommunikatioon tilloch från gadgets i sidan "stämplar" informationen med en kryptografiskt säker signatur. Det gör att din server kan få reda på ett unikt, garanterat id på alla som är inloggade i GFC på din sida.

Detta betyder i sin tur att du kan bygga en webb-tjänst där du inte behöver bry dig om användar- eller lösenordshantering, men ändå få ett unikt id för varje användare som du kan knyta till dina interna processer. Dessutom kan du se vilka vänner användaren har, och lite annat. Dock ej epostaddress, för närvarande, av säkerhetsskäl.

Jag har beskrivit hur detta går till en en annan post på min engeslkspråkiga blogg, som kan vara av intresse.
Lycka till och hör gärna av er om ni vill fråga om något!

Mvh,
PS

Håller Sverige på att falla efter när det gäller webbutveckling?

Sverige är ett av världens mest välutbildade länder. Enligt viss statistik, ligger vi på femte plats i världen på listan över antal utbildningsår per person.

Så välutbildade är vi. Trots det släpar vi efter vad gäller införandet, eller utvärderingen av nya teknologier. Från ett utvecklar- och arkitektperspektiv hamnar Sverige ganska långt ner på listan jämfört med omvärlden.

Ta en sådan sak som att utveckla intranät-applikationer. I nästan samtliga fall väljer man från projektledningen att använda antingen WebSphere eller Sharepoint (beroende på vilken kappa man har på sig), två lösningar med galet höga kostnader för implementation och underhåll.

De flesta företag och organisationer svars intranät jag har sett, har använt detta mer som en portal mot annat innehåll som redan finns i andra applikationer (förvisso inte alla med webb-gränssnitt), snarare än en platform för nya applikationer.

I samtliga fall skulle behoven kunnat mötas till en radikalt mindre kostnad genom att istället välja att implementera intranätet i en CMS plattform som Joomla, Drupal eller Wordpress. Samltiga är Open Source och kostar alltså hundratusentals kronor mindre än motsvarande lösningar från IBM eller Microsoft.

Men Sverige är helt enkelt inte hängt med i teknikutvecklingen. I stället för att göra rationella avvägningar som skulle kunna spara enorma pengar, väljer organisationerna att inte tänka och istället bestämma sig för en standardplattform, i den religiösa övertygelsen att det helt enkelt måste leda till mindra kostnader över tid.

Men CMS'er i all ära; ibland måste man nyutveckla, och tänker sig då att använda ett modernt gränssnitt som en webb-läsare till exempel. Givetvis väljer man ett server-baserat web-ramverk som det lättfotade JSF, eller nymodiga och hippa Struts (på Java-sidan), alternativt det svårkommenterade ASP.NET (i fallet Microsoft). Har man en riktigt tur så kanske projektet får lov att använda sig av Tapestry eller Spring. Dock har samtliga dessa ramverk brister som det finns lösningar för, och som används alltmer i länder utanför Sverige.

I höstas var jag hos Google i Mountain View och gjorde ett 'tech-talk' på ämnet Thin Server Architecture, där jag redogjorde för tekniker för att radikalt minska utvecklings- och underhållskostnaderna för webb-relaterade projekt. Grundidén är densamma som i RIA (fast RIA mest förknippas med Flash), och SOFEA (Service Oriented Front-End Architecture), det vill säga att erkänna den klient-funktionalitet som finns i browsern, och utforma projektet som ett client-server projekt, där en grupp har hand om klientern och en grupp om server.

Detta innebär att projektets två delar kan arbeta till stor del asynkront av varandra, med bieffekten att den design som gjörs i HTML/CSS och JavaScript kan användas oförändrat i applikationen, utan att behöva konverteras till server-side templates. TSA innebär helt enkelt att klienten skrivs med hjälp av moderna Ajax-ramverk som Dojo, YUI, ExtJS eller jQuery (mfl), och som använder Ajax-anrop för att enbart hämta och leverera data från och till server, genom ett REST-gränssnitt eller kanske genom att konsumera web tjänster rakt in i browsern (som är principen bakem SOFEA).

Den stora vinsten blir på server-sidan, där den gruppen helt kan fokusera på att implementera affärslogik och säkerhet, och där all form av rendering, templates och XML-filer för mappning mellan webb och logik helt kan släppas.

Detta kräver givetvis att det finns kompetenta Ajax/JavaScript experter i gruppen som leder front-end arbetet, men experter kommer man ju aldrig undan :) Det finns även ett antal RAD-verktyg som till skillnad mot Microsoft Visual Studio ger ifrån sig en ren, tvåskiktad client-server applikation, som ändå kan köras i en gängse appliaktionsserver. Eempel på dessa är WaveMaker, SmartClient och Mendix.

I de flesta fall räcker det nog att handjaga klienten. Och om man skall ändra något i utseendet, så påverkar det inte server, och om servern ändrar sin interna struktur, så behöver det inte märkas i klienten, så länge inte protokollet dem emellan rubbas.

Det är utveckling det!

Tyvärr just nu bara tillgänglig i utlandet :) Vilket årtionde som helst kanske Svenska företag och organisationer kommer ikapp. man kan ju bara hoppas..

Dagen Nyheter 19/2

1) Jag misslyckades med att konvertera den här raringen själv för ett år sedan ungefär. Däremot kom jag en bra bit på att porta originalet, Box2D, till Nintendo DS på ett halvapigt piratkort. Ja, det var tider det. Problemet med NDS var att all grafik som inte är sprites görs i 3D, vilket skojar till det lite extra. Nå, i vilket fall som helst så blev jag glad när jag såg att någon hade portat Box2D motorn till Actionscript, för då borde det inte vara så svårt att porta igen till JavaScript. Det var det. Jag är *mycket* glad att någon har orkat :) Det är alltså frågon om en 'realistisk' simulering i 2D av kroppars rörelse och interaktion. Perfekt för spel och visualiseringar av olika slag. http://box2d-js.sourceforge.net/index2.html

Det hade varit kul att skriva något mer, men inte i kväll. Dagen har lksom varit alldeles för rolig som det är, om ni förstår vad jag menar. God natt!

10gen - en aldeles egen Google App Engine

Jag har följt 10gen projektet en längre tid. Det är intressant på många olika sätt. Det mest framträdande med det är att det till stor del fungerar som Google App Engine, d.v.s. det är en applikationsserver som låter dig skriva applikationer i ett modernt programmeringsspråk utan att behöva hantera otäcka detaljer.

Men det är mer än så. Där GAE endast stöder Python, stöder 10gen Python, Ruby och SSJS (Server-Side JavaScript). Där GAE är helt beroende av Google's infrastruktur för sitt datalager, öljer 10gen's hela datalagerimplementatio med i paketet (om man vill) färdig att driftas på vilken maskin som helst.

Fast det bästa är nog att både applikationsservern och datalagret är Gnu AGPL, open source så det svänger om det.

Men det finns ännu mer i paketet. 10gen har alltså en applikationsserver, den kallas Babble, som inkluderar captcha tjänster, Django stöd, och mycket annat. Utanför den finns en load-balancing demon som kallas lb, och tillsammans med datalagret Mongo, skapas en helt gratis service-stack som heter duga.

Kika till exempel på hur man gör för att skapa ett objekt som man sedan sparar i datalagret (i SSJS);


var j = { name: "mongo"};

db.things.save(j);


Det är allt. När jag börjar referera till db.xxx, så skapas (om det inte fins) en 'tabell' med xxx objekt. Eller det skapas en 'tabell' med objekt,
typer är ju som bekant oftast i vägen (enligt Amazon, i vilket fall). Känns lite mer hanterbart än Hibernate, eller?

Utvecklarna sitter i New York, men är väldigt närvarande, både på IRC och i mailing-listorna. Vl värt att kika på, om ni är nyfikna på Google App Engine,
men inte vill använda Python, eller tycker Python är OK men vill/måste kontrollera och äga tillgång till data.

Mvh,
PS

Dagen nyheter 18/2

1) Ny, maffig video som visar hur ofattbart hård Andriod G2 är;
http://feeds.gawker.com/~r/gizmodo/full/~3/CXZfT6JtiGY/android-g2-hands-on-close-to-perfection

2) Facebook gör bort sig, men ångrar sig. Som vanligt, och tur är väl det. Nyligen upptäcktes det att FB hade smygit in i användaravtalet att dom ansåg sig ha rätt att publicera material som användaren tagit bort från tjänsten. Sickna tomtar; http://rss.slashdot.org/~r/Slashdot/slashdot/~3/zkMipHQZ0TI/article.pl

3) Joose släpptes nyligen i version 2.0. Joose är Malte Ubl's projekt som på kopierad engelska är "a self-hosting meta object system for JavaScript with support for classes, inheritance, mixins, traits, method modifiers and more. ". Det konkurerar inte med existerande JavaScript ramverk utan kan användas vid sidan av, för att integrera och underlätta; http://code.google.com/p/joose-js/

Dagens nyheter 16/2

De viktigaste nyheterna idag var;


1) Andra generationens Google Android-telefon kommer till Europa inom kort, tack var samarbete mellan HTC och Vodafone;
http://feeds.gawker.com/~r/gizmodo/full/~3/cuTDRcAlmqA/htc-magic-the-fabled-android-g2-looks-like-its-headed-to-vodafone-in-europe

2) Vansinnigt bra artikel på RWW som jämför relationsdatabaser med 'enklare' databaser som CouchDB, simpleDB och Google App Engine's datalager. Ett måste. D.v.s den måste läsas, inget att hoppa över;
http://feedproxy.google.com/~r/readwriteweb/~3/dg4TxhHcY28/is_the_relational_database_doomed.php

3) Lite sent kanske, men Dion, Ben och David på Mozilla Labs släppte i helgen en web baserad open source editor (gissa vilken licens :) i en ren Thin Server Architecture lösning, med en JavaScript-baserad front-end och både en Java och en Python back-end, så man kan välja (lätt att välja faktiskt.py) Tyvärr lite slö på Linux med standard Nvidia drivisar.
http://feeds.feedburner.com/~r/ajaxian/~3/538556606/bespin-a-new-mozilla-labs-experimental-extensible-code-editor-using-canvas

God natt,
PS

Ny industrustandard inom webbdesign

Idag finns det två olika typer av webb-projekt; De som drivs av designbyråer där gränssnitten först ritas som bilder och de som råkar bli till som ett resultat av en mer teknisk byrås funktionella krav. I båda fallen skapas gränssnittet i princip på nytt varje gång.

Visst, många uppdragsgivare utgår från en existerande webb-sajt i sin uppdragsbeksrivning, även om inte målet med övningen är att göra en exakt kopia. "Vi vill att profilen skall se ut lite grand som Facebook's", till exempel. Det är ju inget fel med det, utan i stället en fördel för projektdeltagare som ny har en mall till sitt förfogande.

Men det stora problemet är att det inte har funnits någon direkt 'industristandard' eller de facto standard för delar av webb-sidor coh typer av webb-sidor. Ofta behövs det inte, då de flesta vet vad som menas med ett träd eller en tabell, men ibland blir det knepigt och det kan bli lätt att tala förbi varandra. Hur ser t.ex. en dialog ut, och vad kan man göra med den?

Visserligen finns det en god mängd litteratur och forskning runt gränssnitt i allmänhet, och många paralleller kan hittas mellan klassiska program och tjänster som bor i en webb-sida, men från min i och för sig vinklade bakgrund (Jag har bara sysslat med webb-utveckling i tre-fyra år, efter att ha programmerat Java sedan 1998) så diskuteras det mest om CSS eller direkta problem med Internet Explorer (vilken ju skall sargas, så det säger jag inget om :) i webb-design kretsar, snarare än mer abstrakta element på lite högre nivå.

Anledningen till det kan ju vara att de där mer abstrakta elementen är det inte så mycket problem med, jämfört med t.ex. Internet Explorer. Hur det nu är med det så känner jag ibland att jag har saknat ett mer uttrycksfullt språk när jag har diskuterat med uppdragsgivare utan särskild teknisk kompetens i var knappar skall sitta och hur menyer skall fladdra. Det hade helt enkelt varit bra om det hade funnit någon semi-officell lista med komponenter och flöden som man kunde enas om utan att ramla ner i teknikaliteter. Jag fick faktiskt en direkt fråga för ett tag sedan om det inte fanns någon 'industri-standard' i webb design som man kunde luta sig mot gentemot kunder och uppdragsgivare.

Flamma gärna på om ni sitter inne på bättre information, men personligen så var den första gången jag riktigt kände att det 'klickade' var när jag läste Theresa Neils och Bill Scotts bok Designing Web Interfaces. Vad som är bäst med den boken är att dom helt prejudicerat bestämmer sig för att lista sina egna 12 eller 20 eller vad det nu kan vara abstraherade typer av saker som kan finnas på en webb-sida (eller sajt, för den delen).

De beskriver till exempel de 15 vanligast komponenttyperna; "Add another", "Build an expression", "Full Screen", et.c. Med denna abstrakta lista i tassen, helt separerad från specifikt Ajax-toolkit eller webramverk kan jag mycket lättare sitta ner och bolla idéer runt gränssnitt och funktionalitet med de icke-tekniska personer som till syvende och sist är mina uppdragsgivare.

Om ni arbetar med webb-utveckling och inte ännu har skaffat den här boken; gör det!

Jag har också skrivit en artikel på min engelskspråkiga blog, där jag visar hur man kan använda Ajax-ramverket Dojo för att implementera vissa patterns ur boken.