Fagkveld 24.09.19

NY REKORD!

Tirsdag 24.09 arrangerte vi nok en fagkveld, og aldri har vi vært så mange som nå. Da Sindre, Sindre og Ole Andreas satte i gang showet var vi 41 ITverkere til stede. Det tilsvarer godt over 60% oppmøte, og det er rimelig rått på en tirsdag ettermiddag!

2X Sindre

Det var navnebrødrene Sindre S og Sindre B som staret showet, tett ettefulgt av ringreven Ole Andreas. Sindre og Sindre differensieres både ved hårfarge og etternavn. Førstkommende bærer etternavnet Stenland, har mørkt hår og vikingskjegg. Sistnevnte er en lyslugget legende som har vokst opp på den riktige siden av Mjøsa, i byen der alle har et søskenbarn. Selv om begge Sindrene våre har etternavn som antyder at de heller burde studert geologi, er undertegnede veldig glad for at de valgte IT i stedet.

Ole Andreas

For de som har allerede har vært inne og tittet på bloggen vår trenger ikke Ole Andreas Rydland noen videre introduksjon, men som en så stor bidragsyter fortjener han et par ord likevel. Ole Andreas, også kjent som greven av DevOps og Domain Driven Design, vokste opp i byen med de syv fjell og kronisk nedbør. Han har skrevet utallige blogginnlegg og er kanskje den i ITverket som har holdt flest talks. Selv om Ole Andreas ikke har et geologi-inspirert etternavn, har han en biceps som enkelt kan gjøre stein til grus sånn at Sindre og Sindre kan analysere innholdet.

IMG_20190924_163631


Viking-Sindre lærer oss å debugge.


Debugging i Visual Studio

Sindre Stenland debuterte som presentatør i ITverket med en veldig fin talk om hvordan livet ditt kan bli mye enklere dersom du velger å benytte deg av den gigantiske verktøykassa du har i Visual Studio. Han dundra gjennom en live demo, uten demospøkelser, der han demonstrerte hvordan innebygde hjelpemidler i Visual Studio kan brukes i stedet for mer manuelle og tidkrevende fremgangsmåter. Her er en kort oppsummering av noe av det han viste oss:

  • Callstacken: Når man har fått et exception kan man sette et breakpoint der, og navigere i call stacken for å finne ut hvor det faktik gikk galt, og hvilke kall som ble gjort før det skar seg.
  • DataTip: pinning av variabler så de forblir synlige, og man slipper å holde musepekeren over. Man kan også ekspandere objekter og pinne lister og variabler.
  • Debugger display: Attributt for å representere et objekt som en string under debugging (har også støtte for metode-kall). For å bruke debugger display legger du bare til DebuggerDisplay syntax i topen av klassen du ønsker å debugge.
  • QuickWatch: Lar deg inspisere variabler uten hover, samt mulighet for å evaluere variabler innenfor nåværende scope (scope kan skiftes ved bruk av call stacken). Det er en rask og fin måte å inspisere verdien på properties på.
  • Immediate window: C# statements i nåværende scope (scope kan skiftes ved bruk av call stacken). Når du stopper på en kodelinje kan du skrive variabler eller uttrykk, trykke enter, og voila så kan du se verdiene i stedet for å starte på nytt og trykke F5 helt til du er på samme sted igjen.
  • Action breakpoint: Her kan du for eksempel printe ut verdien på objektet du ønsker å inspisere når breakpointet treffer. På den måten blir du presentert med verdiene på objektet med en gang, og du slipper å holde over og navigere på objektet.
  • Conditional breakpoint: Stopper eksekvering dersom den betingelsen du har spesifisert intreffer. Dette er ekstremt nyttig når man debugger større dataset, og kun er interessert i å stoppe opp og inspisere når det kastes et exception, og ikke på de 1000 andre elementene i lista.

