Of course we wanted to use PTB and CMS 6 for our new project. We went to work but soon discovered that something did not really work. When looking on our PageTypes in admin mode, some of them caused the UI to crash.

It turns out that the UI for CMS 6 (Admin/EditPageType.aspx) does not accept that the help text for any property is null which is the default value for it using PTB. A quick solution would be to change the EPiServer templates to take care and use an empty string when there is a null value. In practice this means:

Change line 81 in EditPageType.aspx from

<%# EPiServer.Core.LanguageManager.Instance.TranslateFallback("/pagetypes/common/property[@name='" + DataBinder.Eval(Container.DataItem, "Name") + "']/help”, DataBinder.Eval(Container.DataItem, “HelpText”).ToString())%>

to

<%# EPiServer.Core.LanguageManager.Instance.TranslateFallback("/pagetypes/common/property[@name='" + DataBinder.Eval(Container.DataItem, "Name") + "']/help”, DataBinder.Eval(Container.DataItem, “HelpText”) == null ? “” : DataBinder.Eval(Container.DataItem, “HelpText”).ToString())%>

but we do not know if CMS 6 will try to access help text anywhere else without checking for null. So we went on by changing PTB:

In the file

/Synchronization/PageTypePropertyUpdater.cs

in the method

CreateNewPageDefinition

we changed from

pageDefinition.HelpText = propertyDefinition.PageTypePropertyAttribute.HelpText;

to

pageDefinition.HelpText = propertyDefinition.PageTypePropertyAttribute.HelpText ?? "";

and in the method

UpdatePageDefinitionValues

we changed

pageDefinition.HelpText = propertyAttribute.HelpText;

to

pageDefinition.HelpText = propertyAttribute.HelpText ?? "";

Hopefully this will help someone. We will continue to post here if we run in to any other issue that could be of interest along the way.

So far we are very pleased with PTB and CMS 6 working together and we are looking forward to releasing some great sites using them.

Vad är då ett unit test och vad definierar ett bra sådant?

Ett unit test är en metod som testar vissa antaganden mot en annan klass eller metod. Ett exempel på ett enkelt unit test är följande.

Vi testar alltså om vår GetCityById metod returnerar null då vi skickar in ett negativt nummer som parameter. För att kunna skriva ett bra unit test måste vi dock först definiera vad som är ett integrationstest och vad som är ett unit test. Osheroves definition av ett unit test är:

• Snabbt
• I minnet
• Inga externa beroenden (mot filsystem, databaser etc.)
• Samma process
• Automatiserat
• Repeterbart
• Konsekvent

När vi nu vet vad ett unit test är, kan vi med fördel dela upp våra unit och integrationstester i olika namespaces eller projekt. Genom att göra en uppdelning av våra tester har vi sedan en klar bild över vilka av våra tester som har externa beroenden, och vilka som vi kan köra som unittests.

En viktig sak Roy nämner är vikten av att lita på sina tester. Litar man inte på dem och använder debuggern för att dubbelkolla förlorar testet sitt syfte. En av anledningarna till att man inte litar på sina tester kan vara att man inte delat upp sina tester och då har ett antal integrationstester som behöver viss konfiguration innan de passerar, men vanligast är att man helt enkelt känner att testerna inte riktigt går att lita på.

Så, hur kan jag börja lita på mina tester?

För att kunna lita på mina tester, måste jag lita på min egen förmåga att skriva bra test. För att göra detta gäller det att inte tumma på vare sig struktur eller läsbarhet. Roy har ett par bra tips när det gäller namngivning.

Ha en konsekvent namngivning på dina testmetoder. Gärna enligt [metodundertest]_[scenario]_[resultat], vilket bli extra tydligt om vi jämför metoderna AddNumber_LessThanZero_ThrowException() och AddNumber().

Man måste också se till att döpa sina variabler korrekt och att undvika Magic numbers. Om vi jämför en assert av typen Assert.AreEqual(-77,statuscode) med att använda en konstant/variabel MISSING_COUNTRY=-77, märker vi hur mycket läsbarheten ökar då vi istället får Assert.AreEqual(MISSING_COUNTRY,statuscode).

Med vackra ord, eller i det här fallet KONSTANTER och metodnamn, kommer man inte långt om testet i sig är inte känns stabilt. För att undvika problem i dina tester finns ett (stort) antal saker att hålla koll på, här är några av dem.

Endast ett test per metod, har du flera tester (asserts) i en metod bör du bryta ut dem till egna tester. Detta gäller dock inte om du skall testa flera properties i ett och samma objekt.
Undvik logik i dina tester, har du ett antal if-satser som styr logik i ditt test kan du troligtvis refaktorera dem till egna tester.
Repeterbarhet, undvik saker som gör att varje test blir unikt. Använd ett statiskt datum istället för DateTime.Now och håll dig långt borta från allt vad slumptal heter.

Summering

Detta var bara en liten del av det som togs upp under sessionen, vilken allt som allt var mycket lärorik, även om det traditionella gitarrspelandet uteblev (den var trasig). Kan även passa på att rekommendera boken ”The art of unit testing” där han går igenom ämnet unit testing mer ingående.

