De highlights van de European Collaboration Summit en Cloud Summit 2021

Blog

Sinds lange tijd is het mogelijk om weer een congres bij te wonen. Samen met twee collega’s ben ik op maandag 29 november naar Düsseldorf gereden.

Nadat we waren ingecheckt, hebben we drie steps gehuurd om naar het congrescentrum te gaan en onze registratie te voltooien. Dit bleek een goed idee: er was nog niemand aanwezig dus we konden rustig onze badges ophalen.

De volgende dag zijn we vroeg opgestaan om op tijd te gaan ontbijten. Bij het ontbijt blijkt al dat bijna alle hotelgasten deelnemers of sprekers zijn van het congres. Na het ontbijt in de auto. Het weer is erg slecht, dus vandaag geen step.

Aangekomen bij het congres laten we onze QR-codes en identiteitsbewijzen zien om toegang tot het congres te krijgen. Om aan te geven dat iedere dag iedereen werd gecontroleerd bij binnenkomst, werd per dag een andere kleur sticker gebruikt.

De keynote

Als eerste ga je, zoals altijd, naar de keynote. Deze begon anders dan je van te voren had verwacht, namelijk met een zandkunstenaar. Dit was een mooie verrassing.

Daarna nam Mike Fitzmaurice het woord op zijn gebruikelijke manier - met veel energie - om iedereen welkom te heten. Ditzelfde werd daarna gedaan door Spencer Harbar. Hierop volgde een videosessie door Jeff Teper, corporate vice president Microsoft 365. Hij deelde een overzicht van wat voor hem de belangrijkste aankondigingen zijn geweest op Ignite. Hierbij kan Microsoft Loop natuurlijk niet ontbreken.

Na de opening vonden er twee verschillende keynotes plaats, omdat het een gecombineerd congres was. Ik ben gegaan voor de keynote van de Cloud Summit.

KEYNOTE Cloud Summit

Deze keynote werd gegeven door Clemens Vasters, Lead Architect for the messaging and eventing services binnen het Microsoft Azure portfolio. Het is dan ook vanzelfsprekend dat deze sessie ging over message en eventing services. Een interessant verhaal waarbij verschillende types zijn besproken en een aantal best practices gedeeld.

Zo gaf Clements bijvoorbeeld aan dat wanneer je met jobs werkt, je altijd queues moet gebruiken om zo de load te kunnen verdelen. Hierdoor bouw je een stabielere en betere oplossing.

De sessies

Toen beide keynotes voorbij waren en we een koffie break gehad hadden, was het tijd voor alle sessies. Een mooi detail is dat alle koffiebreaks in de Expo hal waren. Hierdoor werden de sponsors goed bezocht. Ander leuke gimmick was dat ze een virtuele munt hadden die je kon verdienen door een QR-code te scannen bij de sessies en de evaluatie in te vullen. Daarbij kon je extra munten verdienen als je een sponsor bezocht. Van deze munten kon je vervolgens allerlei swag krijgen en ook korting op het kaartje voor de Cloud Summit van 2022.

De agenda was vol, per tijdslot keuze uit ongeveer 8 sessies. Door corona waren er wel wat afzeggingen, zowel onder sprekers als deelnemers. Maar de organisatie heeft dit goed opgepakt en waar mogelijk ook weer opgevuld met andere sessies.

Hierbij een paar belangrijke zaken die mij zijn opgevallen tijdens de sessies die ik gevolgd heb.

Conditional Access & App Controls

Deze sessie is mij het meest bijgebleven en werd gegeven door Nicki Borell. Hierin werd goed uitgelegd wat je kan doen met Microsoft Defender for Cloud Apps (voorheen Microsoft Cloud App Security) in combinatie met Conditional Access. Met Microsoft Defender for Cloud Apps kan je verschillende applicaties blokkeren of juist op voorwaarde toestaan.

Voordat je apps kunt beveiligen met deze oplossing, moet je ze eerst verbinden. Voor Microsoft 365 en Azure kan je dit vrij makkelijk doen, omdat deze al bekend zijn binnen het portaal, maar je moet ze wel toevoegen. Wanneer je een third party applicatie wilt koppelen, moet je een wizard doorlopen en daarbij alle gevraagde gegevens opgeven, zoals authenticatie URL e.d.

Wanneer een applicatie gekoppeld is, kan je deze voorzien van verschillende policies. De eindgebruiker ziet onderstaand scherm wanneer bijvoorbeeld Teams geopend wordt.

Binnen een policy kan je verschillende instellingen definiëren. Een voorbeeld hiervan is dat wanneer je inlogt vanaf een onbeheerd apparaat, je dan geen documenten mag downloaden. Of je mag het wel downloaden, maar de download wordt dan voorzien van een sensitivity label, als deze nog niet gekoppeld is.

