Communited

Realtime berichtensysteem in Timeblockr met MSMQ en SignalR

Mon, 08 Oct 2012 11:06:00 +0200

Deze blogpost geeft inzicht in de techniek die gebruikt is binnen Timeblockr voor het bieden van een realtime berichtensysteem die het mogelijk maakt om meerdere webclients direct aan te sturen vanaf de server om deze synchroon te houden.

Huidige situatie
In de vorige release van Timeblockr zit een pagina voor de receptie, met daarop alle afspraken van die dag. Hierop kunnen medewerkers zien welke afspraken er zijn, op welk tijdstip bezoekers worden verwacht en wat de status is per afspraak. Het grote nadeel van deze pagina is, dat de gebruiker deze steeds zelf moet verversen om wijzigingen te kunnen zien.
Voor de nieuwste versie van Timeblockr zijn zelfs extra pagina's voor de wachtruimte en optioneel voor de balie toegevoegd, met ieder een eigen gefilterde weergave van de afspraken. Het is ondoenlijk dat medewerkers deze steeds zelf moeten verversen om wijzigingen te kunnen zien.

De gewenste situatie
De ideale oplossing is dat een gebruiker de gewenste pagina eenmalig opvraagt, waarbij alle wijzigingen automatisch op het scherm zichtbaar zijn. Niet alleen wanneer er een nieuwe afspraak wordt gemaakt of een bestaande afspraak wordt gewijzigd, maar ook alle tussentijdse statuswijzigingen van het moment dat de klant zich aanmeldt bij de balie tot aan het uiteindelijk afronden van de afspraak.
Daarbij hebben we het niet alleen over wijzigingen door die betreffende gebruiker, maar vooral ook de wijzigingen die plaatsvinden door acties van andere collega's via hun eigen PC. Tenslotte moeten ook statistische gegevens kunnen worden weergegeven, zoals realtime wacht- en behandeltijden.

De gebruikte oplossing
Om de interactie en gebruikerservaring naar een dergelijk niveau te tillen, moest een andere oplossing bedacht worden. Er is uiteindelijk gekozen voor een combinatie van MSMQ (Microsoft Message Queuing), SignalR in een self-hosted Windows service en javascript.

MSMQ is een relatief oud concept en bestaat al sinds Windows NT 4 en Windows 95. Het lijkt vrij onbekend, maar is bijzonder krachtig voor het ondersteunen van communicatie tussen verschillende applicaties. Het idee is dat applicatie A een object op de queue kan zetten. Applicatie B "luistert" vervolgens naar deze queue en zodra er iets op wordt geplaatst krijgt deze applicatie (samen met het geplaatste object) hiervan een seintje, waarna het object ook direct weer vanuit de queue wordt doorgeplaatst. Deze communicatie verloopt vrijwel naadloos en realtime, en is uiterst schaalbaar.

SignalR is een vrij recente library die continue server-client connecties mogelijk maakt. Normaal gesproken vraagt een client (een browser) een webpagina op, waarna de webserver deze doorgeeft. Daarna is de verbinding gesloten en heeft de server geen contact meer met de client. Daarmee kan hij deze dus ook niet zelf benaderen. Met SignalR is het dus wel mogelijk om als het ware een verbinding open te houden, zodat de server exact weet welke clients er nu verbonden zijn.
Daarbij kan de server nu ook direct javascript functies uitvoeren op iedere gewenste client.
Dit alles wordt uitgevoerd met behulp van een dynamische javascript proxy, die op de server wordt gegenereerd en gehost. Deze proxy wordt vervolgens op de clients toegevoegd als een normale javascript ‘include’. Het opvragen van de url van de proxy geeft dan ook netjes een javascript bestand.
Hierdoor is het dus mogelijk om berichten naar clients te "pushen" zonder dat de medewerkers zelf iets hoeven te doen. Met een extra stukje javascript kunnen deze berichten worden opgepakt en bijvoorbeeld worden getoond op het scherm.
Anderzijds is het ook weer mogelijk om vanaf een client met javascript via de SignalR proxy functies op de server uit te voeren.

