“Digitale Transformatie”

Wanneer men het tegenwoordig heeft over bovenstaand buzzword, zal men steevast een aantal technologische evoluties opsommen die een verregaande impact op onze wereld hebben, en bijgevolg ook op de business, (in het bijzonder de IT business). We denken dan Big Data + Analytics, Sociale Media, Cloud en Mobile; de zogenaamde “Nexus of Forces“.

Het is wel waar dat deze nexus nogal wat furore maakt, maar die kan dat, doordat er, onderliggend, een aantal andere technologische evoluties spelen, die het de software engineering wereld mogelijk maken om al deze krachten voldoende te ondersteunen. Evoluties die, als het ware, ervoor zorgen dat de software die deze nexus draaiende houdt, kan worden gebouwd en ontplooid op een beheersbare manier, zonder dat ontwikkelaars ten onder gaan aan de groeiende complexiteit. Een aantal van die evoluties vatten we hier nu samen onder de noemer “Vortex of Enablers”. (Over vele van deze technologieën hadden we het reeds eerder – volg de links voor meer informatie.)

Enablers 1 en 2: Verregaande Virtualisatie met Cloud & Containers

De Cloud is niet meer weg te denken, maar welke technologie gaat er precies achter schuil? Oorspronkelijk werden er enorme sprongen voorwaarts gemaakt door het virtualiseren van machines, en infrastructuur in het algemeen (IaaS). Maar nu zien we de platformen pas echt ook voor ontwikkelaars tot wasdom komen. PaaS platformen zijn, dankzij de verschroeiend harde introductie van Container technologie, uitgegroeid tot de virtualisatiekeuze bij uitstek. Het worden nu zelfs vaker en vaker in de eerste plaats “Container Platformen“. Momenteel zijn Containers niet meer weg te denken uit Software Engineering, en ze zijn ook een belangrijke enabler voor DevOps. Maar het verhaal zal hier nog niet eindigen. Aan de horizon duikt reeds een nog hoger niveau van virtualisatie op: het zogenaamde Serverless Computing (zie ook onze research radar).

Enabler 3: MicroServices

MicroServices zijn de manier bij uitstek waarmee we complexe IT systemen kunnen opdelen in vele kleinere en makkelijker onderhoudbare componenten. Ze zorgen ervoor dat we een verzameling van toepassingen kunnen bouwen die allemaal potentieel klant zijn van elkaar en elk hun stukje van het geheel uitvoeren. Daarnaast zijn ze typisch klein en onafhankelijk, waardoor ze ideaal zijn om uitgerold te worden via een container platform.

Enabler 4: Event Driven Software Engineering

Over Events hadden we het al uitgebreid in vorige blogs. In het algemeen merken we dat dit mechanisme aan populariteit wint om een dynamisch en snel veranderende wereld, die continu nieuwe data genereert, te kunnen vatten in IT.

Events lenen zich dan ook heel goed voor het capteren van data: alles wat in een computersysteem binnenkomt, kan namelijk worden gezien als een Event, en het gebruik hiervan als primaire databron is soms handiger dan wanneer men de ervan afgeleide data zou gaan bewaren. In een overheidscontext zien we bijvoorbeeld de notie van civic moments aan belang winnen, hetgeen eigenlijk niet minder dan business Events zijn voor overheidstoepassingen.

Enabler 5: Steeds Betere Web Raamwerken

Het venster dat de klant krijgt op een IT-toepassing, is de client. Het is dan ook enorm belangrijk dat deze goed is gebouwd en vooral handig is in gebruik. De meeste client toepassingen zijn momenteel webgebaseerd of mobiel, en ook in deze laatste categorie wint webtechnologie gestaag aan belang. Het trio Html, Css en Javascript blijft dan ook de manier bij uitstek om een eindgebruikerstoepassing te bouwen, en elk jaar zien we wel een nieuw raamwerk populair worden in deze wereld; raamwerken die het makkelijker maken om sneller grotere, complexere en mooiere toepassingen te bouwen. Daarnaast wordt deze technologie ook steeds beter ondersteund door de technologie die er aan server-zijde bij komt: we krijgen haast onbeperkte schaalbaarheid en robuustheid wanneer we toestandsloze webtoepassingen gaan hosten op container platformen, gebruik makende van microservices als backend, op hun beurt ontsloten door (vaak RESTful) API’s (en, waarom niet, werkend via node.js).