Misschien is het beste advies nog wel dat je altijd moet beginnen met de scenario’s en bepalen wat je wilt bereiken. Wanneer dit duidelijk is, weet je wat je moet inrichten en dus ook welke licenties je hiervoor nodig hebt.

All About Microsoft 365 Sensitivity Labels

Deze sessie werd gegeven door Tony Redmond en vertelde hij over alles wat te maken heeft met sensitivity labels, zoals de titel al verklapt.

Een belangrijke les die ik heb meegenomen uit deze sessie is dat je geduld moet hebben wanneer je gaat werken met sensitivity labels, de policies worden namelijk elke vier uur vernieuwd.

Mits je de juiste licenties hebt, kan je ook automatisch gaan labelen. Dit klinkt heel mooi, en dat is het, maar kan wel lang duren. Gemiddeld worden er ongeveer 25 duizend documenten per dag voorzien van een label.

Een ander goed punt is dat labels twee verschillende rollen hebben. Het beschermen van documenten en/of e-mails en het beschermen van een gehele container. Een container kan zijn:

  • Microsoft Team
  • SharePoint Site
  • Microsoft 365 Group

Wanneer je een document in een container plaats wordt deze beschermd door het label van de container. Echter wanneer je dit document uit de container haalt, zullen de instellingen niet meer gelden.

Een paar tips die we hebben meegekregen zijn:

  • Gebruik verschillende labels voor containers en documenten
  • Maak de inrichting zo simpel mogelijk
  • Gebruik duidelijke namen en sorteer ze op basis van sensitiviteit
  • Verwijderd nooit een label. Gebruik hiervoor het depubliceren.

En nog veel meer…

Uiteraard hebben we nog veel meer interessante sessies gezien, onder andere over Power BI, Kubernetes en een ‘robot’ voor het organiseren van een vergadering. Als ik over alle sessies zou schrijven wat we daar hebben opgepikt, schrijf ik bijna een heel boekwerk bij elkaar. Ik houd het dus even hierbij.

We houden de ontwikkelingen nauwlettend in de gaten en zullen ook in 2022 weer events bij ShareValue organiseren en blogs schrijven om jullie op de hoogte te houden. Mocht je nu al met specifieke vragen zitten, laat het dan gerust weten. Mijn collega’s en ik zijn altijd bereid om mee te denken naar de beste oplossing voor jóuw uitdaging.

Barry
Auteur Barry Consultant & Architect

Heb je vragen over dit onderwerp of zou je Barry willen inhuren voor een vergelijkbare opdracht?

Neem contact met ons op

Gerelateerde artikelen

Wietze Wietze / 01-12-2021

5 minuten lezen

Front-End developers weten dat de ontwikkeling van Front-End technieken nooit stil staat. De ontwikkeling van frameworks als React, Vue, Angular en Svelte is de laatste jaren flink gegroeid. Daarnaast komen er steeds vaker handige tools beschikbaar die het leven van een frontender net iets makkelijker kunnen maken. Deze keer kijken we naar Storybook en wat de meerwaarde hiervan kan zijn zowel voor een developer als voor andere disciplines. In eerste plaats moeten we weten wat Storybook is, en waar het voor gebruikt kan worden.

Wat is Storybook?

Het maken en onderhouden van een style guide is over het algemeen een uitdaging. Storybook is een open source framework dat het eenvoudiger maakt om de user interface van projecten te bouwen, documenteren, testen en demonstreren.

Storybook kan gebruikt worden als playground voor UI componenten. Doordat Storybook zelf buiten de applicatie draait, kunnen we het gedrag van de componenten in Storybook aanpassen naar een gewenste situatie, zonder dat dit invloed heeft op de componenten in de applicatie.

De huidige versies van Storybook ondersteunen functionaliteiten die een groot aantal onduidelijkheden in de moderne workflow voor webontwikkeling opvult.

Storybook ondersteunt de meest gangbare Front-End frameworks van het moment zoals React, Vue en Angular, maar is ook vanuit native JavaScript te gebruiken.

Wat is de story van Storybook?

Uit de behoefte om componenten in een geïsoleerde omgeving te kunnen definiëren, developen en de UI te kunnen testen, begon Storybook in april 2016 met een eerste release van versie 1.0 vanuit de Kadira startup (de originele developer van Storybook), waarna in september van het zelfde jaar versie 2.0 vrijgegeven werd.

Na dat de startup werd stopgezet en het project dood werd verklaard, volgde er een korte break en werd het project in 2017 door de open source verder omarmd. Inmiddels is versie 6.3 gereleased (juni 2021). De hele storybook story is te vinden op https://storybook.js.org/blog/the-storybook-story/