De werking
Op de server van Timeblockr staat een aantal onderdelen:
- Website: IIS host de website voor de bezoeker en de beheeromgeving
- WCF: IIS host ook de WCF webservice voor de koppeling naar de database
- MessageServer: dit is de Windows service voor het hosten van de SignalR proxy
- MSMQ: hierin is een queue aangemaakt voor het bijhouden van alle statuswijzigingen van iedere afspraak

Timeblockr heeft een publieke website waar bezoekers afspraken kunnen maken. Daarnaast is er ook een website voor de beheeromgeving. Hierin staan de pagina's voor receptie, wachtruimte en de balie. Via de oplossing staan deze nu allemaal realtime met elkaar in verbinding.

Voorbeeld in de praktijk:

Zodra een bezoeker een afspraak maakt op de website, zal dit via WCF aan de database worden toegevoegd. Daarbij wordt het ID van de afspraak direct op de MSMQ queue gezet.
Vervolgens luistert de MessageServer naar deze queue en vangt het ID van de gemaakte afspraak op.
Dan wordt de juiste afspraak opgehaald en via SignalR verstuurd naar alle relevante clients.
Daar bepaalt een stuk javascript logica of de afspraak wel of niet wordt toegevoegd, aangepast of verwijderd.
Alle medewerkers voor wie de afspraak relevant is, krijgen deze dan automatisch op het scherm te zien.

Ook wanneer een medewerker een afspraak incheckt, zal deze actie via SignalR direct naar de MessageServer gaan.
Daar wordt de status van de afspraak bijgewerkt en opgeslagen in de database. Net als bij iedere andere wijziging zal ook nu het ID van deze afspraak op de queue worden gezet. De MessageServer pakt deze vervolgens weer op en zorgt ervoor dat alle clients weer op de hoogte worden gebracht van deze wijziging, zodat alle medewerkers voor wie de afspraak relevant is de wijziging automatisch in beeld krijgen.

Extra aandachtspunten
Uiteraard zijn voor deze techniek wel voorzieningen getroffen voor beveiliging, zodat ongeautoriseerde verzoeken geweigerd worden. Daarbij is ook gebruik gemaakt van SignalR-Groups, zodat clients alleen die berichten krijgen die ook daadwerkelijk voor hen bedoeld zijn.

Het zou wellicht kunnen gebeuren dat de MessageServer offline gaat. Dan worden alle clients hiervan wel direct op de hoogte gebracht, met de melding dat het scherm niet langer automatisch bijgewerkt wordt. Daarnaast is er op dat moment een fallback scenario beschikbaar zodat altijd doorgewerkt kan worden in een "statische mode". De medewerkers moeten dan wel weer zelf de pagina's verversen.

PhoneGap vs. Native Apps

Fri, 11 Nov 2011 12:05:00 +0200

PhoneGap vs. SDK’s

VS

Waarom zou je nadenken

Steeds meer mensen bezitten een Smartphone. Er worden ook steeds meer applicaties gemaakt voor deze Smartphones. In de tussentijd zijn echter veel verschillen platformen ontstaan. Het is dan ook voor ontwikkelaars moeilijk geworden een keuze te maken.

Doordat deze platformen zo erg verschillen van elkaar, is het moeilijk om te veranderen van ontwikkel methode. Het is dus belangrijk dat er een verstandige keuze wordt gemaakt. Middels dit artikel proberen we de keuze voor de ontwikkelaar makkelijker te maken. Er zullen verschillen naar voren komen die belangrijk zijn om over na te denken.

Voor de een is het bijvoorbeeld belangrijk dat de applicatie er goed uitziet en dat er gebruik kan worden gemaakt van alle functies van de telefoon. Een ander vindt het weer belangrijk dat iedereen snel wordt bereikt en dat het niet veel tijd kost de applicatie te bouwen.

PhoneGap

Wat is PhoneGap?

PhoneGap is een open source framework gemaakt door Nitobi, voor het bouwen van een cross-platform mobiele applicaties met HTML, CSS en Javascript. Het is in principe een pakket dat wordt gemaakt om cross-platform applicaties van dezelfde source code te creëren. De applicaties hebben dan ook gewoon een pictogram en werken op dezelfde manier als een applicatie gemaakt met een SDK. De specifieke API, zoals ‘location’, ‘contact’, e.d. wordt afgeschermd door een standaard API van PhoneGap.