Enabler 6: API’s

Het aanbieden van een degelijke API is de ideale manier om de functionaliteiten van een IT systeem beschikbaar te stellen aan andere. API’s hebben reeds een hele evolutie achter de rug: eerst waren er vooral (taal-specifieke) programmatorische API’s, daarna werden componenten steeds beter interoperationeel dankzij eerst SOAP-, en daarna REST-gebaseerde API’s. Momenteel zijn er heuse API Management platformen, die, naast beheer van API’s, ook voor de interoperabiliteit van heel wat communicatieprotocollen kunnen zorgen.

Via API’s kan men een sterk hergebruik van data bekomen: gegevens die reeds verwerkt zijn door één toepassing, worden op die manier beschikbaar voor een hele resem andere; vaak zijn dit dan microservices, maar ook frequent client-toepassingen op het web. De API’s worden bovendien vaak ook aangeboden aan derde partijen en daarbij soms ook gemonetariseerd. Uiteindelijk ontstaat er een hele “API Economy”: meer en meer toepassingen ontstaan eenvoudigweg doordat de data die ze nodig hebben, reeds beschikbaar is, en makkelijk consumeerbaar via zo’n API.

De Vortex

De relaties tussen de verschillende opgesomde technologische evoluties hier beschreven, zijn duidelijk waar te nemen: dit blijkt reeds uit de tekst. Op dit moment hebben we dan ook een unieke smeltkroes: de effecten van deze enablers op software engineering versterken elkaar, en vormen zo het fundament van de vele zaken die er bovenop worden gebouwd: de digitale economie.

Er was eens… een metrorit. En voor metroritten heb je tegenwoordig een MOBIB-kaart nodig. Dit deed me terugdenken aan het verhaal van de smartcards, en hoe we er veel te veel nodig hebben… Bij deze dan het lang beloofde derde deel van dat verhaal.

Over Metro- en Treinkaarten

Onlangs moest ik na lange tijd nog eens de metro nemen. Ik wist dat mijn papieren kaartje met magneetstrip ondertussen niet meer geldig zou zijn: de overschakeling naar MOBIB is nu volledig doorgevoerd. De MOBIB-kaart is RFID technologie, waardoor je ze kan gebruiken door ze gewoon tegen een kaartlezer tegen te houden (je hoeft ze nergens in te steken). Meer over deze technologie kan je terugvinden in één van onze techno’s: Het ABC van RFID.

Nu, ik heb reeds een treinabonnement, en ook dit staat op een MOBIB-kaart… van de NMBS. Ik moest er dus achter zien te komen of ik deze ook voor de metro kon gebruiken. Na wat zoekwerk, zag ik dat ik online een account kon aanmaken bij de MIVB en dat ik een bestaande MOBIB-kaart kon koppelen aan mijn account. Wanneer ik dit echter probeerde, wist het systeem mij te vertellen dat mijn kaart niet gekend was, maar dat dit wel het geval zou zijn indien ik deze eerst kon opladen via één van de GO-machines in de metrostations.

Zo gezegd zo gedaan, en – wonder boven wonder? – dit werkte inderdaad zoals aangegeven: ik kon mijn NMBS-kaart gebruiken als houder voor het saldo van mijn metroritten, en ik kon deze kaart daarna ook effectief koppelen aan mijn online profiel bij MIVB. (Eén mankement: het resterend saldo aan ritten is niet zichtbaar; maar misschien is dit ook voor de eigen kaarten van MIVB geen feature? – graag een comment indien iemand dit weet!)

Wat leren we nu uit dit verhaal?