Veckan har bjudit på flera höjdpunkter men även några besvikelser då fokus legat på IT-infrastruktur och inte programmering och webbutveckling, vilket är Isotops huvudspår. Man hör ofta folk på TechEd säga att ”alla snackar om molnet”, men det är fel… sanningen är att alla snackar om Sharepoint 2010 och Exchange.

Några reflektioner från veckan på TechEd där temat var ”The new efficiency”:

David Chappelle hade en dragning om Windows Azure-platformen ur ett IT-strategiskt perspektiv där han försökte besvara frågorna – När, hur och varför man ska använda molnet? Microsoft planerar att släppa Azure i nästa vecka (19:e November) och funderingarna kring detta är många. Ett vanligt orosmoln från intressenter är säkerheten, vågar vi skicka upp vår känsliga data in i molnet? Microsoft har insett att plattformens pålitlighet är avgörande för att vinna kundernas förtroende. Det har i sin tur inneburit att de infört vissa begränsningar som förenklar systemet men ökar pålitligheten, t.ex. kommer databaser till en början ha en maxstorlek på 10 GB och lastbalanseringen sker via manuell konfigurering. Läs gärna mer om Windows Azure och molntekniken i Staffan Eketorps inlägg Moln i praktiken, del 1 och Moln i praktiken, del 2.

För den intresserade utvecklaren har Microsoft utlyst en tävling där man ska bygga molntjänster. Läs mer på http://wadc.cloudapp.net/

För oss vanliga dödliga finns det fortfarande ett alternativ till molnbaserad hosting. Windows Server 2008 R2 och IIS 7.5 kommer med några intressanta nya features, bl.a. Centralized Web Management som innebär att man kan styra en hostad IIS från en lokal klient. Microsoft har också tagit fram ett verktyg (IIS Web Deployment Tool) för att underlätta installationer direkt från IIS genom konfigurerade export/import-funktioner. Det mest intressanta måste ändå vara Web Platform som innebär färdiga paketinstallationer av bloggverktyg och CMS som Wordpress, Umbraco och DotNetNuke. Site Analysis Report är också en annan feature som gör att vi kan hämta ut rapporter om t.ex. sökbarheten/tillgänglighet på webbplatsen. Listan kan göras lång och det blir helt klart spännande att se hur EPiServer anammar denna miljö i kommande versioner av EPiServer CMS.

Visual Studio 2010 och .NET 4.0 har nyligen släppts som beta 2. En av de mer intressanta nyheterna i .NET 4.0 för utvecklare är Parallel Extensions som förenklar parallellisering av många vanliga programoperationer, t.ex. loopar och (P)LINQ.

IronPython och IronRuby är något som omnämns titt som tätt här på TechEd. Båda språken har fullt stöd i 4:ans DLR (Dynamic Language Runtime) och innebär helt klart intressanta möjligheter för den som inte känner sig hemma med C# eller övriga .NET-språk. Dynamiska språk öppnar en ny värld för utvecklare från andra miljöer, inlärningströskeln för t.ex. en Ruby-utvecklare blir minimal samtidigt som man exponeras för styrkorna i .NET Framework. IronPython och IronRuby kan säkert vara intressant i vissa specifika fall men i grund och botten så innebär det ännu inga prestandavinster jämfört med andra implementationer av språk , snarare så leder det generellt till sämre prestanda, vilket Harry Pierson påpekar under sessionen ”Pumping Iron”.

Veckan har bjudit på många inspirerande talare, sessioner och ämnen. Nu behöver dessa tankar landa innan vi lanserar vår första IronPython-applikation på molnet.

Läs gärna inlägget ”Tips för att snabba upp din webbplats” och ”Unit testing med Roy Osherove” som sammanfattar två enskilda föreläsningar från Microsoft  TechEd 2009 i Berlin.

Giorgio Sardo höll i sessionen som handlade om hur vi kan göra våra webb-2.0-applikationer och webbplatser snabbare. Fokuset låg helt på klientsidan och handlade till stor del om optimering av Javascript och DOM-operationer som står för 33% av CPU-förbrukningen för den genomsnittliga webbplatsen (övrig CPU går till rendering av innehållet).

Sessionen och talaren Giorgio Sardo, som är ”Technical Evangelist” på Microsoft Corporation, kanske var lite smått färgad av just Microsoft men framhöll ändå några intressanta synpunkter och fallgropar man bör tänka på när man utvecklar gränssnitt – oavsett plattform (oroa er inte, jag hade mina GOOGLES på mig).

Några vanliga fallgropar på klientsidan

• CSS - Långa selektorer drar prestanda. Håll dem korta och koncisa.
• CSS - Undvik CSS Expressions.
• JS - Undvik globala variabler om det går.
• JS - Undvik arv med prototyping. JS-motorn måste först leta igenom objektinstansens alla default-properties innan den kan söka vidare efter prototype-funktioner. Det drar prestanda.
• JS - Cacha get/set anropen till DOM genom temporär lagring i lokala variabler.
• JS - Precis som ovan så bör man även cacha återkommande funktionsanrop i lokala variabler.
• JS - Vid användning av setTimeout() bör funktionsanropet göras direkt och inte via en sträng. Strängar som skickas till setTimeout måste exekveras med eval() vilket leder till prestandaförluster.

  
  Exempel - vanligt förekommande:
  setTimeout(”testFunc()”,100);
