mde

Embrace op bezoek bij de Dutch Umbraco User Group

Twee, toch wel oudgedienden van tegenwoordig Embrace onderweg, waarnaartoe? Naar DUUG: Dutch Umbraco User Group!

Sinds een paar maanden zijn we regelmatig te vinden bij DUUG, vooral omdat het informatief is, en ook natuurlijk een beetje omdat we hoofdsponsor zijn. DUUG organiseert bijeenkomsten voor Umbraco bedrijven om kennis en informatie te delen op een leuke en informele manier. Lees meer over hoe we onze software kunnen koppelen met het CMS Umbraco. Dit keer was Arlanet de gastheer van de bijeenkomst, zij zijn één van de hoofdsponsors.

Flink op tijd, stappen Sjaak en ik in de auto onderweg naar Wormerveer. Een gehucht/ehh plaats aan de noordkant van Zaanstad. Met het idee, het zal wel druk zijn, we vertrekken op tijd, komen we een half uur te vroeg aan. Briljant, we zijn de eersten, wederom.

Sjaak steekt eerst nog lekker een peukje op en ik loop alvast naar binnen om ons aan te melden. Eenmaal binnen worden we ontvangen met open armen. Pak wat drinken, doe alsof je thuis bent. Nou dat gaat natuurlijk gebeuren.

Embrace op bezoek bij Arlanet voor Duug meetup vr-bril

Verderop zitten medewerkers van Arlanet lekker te gamen en wordt hun VR-bril geconfigureerd. Het eerste slachtoffer meldt zich al: SJAAK. Als een ninja zie je hem midden in een kamer om zich heen te slaan, meppend om fruit kapot te krijgen. De directeur van Arlanet stelt zich even voor aan ons en herkent ons al van gezicht (we beginnen op te vallen).

Sessie #1 Rapid Umbraco Development

Onze eerste sessie ging over Rapid Umbraco Development. Maar in onze beleving leek het eerder op de ‘Do’s and Don’ts van Umbraco’. Hierin werd verteld over de valkuilen van Umbraco, waar het soms tekortschiet, en dat ontwikkelaars graag het wiel opnieuw willen uitvinden (Klopt, graag hoe meer spaken hoe leuker het wiel).

De grote onderwerpen van deze sessie waren; performance, caching en versies.

Bij het onderwerp performance werd duidelijk dat Umbraco een coole xml cache heeft die boven de 1000x nodes al een stuk trager wordt. En dat hoe het geheugen van een server snel mb’s opvreet. En toen begonnen er allemaal lampjes te branden en belletjes te rinkelen bij ons. Hmm, deze issues komen ons bekend voor, maar dit keer dus met tips van hoe we het eventueel anders kunnen doen. Interessant, heel interessant.

Het komt er in feite op neer dat je bij veel content meer gebruik moet gaan maken van de lucene index, en dan niet specifiek die van Umbraco maar custom varianten daarop.

Nu zullen sommige denken waarom custom varianten? Nou om de simpele reden dat Umbraco zelf eigenlijk in hun index alle velden indexeren, wat weer een overload kan zijn voor bijv. een nieuwspagina. Hierbij kan je met een custom index al af met alleen de velden die je dan wilt laten zien. En dan zit je ernaar te luisteren en automatisch begin je te denken aan eventuele veranderingen en consequenties. Hier gaan we zeker iets mee doen en verder onderzoeken. We doen al natuurlijk veel op deze manier, maar we kunnen misschien hiermee nog meer performance mee winnen.

Snel daarna tikt hun lead developer en ik mag ook wel zeggen Umbraco Guru er even uit dat we moeten stoppen met het gebruiken van eigen strategieën om te cachen en custom cache handlers te schrijven terwijl er al 3 cache manieren via Umbraco wordt aangeboden.

De 3 caching mechanismes die Umbraco aanbieden zijn: RuntimeCache, RequestCache & StaticCache.

Heel simpel, runtimecache is eigenlijk wat we zelf ook al gebruiken, alleen wordt dat nu via Umbraco aangeboden. Request cache is alleen beschikbaar tijdens 1 request call. En static cache is altijd beschikbaar maar eigenlijk moet je die nooit gebruiken.

En ja we hebben inderdaad een eigen implementatie destijds geschreven, die eigenlijk nu overbodig is. Dus ook hiermee moeten we wel wat doen. Want het is in feite dubbele code. En dat is natuurlijk zonde. Zijn advies was ook: maak gebruik van wat er is waarvoor het ook bedoeld is.

