Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum tre års erfaring som utvikler, UX eller UI-designer, systemarkitekt eller prosjektleder. Ta kontakt og bli med på laget!

Bli en av oss banner

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur.

Møt en X banner

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur. Les noen av våre Medium blog posts her!

Bloggen - Dfind Consulting

JavaZone 2022 — Key takeaways

Fra student til konsulent — Løft blikket før skredet tar deg

Git reflog: Restore Version Control History

Dfind Consulting — Internship 2022

Hva er Dfind Direction?

European Women in Tech 2022 - Tre takeaways

Help, I’m a proxy product owner!

React Scroll Hook with Shadows

Stop Overusing Console.log in JavaScript

Benefits of Static Site Generation

<h3>JavaZone 2022 — Key takeaways</h3>
<h4>JavaZone er en av verdens største samfunnsdrevne konferanser og tar for seg ulike temaer innenfor teknologi, sikkerhet, UX og ledelse. Konferansen gikk over to dager med fullpakket program og mange interresante foredrag.</h4>
Skrevet av <a href="https://medium.com/@mathias.hartveit">Mathias Hartveit</a> og <a href="https://marius-ibsen.medium.com/">Marius Ibsen</a>
Som alle tidligere år ble JavaZone holdt i Oslo Spektrum. Konferansen hadde mer enn 3200 deltakere, over 100 foredrag og foredragsholdere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wSQSpqbrXGVXOyQuJoQMCQ.jpeg"><figcaption><a href="https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link">https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link</a></figcaption></figure>Vi har tatt med oss mange erfaringer fra årets JavaZone som vi syntes er viktig å belyse. Erfaringene og kompetansen vi har tatt med i år handler hovedsakelig om mennesker.
<h3>Utvikling handler om mennesker</h3>
Utviklere blir mer og mer tilknyttet flere deler av organisasjonen og tar valgene som tidligere ble tatt av personer uten innsikt eller kunnskap om faget. Dette kommer nok av at man forstår bedre hva utviklerrollen er og at den kan flettes inn med de andre fagdisiplinene i organisasjonen.
På JavaZone i år delte flere foredragsholdere om egne erfaringer som ikke nødvendigvis hadde hovedfokus på kode, men som heller handlet om mennekser, forventninger til utviklere og at utvikling ikke alltid trenger å være så seriøst.
Hva betyr det å være en god utvikler? Christin Gorman fra Kodemaker mener at vi må oppdatere hvilke forventninger om hva programmering egentlig er; dette snakket hun om i foredraget <a href="https://2022.javazone.no/#/program/a28cd1fa-9696-4a1f-97b0-ce1c0bbad6dc">What makes a good developer?</a>. Det som forventes av en utvikler i dag er gode mattekunnskaper og å kunne skrive algoritmer. Programmering som fag blir også ofte fremstilt som en idyllisk verden uten problemer men dette er en ganske så unøyaktig sannhet av virkeligheten. Utviklere opplever også utfordringer i hverdagen slik som i andre jobber, vi løser bare ulike utfordringer og har andre behov.
Forventningene som stilles i dag er nesten irrelevant og langt ifra hva en utvikler faktisk jobber med. Utviklere flest bruker svært lite matematikk i det daglige, og de færreste av oss skriver en algoritme. Det er hverken nødvendig med gode mattekunnskaper eller å kunne skrive algoritmer for å være en god utvikler. Christin mener vi bør fokusere på andre egenskaper som er mer nødvendige og relevante for det arbeidet vi driver med. Hvordan man jobber med mennesker og forstå problemene vi må løse for menneskelige behov er av viktigere art; en utvikler programmerer hovedsakelig løsninger for å løse menneskelige utfordring. Chistin nevner tre egenskaper man bør se etter når man skal rekruttere nye talenter:
<ul>
<li>De viktigste egenskapene en utvikler må ha er tålmodighet og utholdenhet.</li>
<li>Jo mer vi kan av det grunnleggende desto bedre valg kan vi ta i fremtiden.</li>
<li>Vi trenger mer menneskelig interesse. Vi må bry oss om menneske vi lager løsninger for, og vi må forstå utfordringene brukerne våre opplever.</li>
</ul>
Stian Veum Møllersen fra NRK tok oss med på en <a href="https://2022.javazone.no/#/program/8c383c4d-e6ab-44f0-a5a2-ae0782d20e9f">røverhistorie om Popcorn og klokker</a>. For noen år siden startet han et moro-prosjekt for å gjenskape låten Popcorn, en meme-låt fra 1969. Prosjektet gjorde at man måtte løse ulike problemstillinger og finne riktige datastrukturer for å håndtere tid og lyd synkront i nettleseren. Utforringene han måtte løse gjorde at han fikk innsikt i flere av nettleserens verktøy, som blant annet setInterval, setTimeout, requestAnimationFrame og WebAudio-klokka. En annen foredragsholder, Vegard Veiset fra Bekk, viste frem sin hjemmesnekra spillmotor laget i Kotlin. Spillmotoren hadde han laget fordi han ville forstå hvordan en spillmotor fungerer, ikke for å faktisk lage spill. Prosjektet hadde han jobbet med i over fire år på hobbybasis.
Det vi likte spesielt godt med foredragene her var at både Stian og Vegard lagde noe med interesse for å løse andre problemer enn det de vanligvis støttet på. De trengte ingen spesiell grunn eller mening de ville bare gjøre noe gøy for å lære seg ny kunnskap. Det vi lager trenger ikke være seriøst eller nyttig, ei heller profesjonelt for å være lærerikt. Det viktigste er at man får noe ut av det man lager
Nina Bakken, designer i NAV, hold innlegget <a href="https://2022.javazone.no/#/program/77ba7dac-424f-401f-ac34-2539aeba2807">Fart, flyt og hyppige leveranser = bedre brukeropplevelse</a> hvor hun delte erfaringer om det å lære et team å arbeide sammen i smidige prosesser. Essensen av smidig utvikling handler om å gjøre små ting, ofte. Ved å gjøre dette, vil man redusere risiko ved store lanseringer. Smidig utvikling handler også om kontinuitet, og at man jobber med små porsjoner som kan lanseres hele tiden.
En typisk designmetodikk går gjennom flere steg — ide, konsept, testing og utvikling. Utviklere jobber gjerne etter en kortere prosess hvor de “slipper unna” de stegene som ikke har med utvikling å gjøre og feil fikses ofte umiddelbart. Hvis man får alle de ulike fagdisiplinene til å arbeide sammen som et team, så er det ikke noe i veien for at alle de tverrfalige rettningene kan jobbe slik utviklere gjør. Det bør ikke være separate faser men noe som skjer kontinuerlig. Innsikt, konsept, testing, utvikling og videreutvikling er noe man alltid må gjøre uansett.
Inkludering av de tverrfaglige fagrettningene i hverandres prosesser vil etter hennes mening gi økt fart, flyt og hyppigere leveranser. Åpenhet om kode og design vil skape mindre usikkerhet i teamet. Det er viktig å kunne vise frem og snakke om uferdig arbeid for å unngå tap av innsikt og læring. Hun trekker frem noen tilnærminger som har fungert bra for deres team, blant annet parprogrammering, par-design og datadreven utvikling.
Samlingen av disse foredragene og tilnærmingsmåtene danner et bilde av en norsk industri i vekst hvor fokuset på den tekniske og den organisatoriske og menneskelige siden av utvikling blir mer sammenflettet.
<h3>Fremtiden er Sosio-Teknisk</h3>
Norske bedrifter og organer har over lengre tid hatt fokus på en digitaliseringsprosess av deres tjenester og produkter. Denne prosessen ser ut til å ha ført de fleste opp mot en felles problemstilling. Hvordan skaper man og vedlikeholder IT-baserte team, programvare og prosesser som er bærekraftige, langsiktige og stabile for medlemmer, produktet og brukere?
Dersom man spør 10 bedrifter får man nok 10 forskjellige svar, og derfor er det veldig givende at mange av Norges IT-kjemper deltar på JavaZone for å dele sine erfaringer og anmodninger om hvordan nettopp de oppnår sine mål — uten å slite ut både teknologien og menneskene involvert.
Vipps utforsker sine utfordringer, opplevelser og erfaringer i foredraget <a href="https://2022.javazone.no/#/program/5a831bdc-03be-4142-9e47-ec24dd95713c">Hva er digital produktutvikling? En historie fra Vipps.</a> Moquan Chen og Marit Andreassen understreker viktigheten av å danne tverrfaglige og myndiggjorte team. Et myndiggjort team dannes når medlemmene har autonomi til å ta de valgene fagpersonene mener er best for å oppnå målet definert av ledelsen. For mye styring ovenfra fører til mikrostyring, noe som ofte fører til teknisk dårligere produkter og mindre eierskap for selve laget som utfører oppgavene. Man ønsker å teste teorier og hypoteser så tidlig som mulig i prosessen frem mot et produkt for å luke ut hvilke muligheter teamene har fremover.
<a href="https://2022.javazone.no/#/program/85187a21-c215-43f8-90e8-88989b7a945d">Einar W. Høst fra NAV</a> mener at moderne utviklere og it-systemer er “sosio-tekniske” fenomener. Organisasjonens krefter påvirker utviklingen av programvare, som igjen påvirker arbeidsmåten til organisasjonen. Utviklere som ønsker å påvirke organisasjonen må være mer enn bare teknisk dyktige, de må også være sosialt dyktige. I foredraget tar Einar oss gjennom de personlige utfordringene som kan oppstå individuelt og internt i team som blir mer og mer myndiggjort i dagens landskap.
Det eneste som ser ut til å være sikkert i tverrfaglige, teknologiske og myndiggjorte team er at landskapet rundt endrer seg kjapt, og det endrer seg ofte. Dette gjelder både teknisk med tanke på teknologiske utfordringer og muligheter som åpner for nye løsninger, men også samfunnsmessige endringer. Lover og regler, fokus på nye brukergrupper eller endringer i brukernes daglige behov kan slå inn på hva fremtiden til teamet skal se ut som. Desto viktigere er det at teknologene er fokusert på å bygge bærekraftige løsninger. Med bærekraftige løsninger menes det tekniske løsninger som tåler endring og vedlikehold over lang tid, med skiftende fokus og landskap.
<a href="https://2022.javazone.no/#/program/b0d4acb2-2255-48db-acf0-f1268017b49e">Kristofer Giltvedt Selbekk</a> deler sine erfaringer fra 10 år med design systemer og frontend komponentbibliotek for å belyse hvordan man designer React komponenter med fokus på den fremtidige utvikleren. <a href="https://2022.javazone.no/#/program/8a2fd154-b7d0-466c-99b4-ffce79cc6e2f">Vegard Haugstvedt</a> forteller om NAVs pågående arbeid med å digitalisere alle sine søknader. Til nå estimerer de at de har digitalisert om lag 300 søknader på 3 år! Teamet må underveis ta hensyn til flere lag med brukere, samt endringer i lover og regler, endringer i nav-kunders behov og ikke minst ønsker om å kunne bruke tjenesten utenfor den digitale sfæren.
Som deltaker på JavaZone 2022 har det vært svært givende å delta i diskusjonene og erfaringene som deles av mange av Norges fremste teknologiske bedrifter. Dette er utfordringer som er universelle for alle team i alle sektorer, og byr på et spennende blikk inn i fremtiden for mange “sosio-teknologer”.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b344a33962f9" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/javazone-2022-key-takeaways-b344a33962f9">JavaZone 2022 — Key takeaways</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<h3>Fra student til konsulent — Løft blikket før skredet tar deg</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TE4iDhsn-kLJC4x4hHptgA.jpeg"><figcaption>Fra Camp Dfind 2022</figcaption></figure>August er alltid en spennende tid hos oss i Dfind Consulting. Sommerstudentene har nettopp blitt offboardet, mens våre nyutdannede kollegaer har sin første arbeidsdag som eksperter i IT. Dette innebærer naturligvis forventninger fra oss som arbeidsgiver, fra kunder og ikke minst fra den nyansatte selv. I dette innlegget skriver jeg om hvordan Dfind Consulting sørger for å møte deres forventninger gjennom vår onboarding-uke. Hensikten med uken er å gi nyutdannede en trygg start på karrieren og samtidig hjelpe dem på veien til å bli gode konsulenter. Slik lykkes Dfind Consulting i å utvikle markedsledende løsninger for våre kunder.
<h4>En nyutdannet sin styrke</h4>
Erfaring, hva har det egentlig å si i IT-bransjen? En erfaren topptur-gåer kan mest sannsynlig gå fortere, gjøre bedre sporvalg og klare seg bedre enn en uerfaren topptur-gåer. Statistikken viser derimot at jo mer erfaren du er, jo mer utsatt er du for å bli tatt av snøskred. Kan man basert på dette anta at jo mer erfaren du er, jo høyere er sannsynligheten for at du følger “kjente spor” i stedet for å se nye løsninger eller legge merke til endrede forutsetninger?
Det er nettopp her de nyutdannede rett fra skolebenken har sin styrke, og dette gjelder spesielt i IT-bransjen. Teknologi, rammeverk og språk endrer seg så raskt at innen du kan kalle deg erfaren, kan forutsetningene ha endret seg, eller det det kan ha kommet en ny løsning på problemstillingen. Derfor mener jeg at nyutdannede med ufargede sinn, er særlig relevante og stiller sterkt for å se de beste løsningene for våre kunder.
Innenfor frontend finnes det flere gode eksempler på hvor raskt teknologi og etterspurt kompetanse utvikler seg. Du rekker knapt å bli erfaren i et rammeverk før det har kommet et nytt og mer “moderne” på banen. Illustrasjonen nedenfor viser endring i popularitet for hvert frontend-rammeverk siden 2016. Dette gjenspeiler riktignok ikke etterspørsel i markedet, men det gir et interessant bilde av hvor raskt det skjer endringer i teknologi, som igjen påvirker etterspørselen av kompetanse.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*jqHJBEkG4TMpemwl"><figcaption>“THE STATE OF JS 2021: FRONT-END FRAMEWORKS AND LIBRARIES”. Alex Ivanovs. 19. februar, 2022</figcaption></figure><h4>Utvikler vs. konsulent</h4>
Våre nyutdannede konsulenter har i løpet av studietiden blitt eksperter innenfor sitt tekniske fagfelt. Dette har vi sikret gjennom grundige screeningprosesser og intervju. Felles for alle er at ingen har hatt “konsulentfaget” på skolen. Konsulent og utvikler er i mine øyne to veldig forskjellige roller. Vi konsulenter går hele tiden på line. Oppgaven vår er å balansere mellom å utfordre kundene våre, og samtidig se at løsningen vi oppfatter som perfekt, nødvendigvis ikke er den som skaper høyest verdi. Det er nettopp her det er så utrolig viktig at vi bruker kompetansen vår til å hjelpe kundene våre i å gjøre gode vurderinger.
Det finnes ingen fasit på hva som definerer en god konsulent. Du har muligheten til å lage din egen definisjon basert på din personlighet, erfaring og kompetanse. En god konsulent er uavhengig av personlighetstrekk. Forskjellen finner vi i hvordan du lærer å bruke disse trekkene sammen med din kompetanse til å spille deg selv og våre kunder gode. Det betyr at jo større mangfold vi har, jo større arsenal tilegner vi oss av fremgangsmåter for å hjelpe kundene våre. Dette er etter min mening, det som virkelig gjør jobben vår til en av de mest givende, utviklende og utfordrende jobbene innenfor IT. Så hvordan utgjøre denne forskjellen som konsulent, uten erfaring? Jo, Camp Dfind.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*chojcC4cbVf1Pd8lIz18lA.jpeg"><figcaption>Det ble luftig på Camp Dfind 2022</figcaption></figure><h4>Camp Dfind</h4>
Vi kan ikke påstå at vi er de eneste i bransjen som har en onboarding-uke for nyutdannede konsulenter. Derimot tør vi påstå at vi har bransjens kanskje mest unike omboardinguke. Konseptet bak Camp Dfind er å trene opp våre egne, av våre egne. De nyutdannede får under trygge forhold bryne seg på typiske fallgruver man som konsulent opplever, og kjenne på presset som kan oppleves ute hos kunde. Samtidig blir de kjent med sine nye kollegaer og ledere på en utflukt ute av byen. Hensikten med Camp Dfind er å gi konsulentene en verktøykasse de kan ta med seg ut til sitt første prosjekt. Dette gjør at våre nyutdannede kollegaer kan senke skuldrene når første kunde står for tur. De vil føle seg tryggere, skape mer verdi og på den måten føle seg mer verdsatt, som til syvende og sist fører til høyere trivsel.
Teknologi og språk er selvsagt også en viktig del av Camp Dfind. Vi har fokus på at konsulentene får tatt i bruk nye spennende språk og rammeverk som de kanskje ikke har vært borti før. Dette gjenspeiler også noen av utfordringene når man går fra skolebenken til konsulent hos en ny kunde. Evnen til å tilegne seg kunnskap i ukjente språk, rammeverk, metodikker og teknologier raskt.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QYQcyj9GCKA8Sli_xV6jPg.png"><figcaption>Deltakernes beskrivelse av Camp Dfind 2022</figcaption></figure>Camp Dfind er under kontinuerlig utvikling for å sikre våre nyutdannede den beste starten på sin karriere hos oss. Ser du for deg en fremtid som IT-konsulent og har lyst til å vite mer om Camp Dfind? Vi kan dessverre ikke røpe mer om konseptet, men håper du har lyst til å oppleve det med oss. Kanskje vi sees på Camp Dfind?
Referanser
The State of JS 2021: Front-end Frameworks and Libraries. 2022. Hentet fra <a href="https://stackdiary.com/front-end-frameworks/">https://stackdiary.com/front-end-frameworks/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5cde7e60910" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/fra-student-til-konsulent-l%C3%B8ft-blikket-f%C3%B8r-skredet-tar-deg-5cde7e60910">Fra student til konsulent — Løft blikket før skredet tar deg</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NNpIKZmLZ8bDSz79"><figcaption>Photo by <a href="https://unsplash.com/@vonshnauzer?utm_source=medium&amp;utm_medium=referral">Egor Myznik</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Did you know we can use Git reference logs to restore Git commit history(?) Often we developers experience challenges when working with Git. We can accidentally force-push commits to the remote main branch, complete a rebase that went bad, delete a branch we wanted to keep or hard reset to the wrong commit. In this post, we will look at git reflog and git reset. We will review some common scenarios on restoring local commits, restoring a deleted branch, and reverting force-pushed changes due to a rebase.
<h3>Git reflog</h3>
<a href="https://git-scm.com/docs/git-reflog">git reflog</a> is a tool that can help us recover almost anything — at least everything we have committed. The tool keeps track of commits that have been created but also discarded ones in a log called the reference log. The reference log is kept on our local computer under the .git directory in a local repository. It contains a list of commits that HEAD has pointed to and keeps track of the entire history of a commit. Besides the reference log for branches, we have a separate reference log for stash.
It’s important to know that reference logs do not track in the remote repository, like pushes, fetches and clones; it is purely local and current to the working environment. Below is two screencaps, the first from Github Codespaces and the second from a local filesystem that initially created all the commits of the main branch in the same repository:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/964/1*L1DTjYe4kiUo01_95hL-dQ.png"><figcaption>Reference log from a workspace in Github Codespaces</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/930/1*d175xjAzVotgtgHlFvjtQg.png"><figcaption>Reference log from local computer where the commits were initially created</figcaption></figure>Records of the history on a branch will expire after 30 days by default. We can change the expiration days running git reflog —expire if we want to keep the history for a longer time or just want to change the duration.
<h3>Git log vs reflog</h3>
<a href="https://git-scm.com/docs/git-log">git log</a> is a command that shows a list of commits related to a branch.git reflog is similar to git log but shows a list of snapshots and times when HEAD was changed. reflog can also reference other types such as stash, branches, rebase, merge and tags. A reference is known as refs, and the syntax for accessing these is name@{qualifier}. Running git reflog is the most basic use case and essentially the equivalent of writing git reflog show HEAD. The output will look like this:
<pre>=&gt; git reflog</pre>
<pre>47efaa2 HEAD@{0}: commit: refactor: remove post schema f243f12 HEAD@{1}: commit: refactor: change author fields 4783ba0 HEAD@{2}: commit: chore: add .env to gitignore a19d142 HEAD@{3}: commit: chore: update readme f5ade9a HEAD@{4}: commit: chore: update yarn.lock 854c08f HEAD@{5}: commit (initial): feat: bootstrap sanity studio</pre>
<h3>Git reset</h3>
<a href="https://git-scm.com/docs/git-reset">git reset</a> is a command we can use to move back to a previous commit, discarding or undoing previous changes. We can run git reset --hard &lt;commit_sha&gt; to move our branch back in the commit history.
<ul>
<li>
A hard reset (git reset --hard) will completely destroy any changes and remove them from your local repository.</li>
<li>
A soft reset (git reset --soft) will keep your changes, and stage them back automatically.</li>
<li>
A mixed reset (git reset --mixed) which is the default, will keep you changes but they will also become unstaged. Even tho it is flexible, you will have to stage the changes manually.</li>
</ul>
<h3>Restore local commits</h3>
<h4>Scenario</h4>
We have made some commits that haven’t been pushed to the remote repository yet. We do a git reset —-hard &lt;commit_sha&gt; to a previous commit, and our local branch is set back to an earlier point and discarded all history after the chosen commit. We then run git log and see that the commits are gone. We cannot pull the changes from the remote repository since we never synced the changes.
<h4>How to restore</h4>
When running git reflog we can see that our changes still are tracked by the reference log; we even have a separate commit for the hard reset that we did earlier:
<pre>f243f12 HEAD@{0}: reset: moving to f243f12 eec6f27 HEAD@{1}: commit: refactor: author should not have image 47efaa2 HEAD@{2}: commit: refactor: remove post schema f243f12 HEAD@{3}: commit: refactor: change author fields</pre>
With this information, we can reset our branch back to the state we discarded by using one of the references in the reflog. We can move our branch to the selected commit by running git reset --hard &lt;commit_sha&gt;:
<pre>=&gt; git reset --hard f243f12 =&gt; git reflog</pre>
<pre>f243f12 HEAD@{0}: reset: moving to eec6f27 f243f12 HEAD@{1}: reset: moving to f243f12 eec6f27 HEAD@{2}: commit: refactor: author should not have image 47efaa2 HEAD@{3}: commit: refactor: remove post schema f243f12 HEAD@{4}: commit: refactor: change author fields</pre>
<h3>Restore a deleted branch</h3>
We can recover deleted branches using SHA’s in the reference logs.
<h4>Scenario</h4>
Not uncommonly, we might checkout a new branch in our local environment. We could have a branch called chore/update-packages and commit a change that adds <a href="https://day.js.org/">dayjs</a> as a package:
<pre>=&gt; git checkout -b chore/add-dayjs-package =&gt; yarn add dayjs =&gt; git add . =&gt; git commit -m 'chore: add dayjs package'</pre>
<pre>5a75042 HEAD@{0}: commit: chore: add dayjs package</pre>
At a later point, we checkout the main branch and deletes the chore/add-dayjs-package branch — maybe we did not need it anymore for some reason:
<pre>=&gt; git checkout main</pre>
<pre>47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main</pre>
<pre>=&gt; git branch -D chore/add-dayjs-package</pre>
<pre>Deleted branch chore/add-dayjs-package (was 5a75042)</pre>
We will get a confirmation message that git deleted the branch. After a while, we discover that we could need the changes after all, so how do we get them back?
<h4>How to restore</h4>
We can undo these changes with git reflog and git checkout. If we run git reflog we won’t see any references to the deleted branch. We could use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we need to use the reference log. And if you named your commits well, it should be easy to find the missing commit:
<pre>=&gt; git reflog</pre>
<pre>// deletion of a branch is not logged to reflog 47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main 5a75042 HEAD@{1}: commit: chore: add dayjs package 47efaa2 HEAD@{2}: moving from main to chore/add-dayjs-package</pre>
We can now checkout the deleted commit SHA and create a new branch from that commit running git checkout -b &lt;branch_name&gt;:
<pre>=&gt; git checkout 5a75042 =&gt; git checkout -b chore/add-dayjs-package</pre>
<h3>Revert force-pushed changes</h3>
<h4>Scenario</h4>
We reset our branch using git reset —-hard to an earlier commit and run git push — force to override any changes that we otherwise could pull from the remote repository. But at some point, we want those changes back.
<pre>=&gt; git reset --hard &lt;commit_sha&gt; =&gt; git push --force</pre>
<h4>How to restore</h4>
We can use git reflog and git reset to restore force-pushed changes.
<pre>=&gt; git reflog f243f12 HEAD@{0}: reset: a19d142 to f243f12</pre>
By the log we can see that the message on HEAD@{0} is reset: a19d142 to f243f12, which means that commit with hash a19d142 was force-pushed by f243f12. That also gives us information about which commit we need to restore, the one with hash a19d142. We can simply do the same procedure as initially to move back to the overriden commit:
<pre>git reset --hard a19d142 git push --force</pre>
Finally, we force-push the new changes to the remote repository. Always be careful and check that you are on the correct branch before doing a force push. Especially to prevent that production code is not being affected or team member code is not being overwritten.
Thanks for reading! I hope you enjoyed this content. Feel free to clap, comment or share.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=67f7676e902f" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/restore-commit-history-with-git-reflog-67f7676e902f">Git reflog: Restore Version Control History</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<h3>Dfind Consulting Internship 2022</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*bIkHM8F11nVKVT1pVOiACQ.jpeg"><figcaption>Jannicke Hamarsnes, Helena Skants, Skjalg Hovland Holtbakk, Eskil Schjølberg, Kavusikan Sivasubramaniam, Thea Kvinnegard, Ida Anseth, Duvara Nishaharan, Elsa Lossius (bak fv.) og Patrick Wulff.</figcaption></figure>Skrevet av Axel Aasen
Dfind Consulting har i år hatt sitt første internship. Over seks uker har ti sommerstudenter hatt ansvar for å lede et prosjekt for selskapet. I løpet av perioden har de utviklet en mobilapplikasjon og en webapplikasjon. Jeg har tatt en prat med sommerstudentene Thea Kvinnegard, Jannicke Hamarsnes og Ida Anseth for å få innsikt i hva de har arbeidet med og lært i løpet av perioden.
Sommerstudentene var delt inn i to team; Team App og Team Admin. Team App hadde ansvar for å utvikle mobilapplikasjonen, mens Team Admin hadde ansvar for å utvikle webløsningen. De to teamene var avhengige av hverandre gjennom hele prosjektet, og samarbeidet på tvers. På denne måten fikk de en realistisk opplevelse av hvordan man som konsulent jobber i prosjekt, med viktigheten av kommunikasjon, forventningsstyring, koordinering, prioritering og hvordan eget arbeid påvirkes av andres. Thea beskriver dette som en av de viktigste erfaringene hun tar med seg fra perioden.
“Å jobbe i parallelle team og se hvordan et slikt samarbeid kan fungere, å faktisk oppleve at det ikke alltid går smidig eller blir helt sånn man hadde tenkt har jeg lært utrolig mye av.”
For best mulig prosessgjennomføring benyttet teamene scrum som metodikk. Med daglig standup, ukentlig sprintplanlegging, demo og retro sikret studentene evaluering og progresjon underveis i prosjektet. Likt for begge teamene var at de rullerte uke for uke på hvem som var Scrum Master, slik at de som ville fikk prøve seg på denne rollen. Av studentene jeg har pratet med mente samtlige at dette var relevant og lærerik erfaring å ta med seg, og Thea beskriver hva hun erfarte i rollen::
“Å få jobbe ordentlig etter scrum-metodikk har vært en stor forskjell fra studiehverdagen til arbeidslivet. Som student er det ikke mulig å benytte slike metodikker fordi det ikke er nok kontinuitet i prosjektene. Det var en øyeåpner å se hvor bra scrum faktisk fungerer — gøy å oppleve.“
Jannicke legger til:
“I en uke hadde jeg hovedansvar for at teamet fulgte arbeidsformen vi hadde blitt enige om, og så til at vi kommer oss gjennom oppgavene som er prioritert. Dette er første gang jeg har fått prøve meg som Scrum Master, så veldig gøy å få prøvd meg på den rollen.”
Gjennom hele internshipet var produkteier og flere konsulenter fra Dfind Consulting tilstede for å bistå og støtte studentene underveis. Dette bidro naturligvis til trygghet for studentene, samtidig som det ga synergier på bakgrunn av mangfoldet de sammen utgjorde. Både Thea, Jannicke og Ida beskriver dette som en av de største forskjellene mellom studiehverdagen og arbeidslivet, og som noe av den viktigste erfaringen de tar med seg.
“Det var en trygghet å ha erfarne konsulenter fra Dfind Consulting i ryggen. Det å ha noen å spørre og sparre med gjør det lettere å komme videre om man står fast.”
“Dette er er jo en bransje som utvikler seg veldig raskt, så det er gøy å få sparre med konsulenter som er aktive i rollen … Vi får både bruke teknologier som er veldig relevante i arbeidslivet òg prøvd oss på de i trygge miljøer.”
Som studentene påpeker har vi sørget for å ta i bruk moderne teknologi som gir studentene relevant og etterspurt erfaring. Mobilapplikasjonen, som Team App hadde ansvar for, var en quiz-løsning som lar brukerne spille quiz live. Applikasjonens frontend ble utviklet i React Native, mens det i backend ble brukt Firebase, hvor Firestore ble brukt som database og Firebase Authentication ble brukt til logg-inn. Det ble også laget Firebase functions, blant annet for å håndtere Push-notifikasjoner. For å lage og administrere innholdet i quizen ble en webløsning utviklet som Team Admin hadde ansvar for. Løsningen ble utviklet i React og hostet på Firebase hosting. Som vi gjorde med mobilapplikasjonen, brukte vi også Firebase som backend i webløsningen.
Basert på tilbakemeldinger fra Thea, Jannicke og Ida, og de andre sommerstudentene i Team App og Team Admin, kan vi trygt si at vi har lykkes i Dfind Consulting sitt første internship. Thea påpeker at vi har bidratt til at hun har funnet sin plass i IT-verden, og med den tilbakemeldingen kan vi ikke konkludere med annet enn at vi har skapt verdi og fått til noe mer enn bare å utvikle et produkt. Vi ser frem til samarbeid med flere sommerstudenter i årene som kommer!
“Jeg føler den viktigste erfaringen jeg tar med meg er at jeg har funnet min plass i et team, men også min plass i IT-verden. Jeg har skjønt at det er her jeg ønsker å være, dette jeg vil jobbe med fremover — at jeg har valgt riktig.“
Er du nysgjerrig på hvilke muligheter som finnes som student i Dfind Consulting? Ta en titt på våre studentsider <a href="https://www.dfindconsulting.no/jobb-hos-oss#internshipArticle">her</a> for å lese mer.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9db3fd9222e4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/dfind-consulting-internship-2022-9db3fd9222e4">Dfind Consulting — Internship 2022</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dfind Direction er vår satsning på ledelse, arkitektur og rådgiving, enkelt og greit.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3-u42TfNnSpbbJV5Y8M7zw.jpeg"></figure><h3>Hvorfor?</h3>
Vel, først blir det litt historiefortelling. Det hele startet i 2016. Consulting så dagens lys og i løpet av 2017 hadde de første pionerene blitt med på skuta. Hovedvekten av konsulenter var utviklere selv om man også hadde prosjektledere og arkitekter i tillegg til UX og andre roller. Det har vært en god vekst i selskapet og når vi etter hvert nærmet oss og passerte 150 ansatte ble utfordringene tydeligere. Flesteparten av konsulenter og kunder kjente oss som et konsulentselskap med utviklere og det ble vanskelig å vise mot både kunder og potensielle nye kolleger at vi hadde mange andre bein å stå på. I tillegg så vi at det var forskjellige behov både avhengig av hvilken profil man har, men også også mtp. senioritet. Man er på forskjellige steder i livet rett og slett.
Dfind Direction ble etablert som vår satsning på ledelse, arkitektur og rådgiving med de av våre konsulenter som kjente seg igjen i denne beskrivelsen. Flere har blitt med siden den gang.
<h3>Hvorfor prosjektledere og arkitekter i samme gruppe?</h3>
I bunnen er vi IT-konsulenter alle sammen. Det vil si at vi er prosjektledere, produkteiere, scum mastere, team lead, tech leads og arkitekter i IT-prosjekter. Alle er tekniske i bunnen eller direkte i sin rolle.
I et samfunn som stadig blir digitalisert og hvor nye og kommende generasjoner er født digitale, vil flere og flere selskaper, organisasjoner og offentlige aktører ha alle sine prosesser digitalisert. Conways lov og prinsippet om at organisasjoner vil utvikle IT-systemer som gjenspeiler organisasjonen, viser oss at det er en særdeles sterk link mellom arkitektur og ledelse. På mange måter går de hånd i hånd og det er behov for lik kompetanse i begge leire.
Til sist vil jeg også poengtere at arkitekt og prosjektleder bare er paraplybetegnelser i mine øyne. De favner flere og mer definerte roller slik som jeg har forsøkt å illustrere under. Noen konsulenter har flere av disse hattene, mens noen har gjort et dypdykk ned i én. Det de har til felles er at det kreves en del erfaring og senioritet
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ErV5_5dCaAqwZm9glCx10A.png"></figure>Erfaringen vi har gjort oss i vekstperioden er at det er krevende å kombinere mange spesialiseringer i samme gruppe. Det er veldig mye man har til felles, men det er også en del unike og egne behov. Det krever et visst fokus og det krever muligheten til å gjøre ting annerledes. Med vår filosofi om autonomitet, selvstyre og et selskap bygget av og for konsulenter, er den naturlige tilnærmingen å starte opp en egen divisjon, så selvstyrt som mulig, og nesten som et eget selskap i selskapet.
<blockquote>Poenget er at det er må være fleksibelt nok til å forme seg i takt med konsulentene i selskapet.</blockquote>
På bakgrunn av alt dette ble Dfind Direction etablert. Vi jobber fortsatt med “å finne oss sjæl”. Dette er kontinuerlig arbeide og aller viktigst; det er noe vi gjør sammen.
<h3>Første strategisamling</h3>
Pandemien gjorde at vi ikke fikk startet slik vi ønsket så når høsten 2021 kom så vi vårt snitt til å samle alle i direction og gjennomføre den første strategisamlingen vår.
Målet var å finne ut hva Direction er for oss og hva som er de viktigste verdiene for alle som er med i Direction.
Workshoppen gikk som følger:
<h4>Halen på grisen, aka hvor er vi i markedet</h4>
For å skjønne litt mer om oss selv var det interessant og også se på andre. På den måten kan vi se hva som var unikt for oss, men også bekrefte enda litt tydeligere hvem vi er.
Vi startet med å definere to akser hvor den ene går fra teknologi til forretning og den andre fra rådgivende til implementerende. Deretter plassere vi oss selv og andre konsulentselskaper i denne matrisen. Det er ikke så interessant hvor andre er, men det vi oppdaget om oss selv er at vi vil være mer implementerende enn rådgivende når det gjelder forretning og mer rådgivende når det gjelder teknologi.
Det er ikke et veldig overraskende resultat for prosjektledere og arkitekter, men det er en fin måte å visualisere det på. Det er også mulig å snakke om hvor man er og hvor man vil være og utvikle en strategi for å bevege seg i den retningen man vil.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/796/1*Ns4Q_Xyp3Yg4MrQb2SNVTw.png"></figure>Her er noen eksempler på konsulentoppdrag og hvordan det ville plassert seg i matrisen
<ol>
<li>Rådgivende/teknologi: Teknisk revisjon</li>
<li>Teknologi/implementerende: Utvikler i et team</li>
<li>Implementerende/forretning: Forretningsutvikler eller produkteier</li>
<li>Forretning/Rådgiver: Markedsundersøkelse/rapport</li>
</ol>
De aller største selskapene har gjerne en fot i alle kvadranter og det blir sånn sett vanskelig å plassere de. Derfor havnet alle i midten
<blockquote>Et svært viktig prinsipp vi fikk ut av denne øvelsen er at de gangene vi har rådgivende roller eller er i en posisjon hvor vi blir spurt om å gi råd, så skal vi også være i stand til å implementere det vi snakker om.</blockquote>
<h4>Cover story</h4>
For å få brukt kreativiteten litt krydret vi med noen “klippe og lime” aktiviteter. Med “Cover story” skal man ha litt vyer og se for seg en tenkt avis eller magasinforside om 15 år. Det skrives om dere. Hva står det?
Gruppa klippet og limte med både hvitt og farget papir. Det ble mye forskjellig, men felles for de alle var at Dfind Direction skulle være et sted hvor folk ønsket å bli værende.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/526/1*CNH74xBBEI_uo3iqaKunrg.png"><figcaption>Et av bidragene</figcaption></figure><h4>Verdibrainstorming</h4>
Kanskje det viktigste aktiviteten for dagen. Den gjennomføres ganske enkelt som en brainstorming med påfølgende presentasjon og diskusjon før vi grupperer like lapper og til slutt stemmer på hva vi mener er viktigst.
For å fokusere på verdier hadde vi noen “knagger” man kunne bruke for å komme i gang:
<ul>
<li>Kollegaer og sosialt</li>
<li>Faglig innhold og utvikling</li>
<li>Verdier og holdninger</li>
<li>Roller og oppgaver</li>
<li>Bli motivert</li>
<li>Kompensasjon</li>
<li>Familie og venner</li>
</ul>
Vi fylte en vegg med post-it lapper og vell så det. I mylderet viste det seg etter hvert at det var noen områder som var viktige for alle sammen
Work/life: Mange har famile eller andre utenomsportslige aktiviteter. Vi ønsker en arbeidsplass som tilrettelegger for at vi yter og utvikler oss så godt som mulig
Fag: Faglig styrke er ikke bare en enorm styrke for selskap og kunde, det er også hvem vi er. Vår stolthet ligger i å gjøre en god jobb, designe gode systemer eller etablere vellykkede team og produkter. Om vi ikke kontinuelig utvikler oss og selv vil vi hverken trives eller lykkes.
Sosialt: Den store utfordringen for de fleste konsulentselskaper hvor vi er hos kunde store deler av dagen er å holde på et sterkt bånd med sine kollegaer. Dette er viktig for oss og vi må jobbe for å skape arenaer som legger til rette for dette.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/455/1*HEPFM5hPRbvyUCNskcohCQ.png"></figure>Til slutt snakket vi om sammenhengen mellom disse. Fag og sosialt må balanseres med work-life. Finner vi balansen mellom disse tre er vi på riktig vei
<h4>Product box</h4>
Den siste øvelsen vi gjorde på denne samlingen var også av det kreative slaget. Her skulle vi se for oss hvordan det hadde sett ut om en Dfind Direction hadde vært et produkt som ble levert i en boks. Hva trekker vi frem som unike egenskaper på innpakningen?
<figure><img alt="" src="https://cdn-images-1.medium.com/max/781/1*vYTha1EYNXavlzSe2rU2Tg.png"></figure>En fantastisk morsom øvelse hvor vi fikk brukt alle kvaliteter vi lærte oss på kunst og håndverk på ungdomsskolen. Skal vi trekke frem noen av de viktigste egenskapene ved Dfind Direction er det (1) Faglig styrke og kvalitet, (2) Familie og work-life balance, (3) likestilling og (4) levere det vi prater om.
Mange av de samme punktene gikk igjen gjennom alle øvelsene. Dette er mye fordi det etter hvert blir forankret i gruppa og gjentar seg selv av den grunn, men også fordi vi lykkes med å finne noe som er viktig for alle. Det er sånn vi skal utvikle oss i Direction. Det er høy kompetanse og folk med såpass lang erfaring at når vi legger hodene sammen så får vi det til.
<h4>Oppsummert</h4>
Om vi skal prøve å oppsummere det som er starten på en strategi for Direction ser det ca sånn ut.
<ul>
<li>Gir solide råd og veileder, men må kunne “walk the walk” og implementere det vi snakker om, både teknologi og prosess for teknologiutvikling.</li>
<li>Vi er sterke på teknologi, men også forretning, siden teknologi i større og større grad driver og definerer forretning og organisasjon</li>
<li>Dette er summen av Direction, hver enkelt konsulent har forskjellig kompetanse, men vi spiller på hverandre og utnytter hverandres kompetanse inn i prosjekt og problemløsning</li>
<li>Vi må legge til rette for fortsatt sterk faglig utvikling og sosialisering med kollegaer slik at det lar seg kombinere med disse andre viktige delene av livet. Og ikke minst gjør alt det andre lettere.</li>
</ul>
Direction har i dag blitt utvidet til alle Dfind Consulting sine kontorer og vi jobber med å definere oss selv som et nasjonalt nettverk på best mulig måte. Denne høsten ser vi på faglig utvikling så vi kan tilrettelegge for at både arkitekter og prosjektledere fortsetter med å styrke sin kompetanse på sine premisser.
Vi skal fortelle hvordan det har gått ved en senere anledning..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ea82454942b8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hva-er-dfind-direction-ea82454942b8">Hva er Dfind Direction?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