PhoneGap is een oplossing om mobiele applicaties voor verschillende apparaten te bouwen. De applicatie kan ook gewoon verspreid worden via applicatie winkels, zoals de Android Market van Google en de Appstore van Apple.

Ondersteunde platforms

· Android

· iPhone

· Blackberry

· Symbian

· Palm

· Windows Phone (Bèta)

De Windows Phone 7 versie is nu nog in bèta, maar zal ook op kort termijn beschikbaar komen.

	Iphone / Iphone3g	Iphone 3GS and newer	Android	OS 4.6-4.7	OS 5.x	OS 6.0+	WebOS	Symbian	Bada
ACCELEROMETER	X	X	X	-	X	X	X	X	X
CAMERA	X	X	X	-	X	X	X	X	X
COMPASS	-	X	X	-	-	-	-	-	X
CONTACTS	X	X	X	-	X	X	-	X	X
FILE	X	X	X	-	X	X	-	-	-
GEOLOCATION	X	X	X	X	X	X	X	X	X
MEDIA	X	X	X	-	-	-	-	-	-
NETWORK	X	X	X	X	X	X	X	X	X
NOTIFICATION (ALERT)	X	X	X	X	X	X	X	X	X
NOTIFICATION (SOUND)	X	X	X	X	X	X	X	X	X
NOTIFICATION (VIBRATION)	X	X	X	X	X	X	X	X	X
STORAGE	X	X	X	-	!	X	X	X	-

X = ondersteund - = niet ondersteund ! = onbekend

Bron: http://www.phonegap.com

Voordat er begonnen kan worden met PhoneGap moet er een aantal dingen geïnstalleerd zijn. Bijvoorbeeld IOS heeft het volgende nodig:

Benodigdheden

· Intel gebaseerde computer met daarop MAC OS X.

· Een Apple iOS apparaat (iPhone, iPad, iPod Touch).

· IOS ontwikkelaars certificaat.

Installatie SDK + PhoneGap

· Download en installeer Xcode van de Apple Developer Portal.

· Download de laatste versie van PhoneGap en pak alle bestanden uit.

Creëer een nieuw project

· Start Xcode, daarna onder het File menu selecteer New en vervolgens een New Project…

· In de lijst is er een nieuwe optie bijgekomen namelijk PhoneGap-based Application.

Het is dus gemakkelijk om PhoneGap te installeren. Ook staat er op de website van PhoneGap duidelijk aangegeven hoe alles geïnstalleerd moet worden.

Voordelen van het gebruik van PhoneGap

· Er kan gebruik gemaakt worden van één en dezelfde code voor cross-platform applicaties.

· Er kan ook gebruik worden gemaakt van de hardware op de telefoon zoals geolocatie, tril-functie, acceleratiemeter, contacten en het geluid.

· Er worden nieuwe modules ontwikkeld door de open source community waarmee tijd en geld wordt bespaard.

Nadelen van het gebruik van PhoneGap

· Doordat PhoneGap is ontworpen om meerdere platforms te ondersteunen, zal het niet over de nieuwe functies beschikken zodra deze beschikbaar zijn in de SDK.

· Sommige belangrijke functies zullen nog niet beschikbaar zijn met PhoneGap.

· Net als elk ander open source platform leunt PhoneGap op de gemeenschap om bij te dragen aan verschillende modules. Hoewel de modules prima zullen werken als zij worden uitgebracht, kunnen er nog steeds problemen ontstaan met de ondersteuning en onderhoud van deze modules. De modules kunnen ook niet altijd voldoen aan de wensen van iedereen.

· Het uiterlijk zal op alle telefoons hetzelfde zijn, waardoor het minder op een echte applicatie lijkt.

Native Apps

Wat zijn Native Apps?

Een Native app wordt ontwikkeld met een SDK ( dat letterlijk Software Development Kit betekent ) en dit is een set van ontwikkeltools die kunnen worden gebruikt om software te ontwikkelen. Voorbeelden van software die ontwikkeld is:

· Applicaties/mobiele applicaties

· Frameworks

· Computer spellen