• Ten eerste, de technologische mogelijkheden om het probleem van het teveel aan kaarten in mijn portefeuille op te lossen, zijn reeds duidelijk aanwezig, maar, gezien het aantal kaarten dat ik nog nodig heb, is er nog geen verregaande implementatie gebeurd (zo is mijn abonnement bij De Lijn, verkregen via NMBS, nog steeds een stukje papier, en een koppeling met bijvoorbeeld de Belgische eID is nog steeds beperkt tot de occasionele online aankoop van een treinticket). Conclusie: nog steeds geen one card to rule them all…
• Ten tweede: de netwerken van MIVB en NMBS zijn voorlopig nog onvoldoende geïntegreerd om reeds bij de aanmaak van een nieuwe kaart bij één firma, rechtstreeks ook de nodige gegevens te versturen aan de andere. Op zich is dit soort integratie misschien nogal veeleisend, maar in deze nieuwe wereld van de IT, met zijn Cloud, zijn microservices, en vooral, zijn API economy, zijn er toch wel een aantal architecturen te bedenken waarin dit geen probleem zou mogen zijn. Het “only once principe” is echter vaak meer een verhaal van politiek en economie, dan van technologie.

“Card Management as a Service”

Ik zou hier graag reeds even vooruitblikken op een toekomstige blog, waarin ik de voordelen van een gescheiden beheer van gegevensnetwerken versus er van gebruik makende toepassingen wil toelichten: Stel dat we één instelling hadden die het beheer van de kaarten en de ermee gepaard gaande gegevens, netwerken en basisdiensten op zich nam, en dat de andere bedrijven, zoals de vervoersmaatschappijen in kwestie, van deze diensten gebruik maakten. Dit zou ervoor zorgen dat alles wat met kaarten te maken had, efficiënter zou kunnen worden gemaakt wegens schaalvoordelen, én dat de vervoersmaatschappijen zelf deze verantwoordelijkheid niet meer hoefden te dragen. Dit is eigenlijk precies één van de belangrijke verwezenlijkingen van Cloud, en, meer in het bijzonder, het “as a Service” verhaal, maar dan toegepast op chipkaarten. Daarnaast kan men het ook bekijken in een microservices en API context (“you build it, you run it”).

Hierover dus later meer. Waar ik het nu verder over wil hebben is de toekomst…

De Nabije Toekomst?

Vandaag is het reeds mogelijk om met je smartphone vervoersbewijzen aan te kopen, betalingen te doen, ja, zelfs jezelf te identificeren voor gebruik van overheidstoepassingen. Een toekomst waarin we geen kaarten meer nodig hebben, maar waarin deze volledig zijn vervangen door de smartphone, is dus zeker technisch realiseerbaar, en op lange termijn misschien zelfs realistisch. Het belangrijkste probleem hierbij is er één dat slechts langzaamaan kan worden opgelost: de logistiek van het on-boarden van alles en iedereen die nu nog met kaarten werkt, en van alles en iedereen die nu nog geen smartphone heeft. In een nog verdere toekomst zullen we misschien zelfs de portefeuille in zijn geheel kunnen afschaffen, indien we dit ook met het systeem van cash geld zouden doen!

Science Fiction

Wat als we dan nog eens een paar decennia verder in de toekomst kijken? We zien reeds nu zaken opduiken als bio-authentication, waarbij we onze vingerafdrukken, stem, gezicht, of zelfs context gebruiken om te authenticeren. Daarnaast doet men ook gericht onderzoek naar nanotechnologie, robotica, artificiële intelligentie, Internet of Things, … Allemaal zaken die ervoor zorgen dat technologie en ons lichaam steeds dichter bij elkaar komen en uiteindelijk zelfs kunnen worden samengevoegd.

Uiteindelijk zou het dan mogelijk worden dat de smartphone wordt vervangen door een scherm op de huid van onze arm (zie filmpje hierboven voor wat binnenkort al kan!), met alle nodige technologie netjes verborgen aan de binnenkant van ons lichaam! Sterker nog: het scherm zou evengoed virtueel voor onze ogen kunnen worden getoverd, dankzij technologie rechtstreeks in onze ogen of hersenen. Op die manier hebben we niets meer nodig: al het nodige dragen we steeds met ons mee, zoals we dat met ons lichaam doen. En onszelf identificeren om ons vervoersbewijs te legitimiseren, doen we door eens te wuiven.

Op zich een groot gemak, maar uiteraard is hier ook een duistere zijde aan verbonden: het zou wel eens heel moeilijk kunnen worden om “off-the-grid”, of “offline” te gaan, of om zonder al deze technologische snufjes te kunnen. Sterker nog: we zouden Big Brother scenario’s kunnen krijgen, of een regelrecht doembeeld, zoals in de film “In Time“. Maar goed: wat er met een technologie gedaan wordt, staat los van de technologie zelf (ook met een eenvoudige hamer kan je zowel bouwen als verwonden).