function testFunc() {alert(’Hello world!’)}

  Exempel - rekommenderad användning:
  setTimeout(function(){testFunc()},100);
function testFunc() {alert(’Hello world!’)}

• JS - for-loopar blir snabbare om de utgår ifrån en lokal variabel med length-värdet istället för att gå direkt mot object.length.
• JS - Iterationer över DOM-element bör göras med while-loopar där nextSibling() styr iterationen. På detta sätt undviker man onödiga uppslagningar mot DOM-objekten.
• JS - IE 8 kommer med en native selector som (enligt Microsoft) går snabbare än jQuerys selector.
• JS - Konkatenering av strängar bör göras genom att pusha strängar till arrayer som i slutändan sammanfogas med join() istället för att addera (var1 + var2) strängar med varandra.

Några intressanta verktyg som togs upp under sessionen

Doloto

Doloto är ett verktyg för att optimera Javascript-filer, inte genom minifiering utan genom klustring av funktioner. Verktyget analyserar vilka funktioner som anropas i runtime och utifrån det resultatet så optimeras koden dels genom uteslutning av överflödig kod och dels genom lazy loading. Det huvudsakliga målet är att reducera väntetiden för en webbsida att laddas in.

Läs mer på http://msdn.microsoft.com/en-us/devlabs/ee423534.aspx

Expressions Web 3 + SuperPreview

Verktyg för att felsöka grafiska skillnader mellan olika versioner av IE(IE6  + IE7 eller IE8) och Firefox. Via en och samma vy kan man göra snabba visuella analyser över vad som skiljer sig åt mellan de olika webbläsarna.

Läs mer på http://blogs.msdn.com/xweb/

Some time ago, we faced the problem of building a little audio/video sequencer in Flash. With this sequencer the user would produce his/her own music video that was published on YouTube. As for video, there wasn’t much problems, but synchronizing audio turned out to be a real beast. Following the debate on Andre Michelle’s blog and http://www.make-some-noise.info/2008/04/01/response-to-a-bunch-of-questions-from-adobe/ Adobe hasn’t really been the Flash sound community’s dear friend recently. In short, they introduced severe bugs in Flash player 9.r115, but they changed the whole API for version Flash Player 10. With version 10 you can do really cool stuff writing directly to sound mixer buffers. In particular: see Hobnox’s Audiotool which is probably the coolest Flash application I’ve ever seen (ReBirth anyone? :-)).

Anyhow, unfortunately our project couldn’t go for Flash Player 10 as the market penetration wasn’t large enough. Even AS 3 was not an option due to platform restrictions. So, back to thinking in terms of the old API:s and playing around. The idea was for the user to click in a grid and play different samples, just like a beat box or drum machine. Furthermore, each sample had a video so, in effect, the user made a little video beat box loop. Ok, cool…but could we accomplish this?

After trying just naive Sound.play calls together with matching timer values from getTimer() and noticing quite large rythmic glitches I was disappointed. Clearly, we needed better timing information. But reading the article Advanced Flash MX Sound Timing made it clear. There is one exact timing for sounds in Flash, namely the Sound.position property. In order to use this for common timing information, we needed to play a really long sound, and then we could check where we were in this reference sound. As we’d see, we’d get position increases in chunks of 46.4 ms. It turns out that this corresponds to the buffer size used by Flash (2048 samples 44.1 KHz) and sometimes (NOTE: not always) when the soundcard calls back to get more data to play, Flash updates Sound objects’ position values. So I started a really long, totally quiet, sound to play in parallel for common timing, but it quickly struck me that a smart approach would be just to loop something like a 1 second sound. I’d found my first conclusion:

1. Use a silent reference sound and loop this sound. For each loop we can increase a counter and thus we can always reach the overall position. A reasonable length is probably 1 second. Make sure it’s mono by the way.

Ok great! Things were clearly better. Only - quite many sounds still came slightly wrong and misaligned musically. After thorough investigation, it turned out that when you say Sound.play to Flash, this doesn’t really happen immediately. Not even on the next sound card callback. But rather on the next sound card callback which Flash happens to like. (My guess: where some low prioritized task queue copy function for some other thread has completed).

2. So the solution is to use some silence in the beginning of the audio, and schedule the sound to play “in the future”. We thus introduce a little latency, but we really have the ability to sync sounds given a little latency of say 200 ms. If we schedule audio every 200 ms, we need at least a 200 ms silent part before each sound, and then we can just check the position of the reference sound and use Sound.start(OFFSET) to start a sound with a little offset that has been calculated from the position. This is actually much better explained at Advanced Flash MX Sound Timing. Great! But it turned out that there were still glitches.