En toen kwam eigenlijk meest mooie moment; Umbraco en versiebeheer. Eigenlijk heel mooi, elke wijziging van Umbraco wordt opgeslagen, maar dan ook echt elke wijziging. Hierdoor groeit versiebeheer ook uit de klauwen, waarbij je snel kwijt bent wat voor tekst je mogelijk kwijt bent omdat je aan het klooien bent met het opslaan van bijvoorbeeld wel tonen in het menu of geen reacties tonen.

Hmm, dachten we, misschien moeten we daar eens naar kijken. Het idee van Arlanet was, gebruik voor niet versie relevante onderdelen een PetaPoco tabel waarin je dit verwerkt. Op zich klinkt dat logisch maar eigenlijk is het gewoon zonde dat je niet aan kan geven wat wel en niet in versiebeheer moet worden meegenomen. Wederom een punt dat nader onderzocht moet gaan worden.

Pff, allemaal huiswerk lijkt het wel. Toch merk je dat met zulke sessies je eerder oplossingen kan bedenken dan als je dit allemaal zelf moet uitzoeken. De kracht van de community.

Pauze, heerlijk, er is ook bier wordt er gezegd, en natuurlijk als ervaren bierdrinkers waren Sjaak en ik er als eerste bij. Helaas, Amstel. Pff dat is wel een domper, maar ja, er is geen ander bier en we waren wel klaar met de koffie en cola. Dus op naar de volgende sessie Bitcoins en blockchain.

amstel bier grapje

Sessie #2 Blockchaining

De insteek van de heren van de blockchainsessie was dat we aan het einde van de sessie konden uitleggen wat een blockchain precies inhoudt. Dat is de beste man (die wel erg veel weg had van Rob Geus) bijna gelukt.

Hieronder onze poging om jullie duidelijk te maken wat een blockchain is.

Bovenstaand plaatje geeft een redelijk overzicht van de opbouw van een cluster die gebruikt wordt om blockchains te maken/controleren. Rechts onderin een schematische weergave van een (in dit geval) transactie van een Bitcoin van gebruiker #13 naar gebruiker #29.

Het principe achter blockchain is in eerste instantie dat er niet 1 partij is die leidend is in Blockchain transactie. Dus niet zoals we in de echte wereld gewend zijn, dat een bank je geld beheert, maar dat het door losstaande nodes in de cloud gebeurt. Ik zal stap voor stap door het proces lopen:

  1. Gebruiker #13 gooit een transactie op om een Bitcoin over te maken naar gebruiker #29 en ondertekent deze met zijn eigen hash (voor niet developers de unieke code van deze gebruiker, zie het als een ApiKey)
  2. Deze hash wordt door alle deelnemende nodes opgepakt en in een block gestopt. In een block zit een x aantal transacties die samen na veel rekenwerk weer een hash opleveren waarmee een hash kan worden gemaakt met alleen 0én. Elke node berekent de nieuwe hash uitzonderlijk!
  3. De node die als eerste de hash gevonden heeft (in dit geval degene rechtsboven, met BINGO erboven) wordt deze ter controle naar alle andere deelnemende nodes gestuurd.
  4. Deze nodes controleren of de berekening van de “winnende” node klopt. Wanneer dit het geval is, wint de winnende node een x aantal Bitcoins.
  5. De hash die gevonden is, wordt vervolgens de 1e transactie in een nieuw block. Waarna weer stap 1 en 2 volgt.

Door deze laatste stap wordt het een veilige manier van transacties verwerken. Omdat de hash van een vorige block gebruikt wordt voor de nieuwe. Het is dus niet mogelijk om eerder afgeronde blokken aan te passen en in de chain te krijgen omdat alle blocks daarna dan niet meer kloppen.

Zo is het dus mogelijk om decentraal transacties te doen, die toch veilig en onveranderbaar zijn.

Volgens de heren, is het echter wel zo dat Blockchains voor Umbraco niks kunnen betekenen, maar andersom wel. Het was dus naast dat het een redelijk een abstracte sessie was ook nog eens niet iets waar wij als Embrace en Umbrella echt iets mee kunnen. Desalniettemin zeker wel een boeiende sessie.

Met vriendelijke groeten,

Johan & Sjaak 

edwin2Wil je meer weten over hoe we ons intranet integreren met Umbraco?
Neem dan contact op met Edwin.
06-54633946<
edwin.cnossen@embracesbs.com

Download Ebook In 7 stappen naar een succesvol social intranet

Download Ebook In 7 stappen naar een succesvol social intranet-mobile

Facebooktwittergoogle_plusredditpinterestlinkedinmail