Besluit

Er staan ons nog een aantal wonderlijke technologische evoluties te wachten, maar er blijft vooral nog veel werk aan de winkel wat betreft het vereenvoudigen van het leven van de gewone burger, met al zijn chipkaarten, zijn smartphone en zijn muntjes van twee eurocent, en van alle administratie die daarbij komt kijken. Samenwerking, integratie, en het zo breed mogelijk invoeren van het only once principe zijn de boodschap.

Tegenwoordig gebruikt men voor het bouwen van een website of web-applicatie technologie die heel anders is dan 20, 10, of zelfs 5 jaar geleden. Anderzijds zijn er een paar zaken nog altijd hetzelfde. Bovendien gebruikt men deze technologie om steeds nieuwe, en vaak complexere en mooiere sites en applicaties te bouwen – maar anderzijds maakt men ook nog altijd eenvoudige websites. In deze blobg bespreken we een recente evolutie die al een handvol jaren komende is, we noemen deze de “Frameworks Blob”.

To Enterprise, or not to Enterprise?

Wat het bouwen van websites en webapps betreft, volg ik al een tijdje welke zaken hip zijn, welke zaken uit de mode geraken, en welke zaken er in de nog aparte wereld van “Enterprise” development gebeuren. Naar mijn mening vindt er nu een interessante evolutie plaats: meer en meer professionele software huizen (“enterprises”, dus) gebruiken – of bekijken op z’n minst – technologie die minder als “Enterprise” technologie gezien wordt.

Maar wat is Enterprise technologie dan wel? Volgens de definitie is het eigenlijk gewoon ‘technologie ontwikkeld op maat van bedrijven i.p.v. individuele gebruikers’. Waar velen van ons – of ik toch – echter aan denken wanneer we het woord “Enterprise-ready” horen vallen is: matuur, stabiel, zwaar, complex, full-blown en moeilijk. Kortom, technologie die, beter dan andere, goed werkt als ze goed gebruikt wordt, maar niet fijn is om goed te gebruiken.

Anno 2010, Blob as Usual

Op onderstaand assenstelsel heb ik weergegeven op welke manier de meeste applicaties worden ontwikkeld. De horizontale as toont de complexiteit van de website of -app: links heb je de meest eenvoudige websites, rechts de meest complexe en “mastodontale” web-applicaties. Op de verticale as heb ik een aantal technologieën, talen, pakketten, methodologieën… kortom bouwstenen geplaatst die kunnen worden gebruikt om deze webprojecten mee te ontwikkelen. Bovenaan staan de eenvoudigste: zaken zoals Html, de elementaire bouwsteen van het web, en Javascript, een taal die men rechtstreeks in de browser kan gebruiken. Onderaan vinden we meer en meer “enterprisey” technologieën terug: zaken zoals SOAP, J2EE en – huiver – Cobol (jawel, zelfs voor web 2.0). Het is uiteraard voor discussie vatbaar waar welke bouwsteen juist op deze as thuishoort. Bovendien kunnen dergelijke technologieën en talen verschuiven op deze as: ze kunnen minder, of juist meer “enterprisey” worden, naarmate ze matuur worden.

De groene “Blob” tenslotte, is waar, volgens mij, het grootste gewicht van alle web development gebeurt: traditioneel en logischerwijs worden dus de meeste eenvoudige sites en applicaties met eerder eenvoudige technologieën gebouwd. Zware en complexe applicaties worden echter – vaak terecht – met enterprise-ready technologieën gebouwd. Business as Usual…

 Anno 2014, the Blob deforms…

Zoals in het begin reeds gezegd: meer en meer web development schuift weg van technologie die te “Enterprise” is, richting lichtere raamwerken die alles in het werk stellen om het bouwen van webapplicaties zo snel en eenvoudig mogelijk te maken. In de onderstaande figuur vertaalt zich dit in een verschuiven van de onderkant van de “blob” naar boven toe: dus ook voor complexere applicaties worden nu meer en meer lichtere en kleinere bouwstenen gebruikt.