3. Enter 1 short 1-sample silent mono sound that we don’t loop but re-trig all the time. Yes, just as it had been suggested by Advanced Flash MX Sound Timing and others. It turns out that callbacks at onSoundComplete are really good for starting new sounds, even though they don’t always come when the sound has actually finished (as pointed out by very disappointed people at http://www.make-some-noise.info). Anyhow…still great for our purposes! To be clear: the idea is basically to just start this one-sample sound and use its onSoundComplete handler. In that handler, we just trigger the little sound again. And so on. This way we get a callback on “good” times, instead of using setInterval or onEnterFrame. Super! So we now have a longer sync sound that we loop for position, and a shorter sync sound for good callback times. But…happiness didn’t last for long. Even though the situation had clearly improved there were still glitches every now and then. If you weren’t picky or perhaps playing some rather soft/smooth sounds, perhaps you didn’t care. But we had this smackin’ snare and hand clap we wanted to make a groove of and glitches aren’t grooves’ best friends.

4. It turned out some old fashioned pickyness, good system design and loads of asserts were bringing in some predictability. Starting a Sound in Flash isn’t just a few-instructions synchronous little thingie. It actually takes a couple of milliseconds. And by starting a lot of sounds, the master position could have changed, and then those recently started sounds were out of sync. Even on direct callbacks from the onSoundComplete handler previously mentioned the master clock sometime changed directly. Ok, so by just avoiding scheduling sounds at those positions seemed to do the trick quite well. But we now needed to increase the quite part in the sounds, since REALLY GOOD callback times occurred more seldom. Ok, still cool, but….still glitches. Shit! But some more coffee revealed a more serious approach to solving this.

5. Enter error detection. Yep, we could always check the positions of Sound objects that we schedule to see if they match what we expect them to have compared to the master position. This meant that we had to rewrite the scheduling mechanism. Instead of just using play, we now added sounds to a queue and then removed them when they had been deemed “OK” by some error detection handler. But…now it turned out the sync was really good. But…there were drop-outs. Yep, some sound could never be synced back, but an even more common problem turned out to be that it was really hard to read a sound’s position. Say you used the same kick drum sample on each beat, but when you were to read the position of that sound object, it might return the old sound object’s position and vice versa. This really exposed a nasty detail of the Sound API: namely that the Sound object plays two roles: to wrap some audio file and to provide information about currently playing material. A more clean solution more in line with how things work would probably be for the play function to return a PlayingSound (or similar) object which had the position. Anyhow, as that wasn’t available, we decided to build…

6. …a SoundPool class. The idea is to load a bunch, say 30, similar Sound objects in a pool. Whenever a new playing sound is needed, we could ask the pool for a “fresh sound” and the pool would just circle round the sounds and return them in circular order. How many sounds you need depends on how many sounds you play simultaneously, and also how long your silent intro is. We decided that ~30 was probably a quite good number. Notice that the browser cache would normally take care of not issuing more requests than necessary, but it’s probably wise to make the server return an Expiration Data in the HTTP header or similar for the mp3 files in question.

Now we had quite some solutions to deal with this. There was just the problem that when you filled the sequencer grid with beats (I know, not the grooviest of beats, kind of repetitive) sounds vanished and there was nothing heard. Aarrghh…going crazy again! When investigating this it turned out to be because of the sound channel limitation in Flash (currently 32 channels). So what happens is actually that if you have 32 channels playing and play another sound, one of the first sounds just stop. Unlucky for us all sounds start with silence, so we were listening to 32 channels of groovy silence. Not cool.

7. Enter cancel mechanisms on scheduling when too many sounds are playing. Yes - we adapted our scheduling mechanism so that when a sound was OK in sync we moved it to a playing collection and continuously removed sounds from that queue when they finished. Thus we could keep track of how many sounds were playing and cancel any scheduling attempts. We just simply had to wait for some sounds to complete. Sure, this meant that we had fewer times to sync audio, but it still worked quite well.

Ok, but there were still occasional drop-outs

Yep, we decided to live with it. It really happened quite seldom, and we set a limit on 100 ms drift to regard a sound as playable even though not in sync.

Next thing: sync with video. We needed to provide some video along with the sounds as well. We just used an onEnterFrame callback and calculated the approximate position. When we had the latest callback we saved the position using a getTimer() call and then we could just diff a getTimer() to the last call to calculate a continuous position which we could then use for video. Our video actually started 85 ms before the audio se we showed the corresponding video on the first frame ~85 ms before the sounds was going to be heard.

» Download Code

So - how can you use this code? Just check out the Main.run function which demonstrates an example. Furthermore, check each classes header to see some documentation in comments.

If you really want, I could probably include a demo too =) Just contact me or leave a comment below.

Good luck!

Staffan

1. Skalbar och billig hosting (IaaS)

2. Möjligheten att snabbt skapa ett lätt serverlager för RIA med befintliga PaaS-tjänster

3. Affärsmöjligheter med SaaS

4. Bygga bättre applikationer snabbare och billigare med bra PaaS-tjänster

Låt oss titta lite på vad jag menar i detalj:

1. Skalbar och billig hosting

Denna typ av nytta är tämligen uppenbar. Om IaaS på moln är billigare (det är det oftast idag) än att köpa “vanlig hosting”, varför göra något annat? Med en IaaS-lösning kan man ju dessutom skala upp med några musklick. Vad finns det egentligen för argument som talar emot en sådan lösning? Det som oftast brukar lyftas fram är säkerhetsrisker - vågar jag anförtro åt Microsoft/Google/Amazon att handha min data och kan jag leva med att det kommer vara åtkomligt över Internet? Vidare - är erbjudandena jämförbara? Om jag köper hosting från en “vanlig” hostingleverantör får jag ju felsökningsexpertis, övervakning och hårdvarusupport.