Alt dette er eksempler på hvordan man kan gjøre ting litt lettere for seg selv, og som Sindre selv sa: Mange kjenner til mye av dette fra før, men det er fort gjort å glemme en del av det. Og hvis det er ting som gjør debugging litt raskere så er det viktig å repetere og belyse. Det er tross alt en stor og potensielt frustrerende del av jobben vår.

Selv om man debugger som en gud, og koden som kjører i det fjerne fungerer knirkefritt, betyr ikke det nødvendigvis at produktet som eksponeres for kunden er bra. Det er jo en "snakkis" i bransjen at mange utviklere er relativt dårlige på design, noe som kanskje gjør at den gode jobben vi gjør ikke blir like verdifull som den kunne vært dersom vi hadde hørt litt mer på Sindre Berge.

IMG_20190924_160736


Kongen av Gjøvik viser oss design på en visuell og forståelig måte.


Så, hva bør egentlig en utvikler kunne om webdesign?

Sindre Berge debuterte også med sin presentasjon denne tirsdagskvelden. Han hadde i anledning fagkvelden laget en egen nettside der han, på en visuell og ryddig måte, demonstrerte 5 design-prinsipper som bør/skal/må ligge til grunn om man skal designe en røddig nettside. For å putte en stor og ukjent verden inn i en 20 minutter lang talk fokuserte Sindre på 5 prinsipper som grunnmur for et godt design.

  • Visual hierarchy: Dette prinsippet handler om hvordan elementenes størrelse er avgjørende for hva vi oppfatter og hvor blikket vårt lander. En av de viktigste faktorene her er størrelse. Jo større et element er, jo mer naturlig er det at blikket ditt faller på dette elementet. Derfor kan man bruke størrelse til å understreke hva som er viktig. Med andre ord: Size does matter.
  • Whitespace/negative space: Dette er den delen av siden der det ikke finnes noe. Tomrommet, om du vil. Det kan brukes til å skille elementer og gjøre det mer oversiktlig. Nok et enkelt, men veldig kraftig prinsipp.
  • Allignment: Handler egentlig bare om rette linjer. Elementer som legges på linje gjør siden ryddigere og mer lesbart for brukeren. Om man ikke bruker allignment riktig kan det også oppstå negativt fokus, der brukeren fokuserer på at ting ikke ser organisert ut, i stedet for å fokusere på nettsidens innhold. Ofte bruker man for eksempel midtstilt tekst, i stedet for å trekke rette linjer. Selv om det kanskje virker som en god ide så kan det være at det hjernen egentlig oppfatter er kaos.

kaos

Hva du ser når man ikke bruker allignment.


  • Contrast: Forskjeller mellom elementer. Kontrast brukes til å lede brukeren inn på ulike elementer eller ulikt innhold som designer (eller utvikler;)) ønsker at brukeren skal fokusere på. Det kan være for å gjøre designet mer spennede ved at man bruker form og farge til å gjøre elementer for å bryte opp eller det kan være at man rett og slett ønsker å øke lesbarheten på et budskap ved å utheve tekst som er viktig.
  • Grouping: Det siste av 5 prinsipper. Gruppering brukes for å gi brukeren inntrykk av det er ferre elementer enn det egentlig er. Om en side består av utallige elementer vil det være vanskelig for brukeren å vite hva man skal fokusere på. Ved å gruppere lignende og nærliggende elementer sammen så gir det et inntrykk av det egentlig bare er et element.

Nedenfor ser vi hvordan nettsiden til Sindre ser ut dersom man ikke benytter seg av disse 5 relativt enkle prinsippene. Det er hverken oversiktlig, lesbart, eller spennende for den som skal bruke nettsiden din.

sindre_f-r

Utgangspunktet før Sindre skrur på design-skillsa.