Wat we bovendien ook nog zien, is een soort van deformatie; een bochel op de blob, als het ware. Deze wordt veroorzaakt door de recente evolutie van de Javascript raamwerken, zoals AngularJS en Meteor. Deze raamwerken baseren zich op de meest eenvoudige technologieën (Html, Javascript en Css), maar bieden tegelijk een zeer krachtige ontwikkelaarservaring, waardoor men via weinig werk toch enorm veel resultaat kan boeken. Het zal dus niet verbazen dat steeds meer web-projecten van dit soort raamwerken gebruik maken, zeker als het gaat om het beheersen van complexiteit. En dat verklaart dus meteen de bult op de blob!

Zal de blob in de toekomst nog op andere manieren vervormen? De Kerstman kan het ons misschien vertellen…

Vrolijk Sinterklaasfeest  !

Zapier est un service en ligne permettant de faire interagir des services internet afin d’automatiser des tâches répétitives. Ainsi, par exemple, vous pouvez envoyer un e-mail à chaque nouveau suiveur sur Twitter. Zapier supporte de nombreux services internet notoires comme Facebook et Dropbox, mais aussi des fonctionnalités de base comme rss. Au total, plus de 300 services sont déjà disponibles actuellement.

Flipboard permet de regrouper des données provenant de divers sites (Twitter, LinkedIn, Youtube, Flicker, Google Reader, …). Chaque source de données est ensuite présentée sous la forme d’un magazine électronique.

Wanneer je je RSS feeds, mails, berichten op Twitter, LinkedIn en dergelijke consulteert, kom je regelmatig artikels tegen die je interessant lijken maar die je niet meteen kunt lezen. Dankzij Pocket en de bijbehorende webservice beschik je over een oplossing waarmee je alle artikels kunt bewaren die je later nog wil lezen zonder het risico te lopen dat je ze niet meer terugvindt.

Feeddler Pro is een uitstekende RSS feed reader voor iPad die eenvoudig, snel en gebruiksvriendelijk is en werkt op basis van Google Reader.

Persoonlijk heb ik er tegenwoordig een veertigtal in LastPass zitten, het programma dat ik momenteel gebruik en waar ik een tijdje terug een quick review van schreef. En dan zitten sommige sites er nog niet in, gewoon omdat ik ze al een tijdje niet meer heb gebruikt!

In deze blog wil ik kort de weg beschrijven die ik heb afgelegd om bij mijn huidige product te komen, en tussendoor doe ik een kleine vergelijkende studie, zodat ik de wildgroei van deze producten wat kan bijsnoeien voor de potentiële nieuwe gebruiker…

In den beginne…  kocht ik mij een Sandisk Cruzer Titanium U3 edition. Dit is een usb-stick, en dit was ongeveer 7 jaar geleden. Wat deze stick speciaal maakt, is het U3-systeem: dit is een programmaatje dat opstart wanneer je de usb-stick in je computer plugt en je een soort alternatief startmenu biedt, bestaande uit programma’s die geïnstalleerd zijn op de stick. Op die manier heb je overal je favoriete programma’s bij. U3 wordt tegenwoordig niet meer verder ontwikkeld (Microsoft is in samenwerking met Sandisk wel met iets nieuws bezig), maar er is wel een open source alternatief: PortableApps, reeds beschreven in een quick review door mijn collega Gregory.

Welnu, op dit U3 systeem stond een demo van de tool SignupShield, van het bedrijfje Protecteer. Dit was mijn eerste kennismaking met een password manager en de tool vergemakkelijkte mijn leven zodanig, dat ik na een half jaar besloot om ze effectief aan te kopen, toen voor een 30-tal dollars. SignupShield slaat je paswoorden lokaal op je systeem op, of, in het geval van de U3-versie die ik had, op je usb-stick. Wanneer je dus de stick bijhebt, kan je van de tool gebruikmaken.

Wat zeer handig is aan SignupShield, is de mogelijkheid om op een tasktray icoontje te klikken, waardoor je een menu krijgt waarmee je onder andere rechtstreeks op één van je accounts kan klikken, waardoor een browser wordt gestart en je automatisch wordt ingelogd.

Er waren echter ook dingen die mij stoorden aan SignupShield: het belangrijkste dat het niet voor alle websites even goed werkte. Zodoende ging ik op zoek naar een nieuwe tool. Die vond ik snel onder de vorm van RoboForm, welke ook een U3-versie had. Dit was een vijftal jaar geleden.