Nå, kalla mig naiv, cynisk eller luttrad - jag påstår att felsökning bäst görs av utvecklare, övervakning/statistik/loggning av en stor IaaS-leverantör och hårdvarusupport inte alls (virtualisering!). När det gäller säkerhet tror jag dessutom att riskerna med molnlösningar gärna överdrivs. Jag ser egentligen inte varför jag ska misstro Amazon mer än vilken hostingleverantör som helst och vi pratar knappast om att flytta de system vi behöver ha fysiskt frånkopplade från Internet till molnet. Tvärtom brukar akilleshälen säkerhetsmässigt vara mänskliga rutiner och handhavanden och skillnaden är knappast särskilt stor i det avseendet mellan alternativen ovan. Möjligen borde en IaaS-lösning lättare kunna stå emot DoS-attacker eftersom temporär storskalning är ett alternativ.

Kommer då verkligen Googles/Amazons/Microsofts paket att hota idag etablerade hostingpartners? Vi får väl se, men en annan faktor att ta med i beräkningarna är hur aktörer som Microsoft och Google säkerligen kommer utforma sina utvecklingsmiljöer så att de hänger ihop med hosting. Ett klick i Eclipse eller Visual Studio och så är man igång. För att inte tala om varför du ska använda tjänster genom Microsofts Live Services eller söka data genom Googles egna sökspråk. Lycka till att hitta en annan hostingleverantör som kan erbjuda det.

2. Möjligheten att snabbt skapa ett lätt serverlager för RIA

Nyligen hade vi en kund som skulle göra en grafiskt avancerad flashapplikation med spel och tilltalande interaktionsdesign. Men det fanns också ett behov att spara lite speldata och hämta listor över resultat från olika länder. Små snabba utsökningar helt enkelt. Med traditionell webbteknik hade man behövt

a) Definiera format för datautbyte (i XML/JSON)

b) Exponera webbservices eller REST-liknande tjänster

c) Bygga ett datalager som kan persistera objekten och göra utsökningar enligt kriterier

d) Hantera säkerhet och åtkomst till data och funktioner

e) Utreda lastkrav och kravspeca en hostingmiljö

f) Hitta en hostingleverantör som uppfyller kraven

g) Deploya applikationen

Utgår man däremot från en färdig skalbar PaaS-tjänst med datalagring, rättighetssystem och REST-sökningar är det bara en fråga om en spec till Flashleverantören. Visst förenklar jag en aning, men faktum är att kostnaden minskar dramatiskt för att ta fram lösningen. Med PaaS-tjänster som också utvecklas med nya kundprojekt kommer plattformarna bli mer och mer kompetenta och fler och fler projekt kommer kunna se det mesta löst i en redan utrullad applikation. Man kan redan idag återvinna kod och komponenter, men för att verkligen minska kostnaderna i a) - e) ovan behövs återvinning på en högre nivå.

3. Affärsmöjligheter med SaaS

Med lite tekniska begrepp på plats kan man fundera på övergripande trender i webb- och mobilvärlden. Med SOA, mobilt internet och den alltmer vanliga attityden att inte göra allt själv ser framtiden för SaaS ljus ut. Inte bara ljus - SaaS-tjänster som använder andra SaaS-tjänster som i exempelvis mashuptjänster blir vanligare och vanligare. För att vara konkret - jag kan hyfsat lätt göra en Salesforce-site som använder Google Maps och kopplar in en kommunikationskanal från Google Wave för att styra min Twitter som också syns på Facebook. Konsekvensen blir att Molnet (Internet) blir mer sammanvävt när tjänsterna använder varandra. Mer och mer sammanvävning kommer kräva och framtvinga enklare och snabbare integrationsmöjligheter. Och om integration blir lättare kommer tjänsteinriktad arkitektur kunna användas mer. Det blir lätt och affärsmässigt fördelaktigt att skapa små tjänster som bara gör en sak, men gör den bra - lite som en komponent i dagsläget. Vi kan ex. göra rena systemfunktioner som bildomskalning och -konvertering på molnet, eller bild- och videospelare i Flash som en mjukvarutjänst. Återanvändning kan fungera på en högre nivå än genom dagens komponenter.

Mashups och återanvändning på hög nivå kommer att bli mer vanligt, vilket betyder att det också blir viktigare att hålla koll på vilka tjänster som finns. Teknikbyråer måste inte bara  prioritera omvärldsbevakning än högre utan också komma till rätta med en helt ny typ av problem. Låt oss ta ett exempel: idag publicerar kanske en redaktör ett pressmeddelande via ett CMS på sitt företags hemsida, med bilder och filer inlänkade från funktioner i CMS:et. Möjligtvis exporteras detta pressmeddelande via RSS till en nyhetssajt och i bästa fall tittar redaktören efter någon timme hur pressmeddelandet ter sig på nyhetssajten. Men om vi tar de här SaaS-principerna på allvar och tillåter oss att blicka framåt en aning - varför ska redaktören nöja mig med funktioner för bilder och filer i CMS:et? Det finns ju utmärkta bildfunktioner hos Splashup och Flickr. Kan CMS:et erbjuda en förhandsvisning på nyhetssajten innan publicering? Hur är det med länkar och beroenden mellan tjänster? Förstör hon något om hon tar bort sidan? Här finns onekligen affärsmöjligheter att skapa bättre tjänster och tillägg för en webbteknikbyrå.