European Women in Tech er Europas største tech-arrangement for kvinner, og tar for seg temaer innen teknologi, ledelse og karriereutvikling. Etter to år med pandemi var en gjeng på femten ansatte fra Dfind Consulting sultne på kompetanseutvikling og networking — og dette fikk vi. Etter to inspirerende konferansedager med flere av techbransjens mest innflytelsesrike kvinner har vi plukket ut tre takeaways vi nå ønsker å dele med fler.
European Women in Tech fant sted på det velkjente konferansesenteret RAI midt i Amsterdam. Konferansen gjestet over 250 speakers, hadde over 250 sesjoner og workshops, og over 4000 deltakere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*x5OL_HU_PGVA2bEyGJV9xg.jpeg"><figcaption>Dfind Consulting på European Women in Tech 2022</figcaption></figure>Den viktigste kompetansen vi tar med oss og ønsker å belyse:
<h4>Rollemodeller</h4>
Et av de mest fremmende tiltakene for å øke kvinneandelen i techbransjen er å eksponere unge jenter for rollemodeller som inspirerer og viser at det er mulig å få en spennende karriere innen teknologi.
Microsoft gjennomførte en studie med flere enn seks tusen kvinnelige deltakere i alderen ti til tretti år. Av studien fremkom det at interessen for STEM (science, technology, engineering, mathematics) nesten dobles når de har en rollemodell som inspirerer dem, hvor foreldre og lærere her ble trukket frem som aktuelle rollemodeller. Studien viste at sannsynligheten for at jenter vil studere datateknologi og informatikk øker med 81 % dersom en forelder oppmuntrer til en STEM-utdannelse, sammenlignet med en som ikke oppmuntres.
I stor grad handler det om å i det hele tatt prate om og kommunisere STEM som et alternativ til valg av studieretning, og samtidig bryte tabuer om at jenter ikke mestrer realfag like godt som gutter. Studien viser at 91 % av unge jenter regner seg selv som kreative, og at hele 72 % ønsker arbeid som hjelper verden. Vi som jobber i bransjen vet jo hvor fantastisk store muligheter det er for kreativ utfoldelse og arbeid med samfunnsnyttige løsninger — dette må prates om! Vi må bidra til økt bevissthet og kunnskap rundt de faktiske mulighetene som finnes ved å jobbe i techbransjen. “If you cannot see it, you cannot be it”. For at foreldre og lærere skal kunne være gode rollemodeller, må også vi som arbeider i bransjen ta ansvar og være rollemodeller gjennom kompetansedeling og bevisstgjøring.
<h4>Bias i kunstig intelligens (AI)</h4>
Bias i AI er et reelt problem med potensielle alvorlige konsekvenser. Algoritmer er ikke objektive, men virker ut fra det som defineres av den som lager algoritmen. Det er sannsynlig at vi mennesker tar med oss våre biaser inn i koden. Samtidig vil også datagrunnlaget som algoritmen lærer av og baserer sine resultater på, kunne ta med seg biaser. Dette er to viktige faktorer til at bias i AI forekommer i utgangspunktet.
“One size doesn’t fit all”. Techbransjen må være en sann representasjon av mangfoldet som finnes i samfunnet, slik at mangfoldet også blir representert når ny teknologi utvikles. Konsekvensene av en teknologisk utvikling som ikke er representativ sees allerede, som ved talegjenkjenning som ikke gjenkjenner pronomenet “hers”, men gjenkjenner “his”. Eller ansiktsgjenkjennings-programvarer som ikke klarer å skille personer med mørk hud.
Vi har fortsatt en vei å gå innenfor teknologi for å unngå bias i AI. Mye av følgene som sees er skapt av manglende mangfold eller allerede samfunnsdefinerte forutantakelser. Ved å tilføre mer mangfold og ikke minst ta høyde for at bias i AI kan og vil oppstå er vi allerede et stykke på vei for å unngå konsekvensene det kan få.
For mer informasjon og flere tips til hvordan vi unngår bias i AI, les innlegget European Women in Tech har postet om tematikken: <a href="https://www.europeanwomenintech.com/blog/bias-in-ai">https://www.europeanwomenintech.com/blog/bias-in-ai</a>
<h4>“Claim your space!”</h4>
En siste og generell oppfordring vi tok med oss og mener er viktig å bringe videre, er å våge å ta plass og ta kontroll over egen karriere. Dette var en fellesnevner ved flere av foredragene, og samtlige av foredragsholderne delte sine historier om hvordan deres karriere skjøt fart eller endret kurs den dagen de tok et valg om å ta plass.
Snakk høyt om egne ambisjoner, fremhev og vis hva du kan. Vit din verdi og be om det du fortjener, med en antagelse om at ingen kommer til å gi deg noe gratis. Det handler om å synliggjøre seg selv og vise hva du er god for. Hvordan skal ellers din leder eller mentor kunne støtte deg og påvirke din faglige og personlige utvikling for å nå dine karrieremål?
Delta i og inkluder alle i diskusjonen. Prat med de med andre synspunkter enn deg selv, også de personene du vet du får en utfordrende samtale med, eller den som vanligvis ikke inkluderes i diskusjonen. Med en oppriktig nysgjerrighet overfor alle perspektiver utvikler du deg. Å skape nettverk som både inkluderer de som kan støtte, rådgi og utfordre deg kan åpne fantastiske utviklings- og karrieremuligheter. Ved å tørre å ta denne plassen, fremme egne meninger og kompetanse samtidig som andre også inkluderes, skapes perspektivbevegelighet og synergier. Det skaper en arena for å selv kunne utvikle seg og motta andres respons.
Med det håper vi å ha inspirert flere kvinner og menn der ute til å være gode rollemodeller og utfordre seg selv til å ta litt større plass. Vi mener at European Women in Tech-konferansen er like relevant for menn som kvinner, og oppfordrer alle menn til å engasjere seg på tilsvarende arrangementer, selv om det inkluderer “women” eller “kvinner” i tittelen. Som vi nå har presisert — hvordan skal kompetansedeling og endring skje om ikke alle inkluderes i diskusjonen og kunnskapsdelingen? Vi i Dfind Consulting fortsetter i hvertfall vårt arbeid med å dele kompetanse, og håper vi har bidratt til å belyse viktigheten av mangfold i techbransjen.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d3cc717610e8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/european-women-in-tech-2022-tre-takeaways-d3cc717610e8">European Women in Tech 2022 - Tre takeaways</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BF2vA6dM2PHRFyaMoWq8kQ.jpeg"></figure>Some years ago, I was working as a facilitator or coach, if you like, for a team of product owner. It was a complex organisation and the product we were working on had many stakeholders from different parts of the organisation. All with different needs and priorities. It is often difficult to do propper, customer centric product development in this situations as it often end up in a discussion about who should get their way and the features they want.
The challenge:
<ul>
<li>
Different needs and priority between stakeholders</li>
<li>Great business understanding, but not much experience with analysing insight and breaking it down into product requirements
</li>
<li>
High expectations from the rest of the organisation towards what the stakeholders will “deliver” for their team or department</li>
<li>
Difficult to move forward as a PO as the same discussions are being repeated</li>
</ul>
All of this resulted in us not being able to move forward and no-one getting what they wanted. We came up with a workshop concept to takle this challenges and be able to continue with everyone more or less on board
Where can this workshop be helpful?
<ul>
<li>A lot of stakeholders with different needs and opinions</li>
<li>Different seniority between stakeholders</li>
<li>Stakeholders not focusing on problems and insight and more on gut feeling</li>
<li>Stakeholders with a strong opinion on solution, but not necessarily the solution to the problem</li>
<li>You find yourself as a proxy PO without mandate</li>
</ul>
<h3>The works</h3>
For a group of about 12 ppl, you probably need two days to allow for discussion. The agenda will look something like this
<ul>
<li>
Homework — Participants need to prepare an “opportunity statement/description” . You will have to send this out a bit in advance.</li>
<li>
Opportunity workshop — Work with the opportunities provided by participants and stakeholders</li>
<li>
Ideation workshop based on opportunities</li>
<li>
Detailing — Work with selected ideas and start to detail in groups</li>
<li>
Afterwork — Still a lot of work to do, but you hopefully have direction and priority</li>
</ul>
To run a smooth workshop, you might also want to add a bit of motivation and warmup before you kick off the opportunity part. Personally I have had good results talking about the overall product development process and product lifecycle and I can also recommend running a short brainstorming about expectations from all participants.
<h4>Homework</h4>
I find it very helpful to give the participants some homework. It helps to get the right focus going into the workshop and also to control the scope a bit. The workshop itself can also be done in shorter time.
We ask all participants to fill in as many “Opportunity statements” as possible. You will probably get one or two from each. The name “opportunity” is chosen because it’s not related to the solution at all. We don’t commit to anything, but it’s rather a positive upside we can address. The solution will come later to address the opportunity.
<a href="https://docs.google.com/document/d/1N0ZMTle1tBLGzdnsslAJTIbnR8PtRdf_TwwnmtNvZa8/edit?usp=sharing">Download the template</a>
The template also encourage the writer to think about insight and reasons for why this opportunity is valid. E.g “X% of our user base spend on average 30 minutes for each task. By making this easier, we can save them 8 hours of work each day”. “This and that competitor have this feature and X% of the market. We also got this feature, but our customers doesn’t use it”
<h4>Opportunity statement template</h4>
Title and description — Describe the opportunity. Be as detailed as possible. Remember that the one reading this don’t know what you know.
<ul>
<li>What is occurring? What is the observations made and what is the insight from this?</li>
<li>The objective. What are we going to accomplish?</li>
<li>Who does it affect and where are they affected?</li>
</ul>
Background - Use this section to document your findings and insight
Who is involved - We need to involve them in the verification stage later.
<ul>
<li>Who is involved at your company?</li>
<li>What customer/customer segments are affected?</li>
</ul>
Impact - How big is this opportunity or the problem behind the opportunity?
<ul>
<li>How big market size will it affect?</li>
<li>How many customers are affected?</li>
</ul>
Risk — Challenge your own observations and the opportunity you see
<ul>
<li>Have you made any assumptions?</li>
<li>Why could you might be wrong about the opportunity?</li>
</ul>
<h4>Opportunity workshop</h4>
The day is finally here. It’s workshop time.
Our main purpose for this section is for everyone to get an understanding of the different opportunities from all stakeholders and a priority for what to cover in the next sections
Agenda
<ol>
<li>Make sure you have printed out the opportunities before start</li>
<li>The opportunity owner presents the opportunity in front of everyone</li>
<li>Feedback, questions and discussion</li>
<li>Repeat 2–3 until your are done or spent the time you have timeboxed</li>
<li>Grouping of similar opportunities. This step is important as you hopefully start seeing synergy across the organisation. Things that might have been lost because everyone have been so busy focusing on their own problems.</li>
<li>Prioritization vote — Use red dots. Give each participant 3 dots each, they can place all on one opportunity (group) or spread the votes between different ones.</li>
<li>You now have a prioritised list of the biggest opportunities for your company</li>
</ol>
<h4>Rephrase</h4>
I didn’t mention this earlier, but you actually have some more work to do. Before starting the ideation part of the workshop, you need to rephrase the opportunity as a challenge. By doing this you frame it as a question it is easier to answer and and you will get more precise suggestions.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*liMtxIzzGp0UtP3pD696Mw.png"><figcaption>Rephrase the opportunity into a challenge before going into ideation</figcaption></figure>Example
Say that you have a Saas solution. Your opportunity could be something like: “70% of revenue comes from customers upgrading their licenses. By improving the software license upgrading process, we should be able to see 15% increase and reduce churn by X%. Customer feedback indicate that they don’t know what licence model they should use and they find it hard to find the upgrade section in the Saas dashboard”
Rephrasing: “How might we improve the licence upgrade process by making it more understandable and easier to find”
Do this with every opportunity or grouped opportunity. Write it out on a piece of paper and mention what opportunity it addresses as bullet points on the same paper.
<h4>Ideation workshop part 1 — Brainstorming</h4>
Back to workshopping!
Ideation come in many forms. Some will probably think that this approach is too rigid and doesn’t foster creativity. You are probably right as the purpose of the following activities is to gather as much input as possible from stakeholders. PO and product designers still need to spend time iterating to further improve the suggested solutions.
First we want to do an activity with all participants. We do this because we need buy-in and consensus about the priority going into detailing. We also get to hear everyones voice about all issues before continuing in groups.
Agenda
<ol>
<li>Kick everything off with a walkthrough of the opportunities and the rephrased version. Place them on the wall in prioritised order.</li>
<li>Start with the first on. Brainstorm individually for 5 minutes. “What ca we do to address this opportunity”. It should be very high level as we will go into details later. If we go back to the SaaS licensing case it could be “Create a tutorial video explaining the licensing modell” or “Redesign the licensing tier packages”</li>
<li>Everyone presents their suggestion one by one</li>
<li>Group similar suggestions together.</li>
<li>Prioritization vote — Use red dots. Give each participant 2 dots each. They can place all on one suggestion or spread the votes between different ones.</li>
<li>Repeat step 2–5 until you have 1–3 top ideas for each opportunity. Don’t do too many opportunities as you will get too much ideas to detail. Its better to run the workshop more often than to cover too much during each workshop</li>
</ol>
<h4>Ideation workshop part 2— Detailing</h4>
This next and last part of the workshop is detailing, and it is done in groups. I suggest to split into groups of three. PO or product designer and maybe a tech-lead or architect can move between groups and help out if needed
The output of this section should be different concept drafts we can further develop and verify.
A concept draft in this case is a piece of A3 paper split into 4 sections
Description: Describe the concept/solution. For our SaaS example it could be: “Redesign the license upgrade page so the user sees what licence they are currently on and how many free seats they have. All levels should be shown and the diff in cost and functionality should be clearly stated. We should also give a small discount if the user pay annually and not monthly to nudge them into making a bigger commitment”
Drawings and wireframes: A picture say more than a thousand words. It’s always easier to communicate your thinking with some visuals. It also help you better understand your own suggestion and identify any pitfalls or issues. This section can also be used to sketch out a simple data model, or flow diagram for the more tech savvy participants
Technical aspects: This sections is for writing down all technical aspect that you need to consider or verify as part of the concept. If our concept is a brand new licensing model where users pay for each feature, we might need to consider a complete redesign of our software architecture to encapsulate features and toggle on or off on a user level. Capabilities the system might not have today.
Verification and validation: What to we do to verify the concept, what is the criteria, market, segment etc. This should go all the way back to the opportunity and it is key for the success of this workshop. If we don’t do propper verification and agree on the criteria we might as well just follow the anti-pattern of key stakeholders having their ideas implemented, not focusing on customer value
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NskqZCQGIdzvrGJ2hmkztg.png"></figure><h4>Afterwork</h4>
This is your time to shine PO or product designer. You hopefully have the mandate, anchored in some insight and data, to further develop the concept drafts into propper concepts, verify them, build the MVP and iterate with many version after that. Good luck..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ad1d04982a60" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/help-im-a-proxy-product-owner-ad1d04982a60">Help, I’m a proxy product owner!</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ml53jqb5uYA704hbuPiK5A.jpeg"><figcaption>Photo by: <a href="https://unsplash.com/@asci_en">https://unsplash.com/@asci_en</a></figcaption></figure>Have you ever thought of spicing up your scrollable content with nice-looking shadows? Yes, all browsers have the scroll bar, but we can make our content shine even better and, at the same time, improve usability. I think shadows add a smooth and excellent feel to our content and help by showing the users that “there is more content down here” or “there is more content up here”.
<blockquote>TLDR: You will find the final source code at the bottom of the article</blockquote>
<h3>The Scroll Hook</h3>
Recently, I’ve been working on a hook that adds inner shadows when scrolling an element with overflowing content. It is not very complicated, and it’s fun to make. We’ll break down the code throughout the post, look into how it works, and finally use it in our code.
<a href="https://medium.com/media/154ecf87431923f99747b31da71175d4/href">https://medium.com/media/154ecf87431923f99747b31da71175d4/href</a><h4>Handling scroll events</h4>
First, let’s go through the roll logic part of the hook. It’s not complicated, and I did not have to create three separate states for each event. But it is done for simplicity instead of holding an object with all the values.
<a href="https://medium.com/media/360751a2658643353a36a8f419148277/href">https://medium.com/media/360751a2658643353a36a8f419148277/href</a>onScroll is a React property that we can get on any scrollable HTML element for listening on scroll events, such as a div. It takes a function and returns an event of the target element. In native JavaScript, this would be somewhat equivalent to:
<pre>element.addEventListener(‘scroll’, (event) =&gt; /* do something*/)</pre>
The onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires and the onScrollHandler-method triggers. Then we can pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.
The onScrollHandler-method (exported from the hook) we can pass as the value to the onScroll-property of our element. When scrolling the element, the onScroll-property fires scroll events, and the onScrollHandler-method receives these events. We can then pick the properties scrollTop, scrollHeight and clientHeight from the event target and set them as values for their respective states.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/570/1*cB16NN2s7k_3f-nW8smY_g.png"><figcaption>Illustration of scrollHeight and clientHeight on an element with overflowing children elements</figcaption></figure><ul>
<li>
clientHeight (visible content) is the inner height of an element, including padding. We can calculate it by CSS height + CSS padding. If a horizontal scrollbar is present, the inner height includes the height of the scrollbar.</li>
<li>
scrollHeight (visible + hidden content) is the height of an element’s visible content, including hidden content not visible on the screen for an overflowing element.</li>
<li>
scrollTop is the number of pixels scrolled vertically on the content of an element. Measuring the value takes the distance from the top of an element to the topmost of visible content.</li>
</ul>
(Read more about <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop">scrollTop</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight">scrollHeight</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/clientHeight">clientHeight</a> on MDN)
<h4>Calculate shadow position</h4>
We have to do some calculations to determine if and when we should show shadows on the top, bottom, or both. We want to show shadows concurrently when we’re neither at the top of the scroll nor the bottom.
<a href="https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href">https://medium.com/media/9fcc6ca9c4c03ea3f8bfcfbb8aeb724c/href</a><ul>
<li>
isBottom is true when the inner height of the visible element equals the total height of the visible and hidden content minus (-) pixels scrolled from the top of the element.</li>
<li>
isTop is true when we’ve not scrolled yet, or scrollTop equals 0 pixels.</li>
<li>
isBetween is true when we’ve scrolled more than 0 pixels from the top, and the inner height of the visible element is less (&lt;) than the visible plus (+) hidden content height minus pixels scrolled from the top.</li>
</ul>
We can show this by example: we could have an element that has 400 pixels inner height [clientHeight], that is scrolled 150 pixels from the top [scrollTop]; we should then get that isBetween is true:
<a href="https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href">https://medium.com/media/b3d88c31a4c5a1d12774709b7da81f28/href</a><h4>Determine shadow type based on the calculated position</h4>
Our getBoxShadow()-function handles the logic for determining and returning the correct CSS box-shadow value as a string. This value we want to set to the target element reactive as we scroll. We’re here using the variables — isBottom, isTop and isBetween —from earlier to determine which shadow to use:
<a href="https://medium.com/media/dd244c457001664fff144489f9a1b027/href">https://medium.com/media/dd244c457001664fff144489f9a1b027/href</a>We want to add shadow to the edge with overflowing content because it makes sense to the eye watching it. So, if we are at the top of the element, we show shadow at the bottom. If we are between (as we calculated in the previous code example), we want to show both top and bottom shadows, or else if we are at the bottom of the element, we want to show the top shadow.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/894/1*1vDIJ5_pf17kz1tifdaBCw.png"><figcaption>Illustration of inner box shadow top and bottom on an element with overflowing children elements</figcaption></figure><h3>Using the Scroll Hook</h3>
Since this is a React hook, we need to create a component that can use it, and it should be straightforward since as there is to do is connect the props to the target element.
In the code block below, we have a component called App. We import the useScrollWithShadow-hook, destruct the onScrollHandler()-method and the boxShadow variable. We pass onScrollHandler() as the value of the div’ onScroll property and set boxShadow as an inline style.
<a href="https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href">https://medium.com/media/d5502fbcba53852feaf3e18921c672a5/href</a>Without some content that overflows the element, this would not look or work very well. All it is left is to add some content to the div and maybe some static height so we can get an overflow. We could also add CSS transitions for even more smoothening. But from here on, I will leave the rest to your imagination.
Look at the final result for the styled solution with content and source code on Codesandbox.
<h3>Final result</h3>
Here is the final result. Click “toggle shadows” to switch between with and without shadows (<a href="https://codesandbox.io/s/upbeat-sun-zgyyo5">source code on Codesandbox</a>):
<a href="https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href">https://medium.com/media/0539ccf83b2c50d23410531b216ea8aa/href</a>Thanks for reading! (feel free to clap and share if you liked this article)
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9ba2d47ae32" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/react-scroll-hook-with-shadows-9ba2d47ae32">React Scroll Hook with Shadows</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The web browser console gives us more options than just the console.log()
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qbSBSYYEKTSCfXF5gKz6qQ.png"><figcaption>Image of a road sign containing the text: Watch out! overuse detected</figcaption></figure>OK, I admit it, and I’m not very a fan of it. Mostly I use console.log() for troubleshooting, checking that the arguments of a function get the correct values or that a function returns what I expect it to do. Sometimes I take shortcuts using the built-in browser method console.log() to clarify the result of some piece of code. On infrequent occasions, instead of rendering a ReactJS-component to the Graphical User Interface (GUI), I may print the component to the console to examine its properties.
I’ve seen many developers are using the web console in similar ways as I do. We developers should stop overusing the console.log() and instead draw advantages from what we can do with the web console than just reading simple logs.
I want to discuss some common issues and bad habits that we usually do and some solutions for using the console better.
<h3>Issues and bad habits</h3>
How often do we think about why we use the console.log() method, and in what contexts? Is it just purely automatic that we use it? Why do we always have to do all this logging, especially with console.log()?
In many of these situations, instead of reading and understanding the code, we make guesses and try to help ourselves by logging stuff to the console. All this time we spend on logging can be very time-consuming (sometimes it can even make us even more confused), and we probably “learn” slower.
<h4>Unnecessary logging = less confidence</h4>
An unnecessary amount of logging to the console makes us less confident. Developers often log to the console in many parts of the code — especially if functions are deeply chained — to “test” our code is reliable.
<h4>Using the console for “confirmation”</h4>
In far too many cases, we also accept that when logging something to the console, we get an indication that “everything works fine.” We can prevent building agents or scripts from breaking if we read and understand the code thoroughly instead of relying on the “confirmation” that the console may give us.
We often use this “confirmation” to check whether something is wrong or not, whether an object is undefined or an array has a length. I would say that “confirmation” is OK when our code breaks, and there are no other options.
<h4>Debugging is time-consuming</h4>
Debugging in the console may be time-consuming. Sometimes we can sit for days logging things to the console, taking away the focus on understanding how the code “actually” works and other options that we could have tried instead of just logging stuff.
<h4>Logs may end up in production</h4>
Logging to the console can be deployed in production, which is not always that great — especially if we log critical information that should not be available to “everyone” on the web.
<h3>How we should use the web console</h3>
What is essential to know is that the console also is a <a href="https://en.wikipedia.org/wiki/REPL">REPL</a>. That means we can interact with JavaScript on the page we’re inspecting. Using the REPL is a great way to play with and learn JavaScript.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*IJD_qI9I0EBnjxkcxUvlAw.png"><figcaption>Using the console REPL to add textContent to an HTML element with a wordmark CSS-selector. Here we add a string “Hello” above the Firefox logo.</figcaption></figure><h4>Useful console methods</h4>
The overusedconsole.log() is just one of many methods we may call on the console object. console.error(), console.info(), and console.warn() may be better in cases where we will separate different states of messages. And, to get a better representation of our data in the console we can use methods like console.group() and console.table().
console.error(): Prints an error message to the console, where the printed content will have a red colour. Most browsers also displays an error icon beside the console message.
console.error(‘Something is wrong’)
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*tYcFUWNQmHoWvGFQL6geeA.png"></figure>console.warn(): Prints a warning message to the console, where the printed content will have a yellow color. Most browser also displays an warning icon beside the console message.
console.warn(‘Heads up! This is a warning’)
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*urjiiFrNXm3I2S_pYvVhBw.png"><figcaption>Illustration: console.warn example in Firefox. console message with a yellow triangle containing an exclamation mark</figcaption></figure>console.group(): Prints a group of console methods executed within the group. Such logging is usable when we need to do more than a single log in different files which is not related. We can also open and close groups in the console.
<pre>console.group(‘feature’) console.warn(‘Heads up! This is a warning’) console.error(‘Something is wrong’) console.groupEnd(‘feature’)</pre>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*rMwm77JyiXtzVsSljonvtQ.png"><figcaption>Illustration: console.group example in Firefox. console messages grouped within a console group called “feature.”</figcaption></figure>console.table(): Prints a table representation of the data provided. The method accepts objects and arrays.
console.table([{ a: 1, b: 2 }])
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*DB4_roBRCsKjULq_zPce-A.png"><figcaption>Illustration: console.table example in Firefox. console messages are displayed in a table representation</figcaption></figure><h4>Some final words</h4>
It’s not uncommon [for JavaScript beginners and professionals] to just print strings that say “works” or “done” or something similar and then use them to “confirm” that our code works as expected. I’ve seen far too many uses of console.log() in different places in a codebase simultaneously during a pair programming session.
Browser consoles are great tools, and we should use the great utils they provide to our benefit; testing JavaScript methods or extracts, playing with Document Object Model (DOM) or objects in our code. We can do much more with the console than log simple strings, numbers, or lengths on a list.
We should focus on understanding the underlying code and using the console for its benefits and not as a tool for confirmation; then, we will learn faster, become more confident and write better code in the future.
Thanks for reading
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ff4b85df5268" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/stop-overusing-console-log-in-javascript-ff4b85df5268">Stop Overusing Console.log in JavaScript</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*nbN27RdqN2KqpTZGCjWUAA.jpeg"><figcaption>Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served. Photo by: <a href="https://unsplash.com/@kyleunderscorehead">https://unsplash.com/@kyleunderscorehead</a></figcaption></figure>Single-Page Applications (SPA’s, or dynamic) and server-based, also called Server Side Rendered (SSR) applications, are probably the most popular ways to create websites these days. But also Static Site Generation (SSG) has become very popular in the past years.
When we need a fast, simple, secure, and cheap website, our next project should be using Static Site Generation.
<h3>Static vs. dynamic websites</h3>
To begin with, we should clear up what the main differences between a static generated website and dynamic websites are:
A static website is pre-built (on the server) and fetched once on the client without a server.
<ul><li>Static-generated sites are just a bunch of HTML files. The site may be updated and re-build when publishing new content through a Content Delivery Network (CDN) or when pushing new features. With static site generation, websites become fast; they are easy to publish and secure! We will drill deeper into these benefits later on.</li></ul>
A dynamic website is when files are changed on the server and fetched on the client on each change.
<ul><li>Dynamic sites consist of a backend with servers and databases. The site’s content changes dynamically and needs to interact with a database to generate the files “on the fly.” Also, the site needs to fetch the content every time someone revisits the site. Dynamic sites are harder to maintain and less reliable.</li></ul>
<h3>Benefits of Static Site Generation</h3>
Dynamic and statically generated websites are suitable for different types of applications. Static Generation has unique features for creating a website with few dependencies, and suites better when meeting business goals is crucial.
We will look at eight benefits that SSG provide, whereas dynamic websites are not quite as good:
<h4>No need for a backend developer</h4>
We won’t need a backend developer to make an SSG website. Content Administrators and Writers can maintain a Content Management System that stores and have manageable content. Also, a Content Delivery Network (CDN) is a great place to upload our static files.
<h4>Better reliability</h4>
We won’t receive irritating error messages like “500 Internal Server Error.” on an SSG website. The only possible time we will get errors is when the hosting provider gets issues, which rarely happens. Besides that, our website will not have downtime or be unavailable. We will also not need to worry about dynamically scaling our servers or databases.
<h4>Simplicity</h4>
With Static Site Generation comes simplicity. They require no servers or databases. Some JavaScript frameworks, like React-based ones NextJS or GatsbyJS and SvelteJS, provide build-in support and help us generate, minify, and bundle static HTML files at build time. The static files can easily change or move from one hosting service to another.
<h4>Performance</h4>
Static Site Generation gives excellent performance and is fast. We won’t need to wait for many spinners [or skeletons] to tell the user that something is on the way and will replace it at some point.
Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served.
<h4>Security</h4>
We will have excellent security since we don’t need a database or servers running, and they are vulnerable to security breaches. Compilation of source code and content ahead of time (AoT) makes it impossible for hackers to access our databases, CMS, or servers. Since there are no servers involved, the site is also more resilient to DDoS attacks.
<h4>Lower costs</h4>
We may choose to upload our static content to services like Netlify, Vercel, Amazon S3, Google Cloud Platform, and Microsoft Azure; these services are also entirely free. Hosting static content is cheap and requires less bandwidth. And since our site will be less vulnerable to security breaches, we may use that left-over-money for other essential business goals instead of thinking of security monitoring.
<h4>Improved SEO</h4>
Dynamic sites can be complex when we want to optimize our website for search engines. And if it’s crucial for our site and content. The most common problems with dynamic sites are that these are fast at first page-load, but most critical content is fetched and displayed asynchronously.
We get well-optimized content for SEO with pre-rendered content and fast page load. Good SEO optimization will give a low or decreased “bounce rate,” which is the proportion of visitors leaving the website. It also improves search traffic, better lead generation, and customer engagement.
<h4>Scalability</h4>
Static Site Generation provides excellent scalability; we cannot always say the same with dynamic sites. So let’s take a scenario where we may have scalability issues with a dynamic site:
<ul><li>We have a website that a few visitors typically use. At one point (maybe just a few minutes), the site can be used by thousands of users simultaneously. Maybe we’ve published something that has gone viral — such as news — or a DDoS attack. Such an event can be costly, grow rapidly in volume and take down our servers in the worst case. Such events can cause an unexpectedly large number of server requests and will potentially generate dynamic content for each of the thousands of unexpected users.</li></ul>
Static content and SSG are different: The website is pre-generated, with styles and content. Users only need to download the page’s content that they are visiting.
<h3>Conclusion</h3>
We should use Static Site Generation when making a blog, landing page, newspaper, hotel booking service, or e-commerce store. On some occasions, we may even combine dynamic and static content, where our public pages as static pre-rendered content and internal or user-oriented pages are dynamic.
When running an online newspaper, combing dynamic and static content might be a good choice. The front pages can be of static content presented on the page to the users as soon as they enter, with main headlines and images, and videos can have a generated GIF instead of loading in a preview. Articles can then be fetched by an identifier (id) in the URL and rendered in a separate application or on a different route on the website that dynamically retrieves the content.
Static Site Generation should be considered over dynamic SPA’s if any of the abovementioned points are crucial for our organization, whether costs, user experience, or performance.
Thanks for reading!
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fb187d1ffe6" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/benefits-of-static-websites-5fb187d1ffe6">Benefits of Static Site Generation</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.