· Besturingssystemen

· Mobiele platformen

Met zo’n digitale gereedschapskist kunnen ontwikkelaars aan de slag om applicaties voor bovengenoemde platforms te bedenken, ontwerpen en ontwikkelen. Het begrip SDK is een vrij groot begrip. Zo kan een SDK bestaan uit een Application Programming Interface (API). Deze heeft weer een interface met een bepaalde programmeertaal. Er worden vaak verschillende tools meegeleverd aan een SDK, namelijk:

· Debugger

· IDE (Integrated Development Environment )

· Voorbeelden

· Documentatie

· Communicatie tussen de hardware

· UI toolkit (gebruikersomgeving of gebruikersinterface)

SDK’s worden vaak beschikbaar gesteld door leveranciers van een bepaald product. Zo heb je IOS SDK van Apple en Android SDK van Google. Deze SDK’s zijn meestal gratis te downloaden. Dat heeft als reden dat deze leveranciers hun eigen producten willen promoten. Als je bijvoorbeeld een applicatie voor de iPhone of iPad wilt gaan ontwikkelen, kun je bij Apple de iOS SDK downloaden. In de SDK zit een set aan tools:

· Xcode IDE is een softwareapplicatie die bestaat uit een editor voor de code, een compiler (letterlijk samensteller of opbouwer), een debugger (om bugs te achterhalen) en een set aan automatisering tools. Vroeger was het zo dat het vaak voor kwam dat deze componenten los werden aangeboden, maar tegenwoordig zie je steeds vaker veelzijdige IDE’s opduiken. Andere populaire IDE’s zijn bijvoorbeeld voor Android Netbeans en Eclipse. Voor Windows Phone is er Visual Studio.

· Met de iOS Simulator kunnen in Xcode gebouwde applicaties voor de iPhone of iPad draaien op je computer. Je kunt hierdoor makkelijk de gebruikersinterface uitvoerig testen.

· Door de Instruments applicatie krijg je meer inzicht in de processen die er binnen Xcode ontworpen zijn. Wat gebeurt er precies als een gebruiker iets onverwachts doet? Kan de applicatie meerdere ingevoerde data of commando’s tegelijkertijd aan? Gebruikt de applicatie niet te veel geheugen?

· De juist userinterface (UI) bouwen voor de applicatie wordt eenvoudiger met de Interface Builder. Hiermee ontwerp je de interface van een applicatie met een drag & drop systeem.

Link naar rechts: Android, Windows Phone, Blackberry en IOS achteraan.

Voordat er ontwikkeld wordt moet er wel gelet worden op de licenties. Het gebeurt vaak dat de SDK gratis te downloaden is, maar dat het product ook gratis aangeboden moet worden omdat het een Open Source licentie heeft. Zodra er een commerciële tint aan zit, zal er diep in de buidel getast moeten worden om nog steeds gebruik te maken van de SDK.

Voorbeeld SDK’s

· IOS SDK (Apple’s Iphone & Ipad)

· Android SDK (Google ’s Android)

· Blackberry SDK (RIM’s Blackberry)

· Windows Phone (Microsoft’s Windows Phone)

· WebOS SDK (HP’s WebOS)

· Symbian SDK (Nokia’s Symbian)

· Bada SDK (Samsung’s Bada)

Voordelen van het gebruik van SDK’s

· SDK’s zijn over het algemeen sneller. Er wordt meer gebruik gemaakt van alle mogelijkheden die op de telefoon beschikbaar zijn.

· De gebruiker voelt zich comfortabeler met een applicatie die speciaal is ontwikkeld voor de telefoon. Met name doordat er gebruik wordt gemaakt van de standaard componenten op die telefoon.

· De ontwikkelde applicatie zal beschikbaar zijn op alle versies van de telefoon.

· De beveiliging van de applicatie wordt beter gewaarborgd omdat het makkelijker is om data gecodeerd te versturen. Dit is tegenwoordig belangrijk omdat veel mensen op hun privacy gesteld zijn.

· Het is makkelijker voor Game-developers om een spel te ontwikkelen. Er is meer mogelijk met de SDK.

Nadelen van het gebruik van SDK’s