Etter at Sindre har lagt på de 5 prinsippene om design ser siden helt annerledes ut. Det er nå lett for personer som skal navigere på Sindres hjemmeside å finne frem, det er enkelt å forstå budskapet, og det fremstår generelt proffere og mer gjennomført. I tillegg til de 5 prinsippene Sindre introduserte har han lagt på en moderniserings-feature. Denne endrer kun farge på elementene og legger til et bakgrunnsbilde. Sindre var veldig tydelig på at denne featuren var det absolutt minst viktige, og at dersom man fjerner en av de andre prinsippene så vil siden miste det meste av sin sjarm til tross for endrede farger og bakgrunnsbilde. Hvis du ønsker å prøve deg frem selv kan du gå inn på https://design.sindre.io og teste ut hvordan siden ser ut ved å toggle prinsippene Sindre har snakket om.

sindre_etter

Resultatet av å anvende 5 enkle prinsipper og litt modernisering.


Sammodellering (Collaborative modelling)

I mangel på en bedre oversettelse falt vi på ordet "sammodellering" her, oversatt fra "Collabarative modelling". Det handler i stor grad om samspill mellom utviklere, prosjektledere, beslutningstakere og andre som er involvert i et prosjekt.

OLE_detnestesteget

Venstre: der vi er.
Høyre: dit vi vil.


Ole Andreas viste oss hvordan vi i mange situasjoner befinner oss til venstre i bildet over, der ulike deler av organisasjonen har sine ansvarsområder, og kunnskapsdelingen er begrenset. Man har gjerne "eksperter" på hvert sitt område. Det være seg design, utvikling, operations, forretning og domene.

For å komme seg til figuren til høyre i bildet over, fortale Ole Andreas oss om 3 teknikker som kan brukes.

  1. Discovery: Formålet med discovery er å dele kunnskapen og innsikten de ulike personene i teamet sitter på og oppdage og avklare uoverenstemmelser og spørsmål så tidlig i prosessen som mulig. Her kreves god tid, og jo mer visuelt det gjøres jo letttere er det for folk med forskjellig bakgrunn og kompetanse og enes om løsningen. Fremgangsmåter her kan være event-storming eller User Story Mapping.
  2. Prosess-modellering: Prosess-modellering brukes når vi beveger oss inn på det mer detaljerte nivået. Vi ønsker fortsatt visuelle fremstillinger og fokuser på kunnskapsdeling. Her må man ofte identifisere avhengigheter, definere prosessen, og finne ut hva slags exceptions man håndtere. Jo mer udefinert prosessen er jo viktigere samhandlingen.
  3. Implementering: Til slutt har vi implementeringsfasen. En av de viktigste tingene her er også kunnskapsdeling, men her kommer også de tekniske aspektene inn i bildet. Her blir det ekstra viktig av de kritiske delene av systemet er gjennomtenkt, samt modellering av domener og nye teknologier. Under selve implementasjonsfasen er det mange måter man kan samhandle på. Ole Andreas nevner for eksempel par-programmering og swarming som to ulike fremgangsmåter.

Det er utviklerens forståelse av koden som går i produksjon, og hvis ikke alle interessenter i et prosjekt snakker samme språk kan det fort oppstå misforståelser. Om man klarer å opprette en felles forståelse og har et felles bilde av hva som skal leveres, når det skal leveres og hvordan det skal leveres er sjansen for at det leveres er i henhold til det alle ønsket seg i utgangspunket.

Mat, drikke og quiz.

Som seg hør og bør på en fagkveld fikk også leveren og magen næring. Vi spiste en herlig delingsmeny på Skatten på Tøyen, og gledet leveren med de herligste sorter øl og vin. I mens vi konsumerte herrens gyldne dråper hadde Marius Quizwall tatt på seg rollen som quizmaster og laget en Tørnquiz-inspirert variant til oss. Dette var en rolle han kledde, og som dere ser på bildet under så var også scenen godt egnet for en quizmaster av høyeste kaliber.

quizmarius

Quizmaster Marius Thingwall i sitt rette element.


Oppsummering

Alt i alt en veldig ålreit kveld med veldig ålreite folk og veldig interessante talks. Det at så mange velger å bruke ettermiddagen sin sammen med gode kollegaer man ikke ser til daglig gjør det ekstra gøy å arrangere. Håper enda flere har lyst til å være med oss neste gang:)

Sees plutselig!