Roboform, de huidige marktleider voor deze producten, biedt ongeveer dezelfde mogelijkheden als SignupShield, maar werkt net iets beter en heeft iets meer mogelijkheden voor het vullen van formulieren met al je gegevens, zoals je vaak moet doen bij registraties. Bovendien kon mijn tool deze keer alle websites aan. Net zoals SignupShield, werkt de demo-versie van Roboform tot 10 paswoorden; indien je meer accounts wenst op te slaan, moet je de betalende versie aankopen.

Zoals je in de intro van deze blog al kon lezen, is 10 accounts hopeloos ontoereikend voor mij, en een dik jaar geleden kocht ik mij dan ook die betalende versie.

Ergerlijk genoeg herhaalde de geschiedenis zich en was ik, kort na mijn aankoop, niet meer tevreden over mijn product. De ondersteuning voor usb-devices die automatisch opstarten wanneer je ze in je pc plugt, werd namelijk herhaaldelijk teruggeschroefd in Windows Vista en Zeven. Op die manier werd het dus vrij onhandig voor mij om een U3-tool te gebruiken. Bovendien ontdekte ik op dat moment eveneens het nakende einde van de U3-technologie. Om mijn consternatie nog groter te maken: ik leerde op dat moment ook diensten kennen zoals Remember the Milk, die al je gegevens online opslaan en werken via browser-plugins of gewoon, via hun eigen site. Met zo’n dienst heb je zelfs geen usb-stick meer nodig, enkel een internetverbinding.

Roboform bood evenwel nog een oplossing: je kon de tool ook rechtstreeks op de desktop installeren, en over je verschillende devices synchroniseren met behulp van een andere tool van dezelfde makers. Deze tool was echter betalend! Een IT’er stoot zich geen drie keer aan dezelfde steen, bedacht ik mij, en dus ging ik deze keer op zoek naar een gratis alternatief.

Kleine noot tussendoor: tegenwoordig biedt Roboform rechtstreeks een dienst aan waarbij je gegevens online worden opgeslagen en over al je devices worden gesynchroniseerd: Roboform Everywhere. Deze dienst kost 20 dollar per jaar.

Maar ik ging dus op zoek naar een gratis product, dat liefst ook nog beter werkte dan Roboform. Na wat rondsurfen vond ik verschillende alternatieven, maar al gauw kwam ik tot de conclusie dat LastPass voor mij de meest geschikte tool was. LastPass kan je gebruiken, zowel via hun website, of via browser-plugins. Deze laatste optie biedt heel wat gebruiksgemak, met onder andere autologin naar al je accounts vanuit een menu dat beschikbaar is via een knopje in de browser. Ok, wanneer ik geen browser open heb, duurt dit iets langer dan via een task-tray icon te gaan, maar tegenwoordig ben ik zo plugged in dat ik quasi altijd toch een browser open heb. Bovendien is dit – indien nodig – een cross platform methode (dus over verschillende operating systemen en browsers heen).

Bij LastPass zit het online opslaan van je paswoorden ingebakken in het concept. Ze zijn echter Geëncrypteerd, en de beheerders hebben niet de mogelijkheid om ze te lezen. Enkel de gebruiker kan dit, via zijn master password. Perfect veilig kan het natuurlijk niet zijn: wanneer je je Master Password niet goed genoeg beschermd, zijn je gegevens in gevaar. Bovendien is een eventuele aanval op je browser mogelijk in staat om tijdelijk gedecrypteerde gegevens te stelen. In de praktijk zal dit echter niet zoveel voorkomen. De makers van LastPass zijn er zich uiteraard van bewust dat hun platform een doelwit is, en doen er dan ook alles aan om de beveiliging zo hoog mogelijk te maken. Een deel verantwoordelijkheid rust natuurlijk, zoals altijd, bij de gebruiker. Goed je browser up-to-date houden dus, en af en toe van master password veranderen.

Heel kort heb ik ook de tool KeePass uitgeprobeerd. Deze ondersteunt echter out-of-the-box geen features zoals online synchronisatie en autologin functionaliteit. Achteraf heb ik me laten vertellen door mijn collega Gregory, die van KeePass een review schreef in onze Open Source Inventaris, dat dit mogelijk wordt via plugins. Hoewel deze tool potentieel iets veiliger is dan LastPass, was dit soort configuratie voor mij toch iets teveel rompslomp.