· Het is platform afhankelijk. Het zal niet beschikbaar zijn voor alle platformen zoals Android.

· Het is moeilijker te ontwikkelen omdat er kennis vereist is van een bepaalde programmeer taal. De taal is meestal moeilijker aan te leren dan bijvoorbeeld HTML.

· Om te programmeren voor IOS moet je in het bezit zijn van een Apple computer.

Conclusie

Naar mijn mening is PhoneGap een perfecte oplossing voor het ontwikkelen van applicaties voor verschillende platformen. Het is vooral makkelijk als de applicatie een simpele lay-out moet hebben en geen uitgebreide functionaliteiten, zoals bijvoorbeeld een nieuws applicatie.

Als er interesse is om gebruik te maken van een specifiek kenmerk dat niet beschikbaar is voor alle platformen, dan is PhoneGap niet geschikt voor de ontwikkeling van de applicatie. De beveiliging van PhoneGap applicaties is bovendien nog een grotere zorg. Er kan niets gecodeerd verstuurd worden. Ook als er de wens is om gebruik te maken van de laatste functionaliteiten van de platformen, is PhoneGap geen goede oplossing.

Een ander punt om rekening mee te houden, is de applicatie op meerdere platformen uit te brengen. Er moet dan rekening gehouden worden met wat de markt vraagt. Als er bijvoorbeeld voor Europa wordt gekozen, dan kan er het beste gekozen worden voor IOS, Android of Symbian. Echter in de VS is de beste keuze weer IOS, Android of Windows Phone.

Als de applicatie in het begin op twee verschillende platformen zou worden uitgebracht, dan zou er genoeg geëxperimenteerd kunnen worden met de applicatie. De gebruikers zouden dan hun feedback en/of verbeterpunten kunnen geven. Die punten kunnen dan weer aangepast worden voordat de applicatie(s) op alle platformen wordt uitgebracht.

Als de keuze toch niet valt op PhoneGap, omdat het niet aan je wensen voldoet, dan zou ik toch gaan voor het ontwikkelen met de SDK van het platform. Het ziet er toch allemaal iets beter uit. Er zal alleen meer tijd in het ontwikkelen van applicatie gaan zitten en je zal je meer moeten verdiepen in de documentatie van de SDK.

De beveiliging heb je ook zelf in de hand. Als er gekeken wordt naar de installatie van beide, dan valt op dat de SDK van het betreffende platform ook geïnstalleerd moet worden als er gebruik wordt gemaakt van PhoneGap. Het installeren van PhoneGap zelf kost daarentegen geen extra tijd. Als de applicatie op de verschillende platformen uitgebracht moet worden zal er kennis van verschillende programmeer talen opgedaan moeten worden.

Al met al moet er toch goed nagedacht worden over de keuze. Er moeten verschillende opties overwogen worden. Het eenvoudig ontwikkelen in PhoneGap met HTML, CSS en Javascript of het ontwikkelen met de SDK en het maximale halen uit je applicatie. Het hangt er dus in grote mate van af wat voor applicatie het gaat worden, en wat je uiteindelijke doel hiermee is.

Wordt vervolgd.......

Robin Lutteke

Over Remember the Milk, Toggl, Evernote en Meer

Thu, 10 Nov 2011 20:21:00 +0200

Onlangs mocht ik aan de website CloudTools uitleggen hoe ik online diensten en tools in de praktijk gebruik. Een verhaal over onder andere Remember the Milk, Toggl en Evernote, maar ook over de inzet van Yammer in een intranet bij één van onze klanten.

Het artikel is hier te lezen.

CloudTools is het platform voor online software en SaaS. Hier lees je reviews, tips en nieuws over cloud computing. Een erg goede resource op dit gebied!

Fiddler Gebruiken In Smartsite iXperion TestSuite

Wed, 06 Apr 2011 12:28:00 +0200

Ontwikkelaars die ontwikkelen binnen Smartsite iXperion hebben de mogelijkheid gebruik te maken van de Smartsite TestSuite. Deze windows applicatie maakt het mogelijk de site waaraan ontwikkeld wordt lokaal te draaien, en biedt een groot aantal functionaliteiten die het leven van een Smartsite ontwikkelaar vereenvoudigen. De TestSuite gebruikt in de applicatie een browsercontrol om de ontwikkelde op een lokale webserver zaken te bekijken.