4. Bygga bättre applikationer snabbare och billigare med bra PaaS-tjänster

Det här inlägget har hitills handlat rätt mycket om teknisk återanvändning - den industriella princip som möjliggör mer kvalitet till mindre kostnader. Låt mig få ta en liten avstickare till bilbranschen som jag lånar från David Chapell: 1905 gick var och en till sin lokala bilhandlare och beställde sin bil. Det skulle vara specialutformade strålkastare, kromdetaljer på egenutvalda ställen och kundanpassade detaljer till höger och vänster. Sen kom en viss Ford (inte Harrison) och vände upp och ner på världen - “Välj vilken färg du vill bara den är svart”. Poängen var initialt att fler hade råd med bilen, men naturligtvis också att det gick att producera oändligt mycket bättre bilar i alla avseenden när det fanns ordentlig teknisk återanvändning (med specialiserade underkonsulter). En detalj som inte ska glömmas i industrialiseringsprocessen är också gemensamma standarder för alltfrån hjulupphängning till spänningsnivåer till bilstereon.

Nu tillbaka till mjukvaruvärlden. Parallellen är uppenbar: jag menar att vi befinner oss på 1905 års nivå. Vilket leder oss in till frågan varför vi i så fall inte kommit längre med teknisk återanvändning trots ca 40 års integrationsarbete med klasser, bibliotek, dll:er, komponenter, assemblyn och tjänster. Ett tappert försök är förstås att i Fords anda göra som Google Apps: “Gör vilken webbplats du vill bara den innehåller enkelt innehåll och ser ut som vår standardmall”, men fint eller flexibelt blir det i dagsläget inte. Låt oss titta på ett annat exempel:

Låt oss säga att jag vill ta fram en webbshop. Jag kan förstås utgå från en befintlig - kanske en open-source-variant. Eller så kan jag köpa en tjänst som hos starweb.se och anpassa min webbutik så mycket som deras system möjliggör. Oavsett vilket vill jag kanske ha andra delar på min sajt med spännande funktioner, och så vill jag kanske använda ett bra CMS för att administrera övrigt innehåll. Mina produkter finns idag redan i en databas på egna servrar och som används av några butikssystem. Dessutom säljer jag kanske produkter som tjänar på en häftig 3D-visning i Flash och det vill jag ha på hemsidan. Sen vill jag att andra ska komma åt mina produkter via XML över REST för tredjepartstjänster. Men jag vill ju också ha modern HTML som är anpassad till moderna krav på tillgänglighet och SEO. Dessutom kanske det vore fint med en lite anpassad vy för iPhone/Android. Och jag vill inte låsa in mig i något konstigt teknikhörn! Borde inte det gå ganska lätt att göra - någon vecka eller två? Tyvärr vet alla som har implementerat webb att så inte är fallet.

Problemet är helt enkelt att alla inte riktigt är överens om hur man bygger webb. Hur ska man kunna ha en rigorös policy för HTML om de komponenter man köper styr HTML-renderingen. Svaret blir att allt får anpassas och då går konsultklockan. Vi är fortfarande en ganska bra bit från helt separerad återanvändning, där olika delar gör sin specialiserade del och all arkitektur är standardiserad. Tills dess kommer konsulter sälja många timmar på att göra liknande saker om och om igen. Men PaaS är ett steg på vägen i rätt riktning. Vi ska inte heller glömma tekniker som CSS 3, REST, HTML 5, funktionella språk, javascriptramverk som jQuery m.m.. Men i slutändan handlar PaaS mycket om att vi utvecklare ska lämna tekniska beslut till Microsoft, Google m. fl. Vi kommer inte kunna styra över detaljer i hur loggning görs i webbservrar, hur databaser ska klustras, hur url-strategin ser ut för att REST-exponera vår datamodell - kanske i slutändan inte ens hur HTML renderas. Och det är något bra! PaaS via moln innebär lite lite mer enhetligt svart, men i förlängningen mycket bättre och billigare webb!

Även om moln (cloud computing) har varit på tapeten ett tag nu så börjar det dra ihop sig för .NET-utvecklare världen över. Windows Azure ska lanseras lagom till PDC 2009 (17-20 november) och ett nytt operativsystem (nåja) möter världen. Men ok - Microsoft är, sin vana trogen, inte först ut med ny teknik. Det var en bokhandlare som visade vägen när molnet skulle tas ner på jorden - Amazon med sitt Elastic Cloud (idag EC2 och datatjänsten S3). Såhär i efterhand känns det möjligen naturligt eftersom Amazon med webbplatsens besökarantal varit tvunget att uppfinna nya och åter nya lösningar för att kunna skala. Idag finns andra spelare på planen som SalesForce och Google med Google AppEngine. Dessutom finns nya molnaktörer som Engineyard och RightScale, men de erbjuder lite olika saker. Vad skiljer dem åt och hur kan man dra nytta av tekniken? Och kommer webbprojekt förändras framöver på grund av detta? Läser man bloggar och artiklar så verkar molntjänster handla om allt från att köpa Sharepoint per månad till döden för hostingleverantörer. På grund av begreppsförvirring kanske vi ska prata lite mindre om moln och lite mer om IaaS, PaaS och SaaS. Men vad betyder det då? Låt oss reda ut begreppen.