De drie (of vier, als je KeePass meetelt) reeds genoemde tools zijn de enige die ik zelf effectief heb uitgetest, maar met wat rondsurfen kan je al snel het kaf van het koren scheiden:

Iemand die naast keepass en lastpass ook nog ewallet probeerde:
http://www.40tech.com/2009/06/30/password-manager-shootout-ewallet-vs-keepass-vs-lastpass/

Nog een vergelijking van lastpass met een ander goed product:
http://www.40tech.com/2011/05/16/lastpass-vs-1password-whose-syncing-method-is-more-secure/

Vergelijkingen van te installeren en te kopen tools, waaruit blijkt dat roboform nog zo slecht niet is:
http://password-management-software-review.toptenreviews.com/
http://best-password-managers-review.gorungoreviews.com/compare-chart.asp

Reviews van LastPass, vergelijkend met Roboform, waaruit blijkt dat LastPass toch iets beter wordt gevonden:
http://www.thetechherald.com/article.php/200930/4129/Review-LastPass-password-manager
http://theaveragegenius.net/lastpass-vs-roboform-password-security-software-battle/

Mijn persoonlijk besluit is dus dat ik geen password manager producten meer ga aankopen. Ik ben erg tevreden met de gratis versie van LastPass, en overweeg eventueel wel om in de toekomst het premium abonnement eens uit te proberen. Huren dus, niet aankopen

Ainsi ce weekend j’ai été surpris de découvrir un outil de mindmapping (gratuit) en SAAS : Mind42.com.

J’ai d’abord été amusé par la simplicité de l’outil, en comparaison avec des outils standalone tels que FreePlane, Xmind ou le haut de gamme Mind Manager, avant de me persuader que dans le cadre d’un projet faisant intervenir différents partenaires, simplicité et mode SAAS pouvaient justement constituer un bel avantage en termes d’efficacité dans la collaboration.

Voici,  à titre d’exemple, un relevé,  de quelques applications bureautiques en mode SAAS.
http://perso.univ-lille3.fr/~rlecerf/?Mes-travaux:Formation:Outils-Web-2.0—Bureautique

Cet inventaire est aussi à mettre en rapport avec le sucès des technologies du Web 2.0, en particulier le recours de plus en plus prononcé au Javascipt et à Ajax (voir le RIA en général). Les futures applications de type client riche seront-elles toutes demain basées sur cette approche? Avec en filigrane le souci de gommer les frontières entre les différents devices : pc , netbooks, tabletpc, smartphone, … (sachant bien évidemment que taille d’écran et puissance du processeur conditionnent les fonctionnalités accessibles).

Le nomadisme en IT est de plus en plus une réalité. Devices mobiles, technologies du Web 2.0 et mode SAAS en seront vraisemblablement les piliers technologiques.

La conjonction du nomadisme et du besoin accru pour le travail collaboratif (un important gisement de productivité encore mal ou sous-exploité) vont doper le phénomène SAAS.

Pour terminer, un dernier mot sur le mind mapping : l’utilisation de cet outil de conception dans le groupe de travail qui construit les premiers modules de elearning pour les soins de santé est révélateur de l’aptitude de ces outils à fédérer et organiser rapidement les idées d’un groupe.

Maar wat bedoel ik dan met deze “zware” internet applicaties? In tegenstelling tot FIA, zal iedereen allicht al ooit wel eens hebben gehoord van RIA – Rich Internet Applications. Dit zijn webapplicaties met een rijke gebruikersinterface, m.a.w. webapps die er “goed” uitzien en de interactiemogelijkheden bieden van traditionele desktop applicaties.

Waar men misschien ook al eens van heeft gehoord, zijn Fat Clients, een gemakkelijk bekkende naam voor Heavyweight Clients. Deze zware clients zijn desktop applicaties die een deel van het werk van een server op zich nemen, en dus lichtere servers toelaten – in tegenstelling tot Thin Clients. De kracht van de gebruikers eigen machine wordt op die manier nuttig gebruikt. Fat clients waren een natuurlijke evolutie toen de machine van de eindgebruiker beter werd en zware mainframes uit de mode geraakten. Van terminal-mainframe communicaties ging men dus over op client-server. Later, dankzij de populariteit van het web, is men dan uiteindelijk overgeschakeld op webserver-RIA-browser.

