Så er vi godt i gang med NDC Oslo konferencen. Igen i år har vi valgt at deltage på konferencen, fordi vi mener at bredden på konferencens emner gør, at alle dem der deltager fra Schultz kan finde interessante talks. Og igen i år er programmet sprængfyldt med interessante emner og talere. Her er alt fra funktionel programmering og C#/C++ over gadgets til mere bløde emner som agile processer og UX/Design.
De første to dage er pre-konferencen, hvor der er workshops som varer 1-2 dage. Her tilmelder man sig et forløb og går i dybden med nogle emner. Hos Schultz beskæftiger vi os meget med sikkerhed i web applikationer, og vi varetager vedligeholdelsen af Digitaliseringsstyrelsens SAML komponenter til NemLog-in. Derfor har de fleste tilmeldt sig workshoppen med de to sikkerhedsguruer Brock Allen og Dominick Baier. Her er der sikkerhedsnørderi for alle pengene og de nyeste teknologier som OWIN og Katana bliver pillet fra hinanden og sat sammen igen. Vi har også haft et team på funktionel programmeringsworkshop.
Sikkerhedsworkshop af Dominic Baier og Brock Allen
Der sker en masse cool ting hos Microsoft for tiden og ASP.NET gennemgår i disse måneder en stor forandring.
Claims-baseret model
Microsoft har siden lanceringen af ASP.NET for mange år siden skiftet fokus i forhold til sikkerhed og siden 2010 har de understøttet en Claims-baseret model gennem Windows Identity Foundation. En Claims-baseret model er en abstrakt model, hvor et claim beskriver noget om en given bruger. Det kunne være brugerens navn, rolle, gruppetilhørsforhold, e-mail og lignende. Windows Identity Foundation startede som et stand-alone produkt, men er siden .NET 4.5 blevet en del af frameworket, og ASP.NET applikationer benytter nu Claims-modellen som underliggende sikkerhedsmodel. Claims-modellen har den store fordel for os udviklere, at den er så tilpas abstrakt, at den nemt tillader mapning mellem forskellige autentifikationsmetoder og bruges fx når vi laver en web applikationen som tillader login på sociale tjenester som Google, Facebook og Twitter.
OWIN og Katana
Udover det store spring med en Claims-baseret model er Microsoft også begyndt at skille hele ASP.NET frameworket fra hinanden med introduktionen af OWIN og Katana (Katana er meget symbolsk navnet på et Samurai sværd). ASP.NET har vokset sig stort og bloatet gennem tiden og indeholder alt for megen funktionalitet i forhold til måden, vi i dag bygger web-løsninger på, hvor vi benytter mere lightweight frameworks som MVC og Web Api. Det har Microsoft indset, og derfor er de begyndt at skille ASP.NET ad i mindre dele og prøver dermed at lave Legoklodser i forskellige størrelser, som kan sættes sammen til en løsning. Vi synes, det er den helt rigtige vej for Microsoft og ASP.NET frameworket. Det er tydeligt, at de fortsætter med det i forbindelse med den nylige introduktion af ASP.NET vNext, hvor også .NET stakken bliver splittet op i mindre Legoklodser.
OWIN er en simpel pipeline-model som kan modtage et http request og afsende et http response. Den indkommende request sendes igennem en pipeline af såkaldte middleware komponenter, som hver håndterer requestet. Den nye sikkerhedsmodel er implementeret som middleware, og det gør hele modellen meget nem at udvide, hvor nye sikkerhedsmodeller kan kobles ind i pipelinen.
Fremtidsperspektiverne er meget interessante for ASP.NET og .NET, og det bliver nemmere for os som udviklere at kode sikre ASP.NET løsninger og at give brugerne af disse løsninger en nem mulighed for at logge ind med Google, Facebook og Active Directory. For os hos Schultz vil det være oplagt at lave OWIN middleware til at understøtte NemLog-in.
Skrevet af: Jonas, Kim, Stefan og William.
Funktionel programmerings workshop af Venkat Subramanam
Funktionel programmering er meget oppe for tiden og har affødt interesse for et hav af forskellige funktionelle programmeringssprog som Scala, Clojure, Erlang, Haskell og F#. Hvis du vil med på vognen med funktionel programmering, skal du så skifte programmeringssprog og stak? Flere af disse sprog henvender sig rigtig godt til det funktionelle paradigme, da det nu engang er det, de er bygget op omkring. Men Venkat Subramanam’s tilgang til funktionel programmering i denne workshop er ikke, at vi skal starte med at finde et nyt sprog at kode i. Vi kan i stedet starte med at tænke funktionelt i det sprog, vi er vant til at arbejde med. Sprog som C# og Java har nemlig i dag faciliteterne til, at du kan arbejde funktionelt.
Derfor er Venkat’s tilgang til denne workshop også: “Hvilket sprog koder du i til hverdag?”. Under workshoppen har der kørt eksempler i primært C# og Java, da der var flertal for disse sprog blandt deltagerne, men der har også været adskillige eksempler i JavaScript, Ruby og F#.
Et radikalt anderledes paradigme
Funktionel programmering er et radikalt anderledes paradigme end objektorienteret, og sprogene er typisk designet som enten et funktionelt, objektorienteret eller mixet sprog.
Til dagligt arbejder vi i C#, og selvom C# understøtter muligheden for funktionel programmering via Action og Func, vil sprogets objektorienterede design hele tiden tillade dig, at du træder ved siden af. Derfor tror vi også, det er vigtigt at forstå, hvad der faktisk er motivationen bag den funktionelle tilgang, så du kan holde dig på den funktionelle sti.
Den helt grundlæggende metode til funktionel programmering er, at man skal designe “pure functions”. Dette er metoder/funktioner, der givet det samme input, til hver en tid vil returnere det samme output. De kan ikke være afhængige af delt tilstand såsom member variable i et objekt eller tid. En metode skal være enkapsuleret af udelukkende dets input variable. Et andet vigtigt punkt er, at data er immutable, altså en funktion må ikke ændre i tilstand – heller ikke i input parametre, udelukkende returnere nye data.
Som vi ser det, er det fire umiddelbare store fordele ved denne tilgang
* Koden bliver nemmere at teste. Du tvinger dig selv til at anvende en metode der er meget præcis omkring, hvad den skal bruges til, for at kunne udføre sit arbejde
* Det bliver sværere som udvikler ikke at tage stilling til parallelisering af sin kode. Med den funktionelle tilgang bliver dette til en triviel opgave, da du ikke har shared state!
* Du skulle begynde at se færre fejl i din kode. Mange af de fejl vi får introduceret, skyldes ofte, at vi piller ved tilstanden af objekter/data på kryds og tværs i en metode, og så er det, at man liiige misser en lille uskyldig metode, der ændrer en variabel, man ikke havde forventet
* Din kode bliver mere koncis og enkel at overskue, når metoder ikke har side effects, men kæder atomare operationer sammen
Vores udgangspunkt som .NET udviklere har været, at funktionelle programmeringssprog i høj grad er noget, der gør sig gældende i den finansielle verden, eller andre regnetunge områder. Typisk kan man observere, at dele af ens applikation måske ville drage fordel af at blive refaktoreret i et funktionelt programmeringssprog, såsom regelmotorer og heuristik over store datasæt. Desværre bliver man hurtigt forpustet ved tanken om at introducere nye moving parts, nye sprog og risiko.
Jeres erfaringer?
Vi er nysgerrige efter, om nogen af jer læsere har erfaring med at indføre funktionel programmering i projekter – eller måske introducere komponenter skrevet funktionelt, i et i forvejen objektorienteret program? Har det ændret på, hvordan I tilgår jeres løsninger?
Skrevet af Allan og Anders
Følg os frem til fredag på denne blog og på twitter #ver2ndc
Leave a Reply