Isotop fortsatt i bandytoppen

Postad av staeke i Snack den 2 april, 2010

Efter en hård mangling i tisdags visade Isotop återigen var skåpet ska stå. Denna gång besegrades Stockholm vatten och den eviga motståndaren Hässelby gård. Isotop körde ssom framgångsrikt förr med kedjeuppdelning: Förortskedjan (Nils?, Björn och Ida) samt Stockholmskedjan (Rikard, Erik We och Staffan). Segersiffrorna skrevs till slut till 7-3 och 7-5! Slutspelet - here we come. Beundra tabellen nedan eller gå in på http://www4.idrottonline.se/templates/PageWide.aspx?id=327701.

tabell

Etiketter:

Isotop på Linnéuniversitetet

Postad av staeke i Nyheter den 29 mars, 2010

I tisdags besökte vi studenter på Linnéuniversitetet i Kalmar. Staffan och Bob stod för föreläsandet och framförallt var det programmet för webbprogrammering som gästades. På agendan stod:

  • Isotop som företag
  • Projekt
  • Arbetslivet “egentligen”
  • Framtiden

En del elever klämde in smarta frågor som belönades med USB-minnen och olika ämnen diskuterades under de två timmarna. Vi pratade t ex om; hur ska man jobba med estimering och felsökning? Hur funkar det för oss och andra med bredd och djup? Måste vi tampas med IE6-problematik och hur jobbar vi med testdriven utveckling?

Vi gav slutligen en eleverna en avslutande tankenöt genom följande regular expression-utmaning:

\Aht{2}p:/{2}(?!1)\d13\.136\.38\.2\u0038

Några menade sig direkt ha löst den, men vi ställer oss tveksamma till det.

Vi tackar så mycket för att vi fick komma och avslutar med lite länkar till saker vi talade om:

Kod:

Exemplet i F#

Siter:

NCC
STF - Sveriges svenskaste jobb
Fans1.com

Verktyg

TeamCity - ett verktyg för Continous Integration
Resharper - snabbare jobb i Visual Studio
ankhsvn - subversionintegration i Visual Studio
JIRA - ärendehantering
git/github - versionshanteringsalternativ till Subversion/TFS
Team Foundation Server (TFS) - Microsofts samarbetsplattform (versionshantering, ärendehantering, continous integration m.m.)

Produkter

EPiServer - CMS

Coolt

Hobnox Audiotool och Livetool - inspelning och synthemulering i Flash
Pixlr - “Photoshop” i Flash

Etiketter:

Advanced sound programming in AS2

Postad av staeke i Blogg, Staffan den 2 november, 2009

Is it possible to synchronize sounds with good precision in AS2 to create a beat box? You want those bass drum sounds pounding on 1, 3 while digging a nice groovy tight hi-hat. And sync problems: no thanks! Lots of people have experienced problems, but read on to get some code and 7 strategies to get there. Or…browse to the end and download some code.

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

Etiketter:

5 Kommentarer

Moln i praktiken, del 2

Postad av staeke i Blogg, Staffan den 30 oktober, 2009

I förra inlägget talade jag lite om vad molnteknik innebär och om IaaS, PaaS och SaaS. Dessutom nämnde jag fyra huvudområden som särskilt intressanta:

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!

Etiketter: , , , , , , , ,

2 Kommentarer

Moln i praktiken, del 1

Postad av staeke i Blogg, Staffan den 30 oktober, 2009

Det här är det första av två blogginlägg som handlar om hur vi kan dra nytta av molnteknik. Först en liten teknisk överblick och beskrivning av nuläget och i nästa inlägg lite mer om möjligheter och vad jag tror om hur vi kommer att påverkas.

Ä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…

Etiketter: , , , , , , , ,

3 Kommentarer