Fat Internet Applications vormen dan een mengsel van RIA met fat clients. Fat clients dus, maar dan in de vorm van een webapplicatie. Een internettoepassing, zeg maar, die een deel business logica bevat om de server – en de netwerkverbinding met de server – te ontlasten. En omdat men niet meer anders kan tegenwoordig, zal deze er ook goed moeten uitzien, en dus een RIA zijn. Men kan zelfs stellen dat FIA’s een evolutie zijn op RIA’s, en dat sommige RIA’s eigenlijk al FIA’s kunnen worden genoemd. Niet alle bestaande RIA’s zijn echter noodzakelijkerwijs FIA’s. Het al dan niet rich zijn heeft eigenlijk niets te maken met het al dan niet fat zijn, en een aantal RIA’s ondersteunen vooral de Look & Feel van de app, en gebruiken de server voor het grootste deel van de achterliggende logica.

Aan de invoering van FIA’s zijn een aantal voor- en nadelen verbonden. Allereerst een nadeel: men moet aan dubbele validatie doen van de ingevoerde gegevens. Een eerste keer in de client, zodat deze er zonder gevaar mee kan werken, en een tweede keer aan de serverkant, omdat men nooit kan garanderen dat het wel degelijk een zich goed gedragende client-applicatie is, die met de server communiceert. Vooral dit tweede zou men al eens kunnen vergeten…

Het grote voordeel is natuurlijk dat zware operaties door de client kunnen worden uitgevoerd. Denk maar aan compressie of encryptie van gegevens. Dit opent een aantal deuren voor applicatieontwikkelaars, die er bij het gebruik van thin clients niet waren. Zo kan men tegenwoordig een applicatie maken voor online gegevensopslag, waarbij de gegevens door de client geëncrypteerd worden. Dit is niet alleen performanter, maar ook veiliger, want de gegevens hoeven niet eens in onvercijferde vorm naar de server te worden gestuurd.

Spijtig genoeg is het momenteel wel mogelijk, maar nog niet zeer vanzelfsprekend om een FIA te bouwen. Er zijn namelijk een aantal zaken nodig, die men vaak slechts door gebruik van plugins ter beschikking heeft in webapplicaties. Om een zeer responsieve gebruikersinterface te hebben, kan het bijvoorbeeld nodig zijn multithreading toe te passen, zodat de user interface niet ‘hangt’ tijdens een zware berekening. Bovendien zou een FIA wel eens veel geheugen kunnen vragen, hetwelke het misschien niet altijd krijgt van de browser.

Momenteel is het nog erg lastig om, gebruikmakende van enkel javascript, een FIA te maken. Technologieën zoals Flash en Silverlight laten dit wel al toe, maar vereisen uiteraard een browser plugin. Er is dus nog nood aan betere frameworks en browserondersteuning.

In mobile devices heeft men een andere oplossing dan browser-plugins: dit zijn de native apps. Deze kunnen gebruik maken van de uitgebreide functionaliteit van het toestel, omdat ze buiten de browser opereren. Het grote nadeel hiervan is natuurlijk dat zulke apps voor elk soort device opnieuw moeten worden geschreven – eigenlijk zijn het gewoon fat clients die eruitzien als een webapp.

Misschien zorgt Html 5 voor een stap in de goede richting. Met Html 5 wordt het mogelijk om stukken javascript code in een aparte thread uit te voeren, wat voor een vorm van concurrency kan zorgen in de applicatie. Verder zal er in de nieuwe markup taal een soort lokaal geheugen voorzien zijn voor applicaties. Op die manier wordt het terug mogelijk om FIA’s te bouwen voor elke browser die Html 5 ondersteunt, zonder dat deze plugins nodig heeft, waardoor men dus platformonafhankelijk zou kunnen ontwikkelen.

Besluit? Het internet van morgen zal zowel de voordelen van internet-connectiviteit kunnen nuttigen, als de voordelen die ontstaan uit steeds krachtiger wordende client-devices, zowel vast als mobiel. De technologie om dit mogelijk te maken is in volle ontwikkeling en Fat Internet Applications zijn begonnen aan hun opmars.