Med moln eller cloud computing menas egentligen “datorteknik som samverkar i stor skala för att leverera en tjänst”. Men naturligtvis brukar man vanligtvis vara mer konkret. Vanligtvis menar man att hyra vissa grundläggande nättjänster för att erbjuda nya nättjänster på högre nivå. Att allt kallas moln nuförtiden är förstås också en trend, men det är rimligt att reda ut vilka lager och begrepp som man brukar tala om i dessa sammanhang:

IaaS (Infrastructure as a Service)

Precis som namnet antyder handlar det om att man köper datorkraft som en tjänst. Får jag låna lite processor och disk ett tag så får du lite pengar. Det här är alltså precis vad Amazon ägnar sig åt och en nyckel till framgång är effektiv virtualisering.

I praktiken är det också få leverantörer som storskaligt kan erbjuda den här tjänsten - det kostar att köpa stora mängder hårdvara. Ett litet exempel på behovet hos sökmotorföretag: Jason Zanders berättade på TechEd Barcelona förra året att Yahoo, Google och Microsoft tillsammans står för mer än 50% av dagens serverinköp. I praktiken innebär köp av IaaS idag att du hyr virtualiserade maskiner i någon form, där de fysiska servrarna står placerade i ett av ganska få stora datacenter världen över. Rigorös bevakning fordras förstås på plats och kalla länder är heta eftersom kylningen är billig. Grönland och framförallt Island är utöver nämnda skäl också poppis på grund av närhet till dagens två mest IT-intensiva kontinenter, så en liten ljusglimt är det nog i finanskrisens mörkerland.

Men för att kontrastera ovanstående påstående lite grann: att köpa datorkraft som tjänst måste ju inte göras via datacenter. SETI@home använder vanliga desktopdatorer och Skype och BitTorrent använder P2P-teknik. Kanske stundar en framtid där vissa molnleverantörer också betalar enskilda aktörer som tillhandahåller datorkraft och där “molnet” utgörs av ett mer spritt P2P-nätverk? Det borde kunna vara en naturlig utveckling för exempelvis Skype, lite i linje med hur Amazon blev molnleverantör.

PaaS (Platform as a Service)

Ni anar kanske vart vi är på väg? Visst - det är ett lager ovanpå IaaS (vad kan komma sen?). Här börjar det bli lite mer spännande och här börjar de etablerade leverantörernas erbjudanden spreta ordentligt. Ok - vad är då plattformstjänster? Jo, den typ av grundläggande tjänster som utvecklare drar nytta av när applikationer byggs. Det kan exempelvis röra sig om smidiga lösningar för datalagring, sökning, e-posthantering, single sign-on, statistik, API-exponering via datattjänster och testverktyg. Hårdvara är fortfarande hårdvara om än i mängder, men mjukvara kan variera i det oändliga.

Den kanske viktigaste, och vanligaste, plattformstjänsten är förmodligen datalagring. Både Microsoft (SQL Azure), Google och Amazon (S3) erbjuder den om än med olika stöd. Amazon går hitills kortast och Microsoft längst i sina olika ambitioner. Förenklat kan man säga att Amazon erbjuder möjligheten att spara och söka efter godtyckliga objekt. Microsoft gjorde en kovändning från sin första ambition och erbjuder nu mer eller mindre än enklare version av SQL Server som körs i molnet. Det innebär alltså möjlighet att köra ganska avancerade frågor och  Google ligger någonstans mittemellan. Gemensamt för Amazon och Microsoft är fokus på REST, d.v.s. möjligheten att hämta och skicka data så enkelt som möjligt, med vanlig HTTP som kan göras i vilken webbläsare som helst. Du ska helt enkelt på ett lätt sätt kunna hämta data från molnet med en enkel webbläsare i format som JSON och XML.

SaaS (Software as a Service)

När vi närmar oss nästa lager närmar vi oss användaren än mer. Om vi hårddrar målgrupperna en aning är målgruppen för IaaS driftansvariga, PaaS utvecklare och för SaaS slutanvändare eller inköpare. Inom SaaS hittar man tydliga företagsriktade tjänster som t.ex. CRM-system att hyra, SAP-implementationer och Exchange. Men utöver detta kan man nämna exempelvis Google Maps och Google Apps. Ska man dra konceptet till sin spets är webben till sin natur SaaS-baserad. I SaaS kan man alltså mosa in mängder av Internettjänster. Poängen är snarare att de betalas via hyra och driftas av tredje part.