Storybook stopgezet door Kadira

Ondertussen hebben ze meer dan 10.000 github stars en 290k maandelijkse downloads.

Wie kunnen Storybook gebruiken en hoe?

Developers binnen het team zullen Storybook gebruiken als werkruimte om componenten op dezelfde manier neer te zetten. Een voordeel is dan ook dat de opgedane kennis van Storybook te gebruiken is bij elk framework dat momenteel door Storybook ondersteunt wordt.

Storybook kan opengesteld worden voor externe developers, wat interessant kan zijn voor open source ontwikkeling. Hiervoor kan Storybook vooral ingezet worden als documentatie waarbij de API van de componenten wordt uitgelegd.

Voor UX/UI designers kan Storybook als onderdeel dienen van hun design system met koppelingen naar o.a. Frontify waardoor het als gemeenschappelijk bron kan dienen. Als er aanpassingen gedaan moeten worden of er een nieuw component ontwikkeld is, hebben ze gelijk alle (nieuwe) componenten tot hun beschikking

Naast dat het documentatie oplevert, heeft het nog een voordeel dat de stakeholders sneller een nieuwe component kunnen beoordelen op het design en functionaliteit en niet afhankelijk zijn van een nieuwe release. Ook kan Storybook gebruikt worden voor verdere communicatie binnen of buiten het bedrijf.

Om Storybook te gebruiken binnen een project, moet er wel rekening gehouden worden met het gekozen framework van het project. Zo zal de installatie en de structuur/syntax voor React net iets even anders zijn dan voor bijvoorbeeld Vue of Angular.

Storybook is gebaseerd op componenten: maak daarom componenten zo compact mogelijk. Terwijl een project groeit met steeds meer componenten, is het verstandig om de volgende richtlijnen te hanteren:

  • Je codeert de stories in Storybook om een component weer te geven, maar het kan ook op zichzelf documentatie worden over hoe het component te implementeren is.
  • Heldere en duidelijke code. Het doel is om te begrijpen hoe je het component kunt gebruiken zonder te veel na te denken.
  • Om dit te doen, probeer zo statisch mogelijk te zijn: vermijd abstracties, herhaal indien nodig, vermijd elk soort algoritme.
  • Een juiste benaming en locatie van je story, zodat deze overeenkomt met je codebase

Op het eerste gezicht lijkt Storybook alleen te zijn bedoeld voor zo gezegd ‘domme componenten’ die alleen gebruikt worden voor de user interface. Door de complexere componenten te isoleren en business logica te verminderen, kunnen deze echter prima binnen Storybook gebruikt worden waarbij de focus verlegd wordt van de functionaliteit naar het component zelf.

​Storybook addons

In de basis is Storybook vrij compleet, maar dat wil niet zeggen dat we er niet meer mee kunnen doen. Daarom zijn er tal van addon’s voor te vinden die net even dat stukje extra functionaliteit kunnen geven.

Populaire addons

Een aantal veel gebruikte addons zijn:

  • Links - dit kan gebruikt worden om componenten onderling te verbinden om demo’s of prototypes mee te maken.
  • Viewport - met Storybook Viewport Addon kunnen jouw verhalen in Storybook in verschillende formaten en lay-outs worden weergegeven. Dit helpt bij het bouwen van responsieve componenten in Storybook.
  • Actions – geeft data weer in de UI na het uitvoeren van een event handler
  • Accessibillty - test je componenten tegen de huidige webstandaard
  • Docs – standaard heeft elke story al een DocsPage. Mocht deze niet voldoende zijn kan er gebruik gemaakt worden van deze addon waarna er meer mogelijkheden zijn voor documentatie

Conclusie

Storybook kan optimaal functioneren als het gebruikt wordt door developers, UX/UI developers en de stakeholders. Door combinatie van deze verschillende disciplines levert Storybook een grote meerwaarde voor het ontwikkelen en het onderhouden van webapplicaties.

Zelf aan de slag?

Wil je zelf aan de slag met Storybook, maar kan jouw team wel iemand gebruiken die hier ervaring mee heeft? Mijn mede-frontenders bij ShareValue en ikzelf hebben hier ervaring mee, werken graag met Storybook en komen dan ook graag jouw team helpen bij het opzetten hiervan.

Bronnen

Storybook: https://storybook.js.org/

Addons: https://storybook.js.org/addons

Storybook Story: https://storybook.js.org/blog/the-storybook-story/

{description}

Heb je een Azure expert nodig?

Neem contact met ons op
{description}

Hoor van onze experts hoe leuk ShareValue is

Lees de verhalen van onze collega's