Soms wil je op low-level niveau kijken wat het http verkeer is tussen browser en webserver, en DE tool om dit te doen is Fiddler. Deze tool fungeert als proxy tussen de browser en webserver, en maakt het verkeer inzichtelijk.

Echter is er één probleem: de TestSuite is een .NET applicatie, en .NET omzeilt altijd de proxy wanneer localhost wordt gebruikt. En de server die de TestSuite start draait op localhost.

Een veel aangedragen oplossing voor dit probleem is het aanroepen van de website op http://127.0.0.1.:<poortnummer> (let op de extra punt na 1). De TestSuite server accepteert dit echter niet.

Gelukkig is er een andere oplossing. Binnen Fiddler is het mogelijk om rules aan te maken in de vorm van een .js bestand. Dit bestand is te vinden in Fiddler onder het menuitem "Rules -> Customize rules". In deze file is onder andere de function OnBeforeRequest(oSession: Session) te vinden, waarin code staat die bij elk request die voorbij Fiddler komt wordt uitgevoerd.

Als binnen de OnBeforeRequest de volgende code wordt toegevoegd, is de site binnen de TestSuite ook op http://EmptySix te bereiken:

if (oSession.HostnameIs("EMPTYSIX")) { oSession.host = "localhost:7812"; }

Fiddler vertaalt de host EMPTYSIX in localhost:7812, welk geaccepteerd wordt door de TestSuite webserver. Voor de (TestSuite) webbrowser lijkt het echter een externe host, en wordt de call dus over de proxy gestuurd.

Toegankelijk Websites Bouwen: Veelgemaakte Fouten

Wed, 30 Mar 2011 11:09:00 +0200

Toegankelijk bouwen hoeft niet altijd lastig te zijn; gewoon wat goede vuistregels in de gaten houden. De volgende presentatie is gemaakt voor een interne Yahoo! conferentie voor webdevelopers, en somt nog even een aantal veelgemaakte fouten op.

Common Accessibility Mistakes

View more presentations from Ted Drake

(Via het Yahoo Accessibility Blog)

JQuery Append Performance

Tue, 22 Mar 2011 09:31:00 +0200

Momenteel zijn we bij Communited bezig met een nieuwe versie van onze KenTIC afspraakonline module. Door middel van deze module is het mogelijk om bezoekers van een website afspraken te laten maken, en direct in te schieten in een klantvolgsysteem .

Eén van de zaken die in deze nieuwe versie wordt opgepakt is het webrichtlijnen-proof krijgen van de oplossing. Hierbij worden in de basis afspraakmogelijkheden getoond als select-lists, en wordt door middel van een jquery javascript hiervan een mooi ogende kalender gegenereerd waarin de afspraken worden weergegeven. Op deze manier kunnen ook bezoekers zonder javascriptmogelijkheden een afspraak maken, en hebben bezoekers met javascript een meer intuitieve interface om dat te doen.

Bij de bouw van het script liepen we echter tegen performanceissues aan; zeker in IE7 wat het script nogal traag.

Door middel van Firebug ben ik op zoek gegaan naar de oorzaak. Firebug heeft een aantal mogelijkheden om performance te loggen, waarbij ik dankbaar gebruik heb gemaakt van de console.profile() mogelijkheid. Hierbij heb ik wel eerst even de niet-minified versie van jquery gebruikt, anders zijn de resultaten niet te analyseren.

Het bleek dat de performance vooral zat in de jquery.append() methode. Deze werd in het script veelvuldig gebruikt vanwege; voor elke 5 minuten in de kalender die getoond wordt wordt een div gemaakt, die met .append() werd toegevoegd aan de DOM.

In deze blogpost staat inderdaad beschreven dat .append() inderdaad, wanneer verkeerd gebruikt, een aardige performance-slurper kan zijn. Ik heb dan ook een groot deel van de .append() aanroepen vervangen door simpele string-concatinations, en op die manier het gebruik van .append() zoveel mogelijk beperkt. En wat blijkt: 800 ms van de script execution verdwenen!