Men SaaS inkluderar också i viss mån tendensen att flytta ut applikationer från skrivbordet till Internet. Istället för att köra Office, kan jag använda Google Docs. Istället för bildbehandlingsprogram kan jag använda Splashup, Picasa och Flickr. Det här är en spännande marknad som Microsoft med Windows Azure satsar på genom Live Services. En stor utmaning med en mer flytande gräns mellan webb och desktop är hur applikationer hanterar offline- och onlinelägen och hur man åstadkommer en mer integrerad användarupplevelse. Här finns mycket att göra och värt att hålla ögonen på är, utöver nämnda Live Services, tekniker som JavaFX, AIR/Flash och Silverlight. Även HTML 5 är spännande i och med vad det innebär för mer kompetenta och åtkomliga SaaS-tjänster.

Med begreppen på plats vill jag gärna utmåla några fokusområden som jag tror kan bli särskilt intressanta. Mer om det i nästa inlägg, men följande punkter tror jag blir svåra att missa.

1. Skalbar och billig hosting (IaaS)

2. Möjligheten att snabbt skapa ett lätt serverlager för RIA med befintliga PaaS-tjänster

3. Affärsmöjligheter med SaaS

4. Bygga bättre applikationer snabbare och billigare med bra PaaS-tjänster

Men som sagt - mer detaljer om det i nästa inlägg…

Men det var inte så länge sedan som utvecklare var tvungna att att tänka på modem och långsamma uppkopplingar. När bilder komprimerades till bristningsgränsen och skillnaden mellan en swf på 30KB och 130KB var enorm.

I början av mars avgjordes en tävling som gick ut på att koda ett spel i flash som väger mindre än 4 kilobytes. Isotop var en av deltagarna i tävlingen, där tre personer bestämde sig för att ta reda på vad man kan åstakomma med denna minst sagt knepiga begränsning.

Resultatet: Ghost4Koin

http://www.gamepoetry.com/blog/4k-flash-ghost4koin/

Hur mycket är 4K?

4 kilobyte är verkligen inte mycket utrymme.

Loggan på google.com väger till exempel 7,4 KB. Det är nästan dubbelt så mycket.

För att sätta detta i någon slags relation så provade vi att embedda en minimal bitmap (den här: ) i flashdevelop och kompilera. Enbart den bilden gjorde att swf:en vägde 4kb.

Planen

Planen från början var att få till någonting som var så tekniskt imponerande som möjligt, och hur gör man det? Man tänker ut hur man på enklaste vis skulle lösa uppgiften och gör tvärtom =)

Grafik: Enklaste vägen skulle vara att använda flash inbyggda drawing-api (rita linjer, fyll dem med färg), därför valde vi att jobba med bitmapgrafik. Detta ger en tydligare oldschool-känsla, och var en stor utmaning med tanke på föregående test.

Ljud: Att stoppa in ljud i en swf på 4KB är inte att rekommendera. Det tar alldeles för mycket utrymme. Givetvis måste vi ha ljud med.

Banor: När man har så begränsat med minne vore det enklaste att göra en så enkel bana som möjligt, helst utan scrolling. Därför var ett av de viktigaste målen att generara så stora världar som möjligt.

Resultatet

Samtliga delar i planen genomfördes. Detta innebar bland annat att vi var tvungna att konstruera ett eget bildformat och generera allt ljud dynamiskt.

Spelet slutade på en 4:e plats i gamepoetrys tävling (2:a i Audience Choice).

Jag tror personligen att det beror på att inget utav målen med spelet hade något att göra med gameplay. Sanningen är att det oftast är de enklare spelen som är roligast att spela.

Här finns en lista med samtliga bidrag spelbara – och domarnas kommentarer (se särskillt 4k Pillars, Falling with style samt det svenska vinnarbidraget A-Steroids).

http://www.gamepoetry.com/blog/4k_flash_march_09/

Summering

Att delta I tävlingen innebar en intressant och rolig utmaning där vi tvingades lösa problem vi inte varit med om tidigare.

Vi hade kanske hamnat lite bättre om vi fokuserat på gameplay, men för oss låg utmaningen i det tekniska.

Vi hade kunnat lägga till ganska mycket mer funktionalitet om vi hade struntat i exempelvis ljudet, men det kändes väldigt stämningssättande med de underbara retro-tonerna. Men i slutänden handlar det ändå om att ha roligt, och kanske lära sig något på köpet.

Man kan inte undgå att tänka på hur imponerande spelskaparna var i slutet på 70-talet när en spelmaskin inte hade mer minne än så här.

http://sv.wikipedia.org/wiki/Atari_2600

Ett bra sätt att förbättra kravarbetet och precisionen i projekten är därför att jobba med skisser och prototyper, så kallade mockups.

Jag har hittat ett verktyg för detta som vi på Isotop gillar skarpt: Balsamiq Mockups från Balsamiq Studios

Med detta verktyg går det snabbt att göra prototyper över gränssnitt och funktionalitet för såväl webbsajter som applikationer. Verktyget är gjort i Flash och kan köras antingen frisåtående som en AdobeAIR-applikation, men finns också som plugin till Confluence och Jira (två andra verktyg som vi på Isotop använder dagligen).

Kolla in denna demonstrationsvideo om du vill se mer av vad man kan göra med Balsamiq:

Balsamiq Mockups for Desktop from Balsamiq Studios on Vimeo.