Arbeidsdagen har en tendens til å starte rolig for så å fylles av ting som skal følges opp. Denne luken ser på hvordan jeg bruker notatboken min og hvilken litteratur jeg har tatt inspirasjon fra.

Dette er notatboken min. Den husker de tingene jeg glemmer. Den husker prioriteringene jeg kommer frem til. Den husker hva jeg har gjort. Jeg bruker den flittig.



Jeg avslutter uken mine med å finne frem til neste doble blanke side. For selv om uka nesten er ferdig, er det mye jeg ikke har fått gjort. Og det er nettopp dette notatboka er flink til å huske for meg.



Jeg starter med å fortelle notatboken at neste uke er det uke 50.



Så forteller jeg den at det også neste uke er 5 arbeidsdager. Den siste ruta får den bruke som den vil. Det varierer fra uke til uke.



Så forteller jeg notatboka hva det er jeg ikke er ferdig med og må gjøre neste uke.


Og hva jeg skal på mandag, og eventuelt andre ting jeg vet jeg må gjøre på bestemte dager eller tidspunkt.

Med hodet tømt, kan jeg gå hjem til helg uten å være redd for å glemme noe. Notatboken min vet alt som skal skje og minner meg på det på mandag.



Mens jeg har fri, jobber notatboken min flittig. Den ønsker å fortsette å utvikle seg.

Den leste Getting things done.

Der lærte den om det å lage seg en prosess for å ta imot oppgaver på en måte som lar en følge de opp. Den lærte om å gjøre de oppgavene en kan gjøre på kort tid, 2 min eller mindre, med en gang, da det fort tar mer tid å lage en oppgave på det enn å gjøre det. Den lærte også om å bruke kalendere og andre verktøy for å organisere bestemte typer oppgaver.

Sist, og kanskje viktigst, den lærte at en bør skrive opp hva det neste steget en skal gjøre i en oppgave er. Det lar en komme raskt igang med en oppgave når en plukker den opp.



Den har studert Eisenhower prioriteringsmatrisen. For selv om Getting Things Done sa mye smart, var det lett å miste oversikten over hva som var viktig. Det hjelper ikke å være produktiv hvis en gjør feil ting.

Den lærte om også om andre metoder for å prioritere, som “The Action Priority Matrix”, som ser noe om forholdet mellom innsats og effekt for ulike tiltak.




For å lære mer om lister har den lest boka Every tool is a hammer av Adam Savage

Der snakker Adam om hvordan å tømme hode ut på papir, om å lage lister, om hvordan lage lister med lister, hvordan markere progresjon, hvordan dele opp oppgaver, og om hvordan bygge momentum. Den inspirerer også til å skape og utrykke deg.





Den har også studert Bullet Journaling. Der lærte den om å bruke forskjellige typer bullets for å formidle forskjellig behov. Den lærte også om å lage prosjektsider med notater og en index for å lettere å kunne finne frem til møtereferater og planer. Den syntes at det er spennende at en notatbok og en metodikk for å ta notater kan bli til en bevegelse som normaliserer nevromangfold og deler nyttige verktøy.





Når mandagen kommer, og en ny uke starter husker notatboka mi hvor vi sluttet uken som var. Den bruker det den lærte mens jeg var borte til å gjøre jobben min enklere. 

Jeg vet rett og slett ikke hva jeg skulle gjort uten. 








Notatboken min

Java comes in many versions, if not colors. Different projects and dependencies might rely on different versions. This is where jEnv comes in!

Java versions are easier with jEnv

It seems like it was yesterday I started working on a microservice architecture and saw the need for multiple versions of Java. So it had to be just about a day earlier than yesterday that Even Holte wrote his article in Bekk's Christmas calendar about managing java versions on a mac.

As he writes, jEnv is a neat tool for those us in need of multiple java versions installed at the same time

JEnv

jEnv does not come with its own repository of Java versions, but is a tool for easily changing between versions you have installed yourself.

If you’re on mac or Linux, you can install the official version of jEnv through Homebrew

brew install jenv

Finish your setup by starting jenv on terminal startup by adding it to your .zshrc.







To activate jenv, either restart your terminal or source your config file.

source ~/.zshrc

Addons

No tool is complete without a set of addons, is it? jenv comes with a set of addons, and some of them are a must have. The plugin export handles setting JAVA_HOME, a variable used by many a program to refer to the directory of your Java executable. Another key plugin, should you use maven, is the maven-plugin. Of course, gradle comes with a plugin too!

Set them up once by running these two commands





Windows

Windows-developers: rejoice! New since 2021 is that there do exist a windows version! It is made and maintained by someone privately and with a couple more installation steps, but seemingly works as it should 👏

AdoptOpenJdk + Eclipse Foundation == True

In 2020, AdoptOpenJDK which provided JDKs easily installable through Homebrew, is now a part of the Eclipse Foundation as the Eclipse Adoptium Project. As such, newer Java versions can no longer be found on their github or Homebrew. Instead, they can be found on https://adoptium.net/
The latest version can be installed through

brew install — cask temurin

If you want specific versions, first tap into cask/versions before suffixing the version number.

`brew tap homebrew/cask-versions`

`brew install — cask temurin11`

Then, add it to jEnv by executing jenv add with the full path to the Java variable.

Global / Local Java version

Now that everything is set up, you can start working! The easiest way is to set the Java version you use the most as default. For example, with Java 17: jenv global 17 . In the microservice you are using another version, for example Java 15, simply run jenv local 15 . This version will then be added to file in the directory saving your local version for automatically changing Java version any time you enter that directory. If your team all uses jEnv, this file might be nice to commit to git.




Java versions are easier with jEnv

Changing the state of your component based on the interaction of a user is a common scenario in a React application. Your first instinct may be to put the event logic in a useEffect that depends on some value to change so the effect can be triggered. But why put the event-specific logic some other place than event handlers? To avoid misbehavior in your application, put event logic in the event handlers and not in useEffects.

The content of this article is heavily inspired by the new React docs (which is in beta).

Event logic in useEffects

When a user is interacting with your website you want to trigger something based on what action the user takes. Clicking, selecting, submitting, and other interactions you can think of, can change the state of your application, and maybe you want to trigger a function after the user has interacted with the website.

For instance, say you have an application and the user can add a number of likes to an article. You have an Article component that has article and hasSetNumberOfLikes as props, where article is the content of the article, and hasSetNumberOfLikes is a boolean value telling your component that the article has gotten a number of likes submitted from the user. The component has an event handler that receives a number of likes and calls a function that submits the number of likes to the article. Further on the component has a useEffect that listens to the value of hasSetNumberOfLikes to check if a user has submitted the number of likes, and then sends a notification to the user that the submission was successful. Take a look at the example below:

In the code above you may get some unwanted behavior from the useEffect. Odds are that the effect will be invoked too many times. For instance, if you cached the state of your application, the notification can be sent to the user several times when the user refreshes or navigates back and forth. This is quite annoying as a user when getting bombarded with several notifications for one event you performed. By using useEffects this way, you misuse the intended use case for the useEffect hook. Remember that useEffects are for side effects, not maintaining your local state or props.

Event logic in event handlers

The best solution is to get rid of the useEffect and rather put the event logic as close to the event handlers as possible. It requires less code, and less code is always better 😏. If you feel you are writing repetitive code and it makes you want to put it in a useEffect because "it is simpler" and requires less code, it may be better to extract your code to functions with logic that can be shared between several event handlers. Take a look at the example below:

I realize that it is not always that easy to just "move code close to the event handler", especially in old legacy code bases. However, I think this is something we need to pursue when writing new code or rewriting something that is old, to make reliable applications.

TL;DR

Drop the useEffects for event logic, put all the event-specific logic as close as possible to the event handlers.

Put event logic in event handlers in React

Økonomien vår preges av økende politisk uro, og stadig større påvirkning fra klimaendringene. I en slik økonomi blir lange, lineære verdikjeder utsatt for betydelig risiko. Gjennom de sirkulære mekanismene slanking, bremsing og lukking kan verdikjedene bli mer motstandsdyktige i usikre tider.

Sirkulærøkonomi har fått stadig mer fokus de siste årene, og de fleste ser et stort behov for å redusere miljøpåvirkningen fra økonomien vår. Sirkulær transformasjon anses likevel av mange som et overskuddsprosjekt, drevet av hensyn til bedriftenes samfunnsansvar heller enn til lønnsomhet. I en verden preget av økende politisk uro og store påvirkninger fra klimaendringene, er det imidlertid god grunn til å tro at sirkularitet også kan bidra til å øke bunnlinjen.

Tradisjonell økonomi er lineær, hvilket betyr at virksomheter skaper verdi gjennom lineære verdikjeder. Slike verdikjeder starter med utvinning av råvarer i en ende, og ender med avfall i den andre. Fokuset i en lineær verdikjede er å kutte kostnader til et minimum, og produsere så mye som mulig innenfor kostnadsrammen. Økonomien vår kjennetegnes også av høy grad av globalisering og spesialisering. I en slik økonomi har verdikjedene mange små, spesialiserte ledd, og de går gjerne over flere landegrenser. Handel går over landegrenser, og produksjon lokaliseres til landene hvor innsatsfaktorene er billigst.

Det er for de fleste ganske åpenbart at slike lineære verdikjeder er problematiske fra et miljøperspektiv - de utvinner store mengder råvarer i en ende, og produserer store mengder avfall i den andre. Et aspekt ved disse verdikjedene som ikke får like mye oppmerksomhet, er verdikjederisikoen de innebærer. Økonomien vår preges av stadig mer usikkerhet, spesielt som følge av påvirkning fra klimaendringene og økende grad av politisk uro. Dette medfører en økt risiko for at det oppstår problemer i lineære verdikjeder med mange ledd. Satt på spissen, så kan produksjonen av en hel bil stoppe dersom gummien til dekkene ikke er mulig å få tak i. Gjennom sirkulær transformasjon av verdikjeden kan man redusere denne risikoen.

Sirkulære verdikjeder karakteriseres av tre mekanismer; slanke, bremse og lukke. Slanking av verdikjeden handler om å redusere bruken av nye innsatsfaktorer, og fokusere på å få mest mulig ut av de jomfruelige innsatsfaktorene som puttes inn i verdikjeden. Et eksempel på dette er å benytte resirkulert plast som innsatsfaktor i stedet for ny plast. Bremsing av verdikjeden handler om å forlenge tiden fra en innsatsfaktor går inn i verdikjeden i en ende, til den går ut som avfall i andre ende. Et eksempel på en slik mekanisme er å tilby reparasjon av produkter, og slik forlenge produktets levetid. I en lukket verdikjede har man designet avfallet ut av verdikjeden, og innsatsfaktorene blir igjen til innsatsfaktorer i slutten av livsløpet. Et eksempel på en slik verdikjede er panteordningen på plastflasker.

Felles for alle de tre mekanismene er at de reduserer behovet for nye innsatsfaktorer, og det er også slik de kan redusere risikoen i lineære verdikjeder. Ved å finne måter å gjenbruke innsatsfaktorer i verdikjeden, og dermed bruke mindre av nye innsatsfaktorer, tas råvarerisikoen betraktelig ned. Da blir verdikjeden mer motstandsdyktig mot påvirkning fra eksempelvis klimaforandringer og ekstremvær, som kan forstyrre tilførselen av en råvare. Her ser vi en spennende utvikling innen elektronikkindustrien. Produkter som PCer og telefoner har tradisjonelt vært svært utsatt for råvaremangel i enkeltledd i verdikjeden, for eksempel mikrochipmangelen. For å bøte på denne risikoen, har flere produsenter i de siste årene begynt å ta i mot brukte PCer og telefoner gjennom ulike panteordninger. Da kan de få komponenter inn i verdikjeden igjen, og de blir mindre avhengige av risikoutsatte ledd i verdikjeden.

Ved å gjenbruke ressursene lokalt, tar man også ned transport- og handelsrisiko. Hvis man kan gjøre seg mindre avhengig av å sende innsatsfaktorer eller produkter over store avstander og landegrenser, reduseres risikoen for at verdikjeden påvirkes av eksempelvis politisk uro og handelssanksjoner. Bare det siste året har vi sett mange eksempler på at bedrifter har blitt tvunget til å tenke nytt rundt verdikjedene sine og avhengighetene de har til andre land. Eksempelvis har mange måttet finne måter å unngå handel med Russland, eller måter å redusere påvirkningen fra krigssituasjonen i Ukraina.

I en verden preget av stadig mer usikkerhet, store påvirkninger fra klimaforandringene og økende politisk uro, kan man argumentere for at sirkulær transformasjon av verdikjeden gir gevinster både for miljøet og for virksomheten. Gjennom å slanke, bremse og lukke verdikjeden reduseres risikoen for at det oppstår problemer i ledd i verdikjeden, og som en bonus reduseres samtidig den negative påvirkningen på miljøet.



Interessert i å lære mer om sirkulær økonomi? Se blogginnleggene fra mine kollegaer som er lenket under! 

Hvordan sirkularitet skaper mer motstandsdyktige verdikjeder

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips.

Kven er eg?

Åshild Aaen Torpe

35 år

Frå verdas vakraste bygd – Voss

Master i Informatikk: Design, bruk, interaksjon frå Universitetet i Oslo

Har jobba som interaksjonsdesigner i 10,5 år

Eg blei egentlig designar litt på slumpelukke ved å snuble ganske tilfeldig inn i informatikkverda då eg ikkje kom inn på førstevalet mitt etter vidaregåande. I løpet av dei tre åra mine på bachelorstudiet Nye Medier ved Universitetet i Bergen var eg innom mange ulike emne innan både informatikk og medier, og det var ikkje før ei forelesning med Tone Nordbø eg fann ut at interaksjonsdesign faktisk var ei eiga retning å gå. Eg satt heilt fortrylla og slukte alt som blei sagt – for ei lukke at akkurat det eg interesserte meg for var noko det gjekk an å jobbe med på heiltid! Back in the days i 2007 var ikkje interaksjonsdesign ei veldig kjend retning, og eg hadde rett og slett aldri høyrd om det før.

Kva gjer eg (og korleis)?

Det siste året har eg vore på oppdrag hos Entur der eg er så heldig å sitte saman med Ragnhild (frå designtips luke 8) og jobba med å lage verdas beste reiseplanleggar for app og web. 

Det er utruleg motiverande og givande å skape noko eg veit at veldig mange nyttar seg av i kvardagen sin. I haust har me testa gjennom løysinga vår saman med ein blind brukar, og det har gjort at eg har lært mykje nytt om VoiceOver og korleis ein som ikkje ser nyttar seg av produktet me lagar. Å jobbe med, og ha spesielt fokus på, universell utforming, har gjort at eg er riktig så stolt over  å vite at me leverer eit godt produkt som kan vere nyttig for alle. Noko anna som er kjekt er å kunne ha to designarar i same team, slik at eg alltid har ein diskusjonspartner ved sida av meg!

På den utfordrande sida har eg kjent på at det i den ideelle verda burde det eg gjer vere endå meir basert på måling, vere meir hypotesedrive og ha med seg utviklarane frå start. For min del har det vore litt for lett å gå i "koronafella". Med det meiner eg å stille eit spørsmål på Slack heller enn å stille det direkte til ein av utviklarane på kontoret og det å bruke liiiiitt for lang tid i Figma før diskusjon med utviklarar. 

Kva tips ville eg ha gjeve til meg sjølv i starten av oppdraget? 

Eg har ein gong høyrd at det tar opp mot seks månader å bli onboarda skikkeleg i eit team (om det er basert på fakta veit eg ikkje, men eg synes det er fint å tenke på uansett). Det er altså lov å vere ny (sjølv om ein har jobba i mange år), domenekunnskap kjem litt og litt med tida så ikkje stress med det.

Eit anna tips eg ville ha gjeve meg sjølv er å stupe inn i backlog og trimme denne for designarv tidleg. Saman med produkteigar kan ein rett og slett fjerne oppgåver frå Jira som tidlegare har vore viktige, men som kanskje ikkje er det lengre. Ikkje nødvendigvis fordi det er noko feil med desse oppgåvene, men på grunn av korleis retninga har utvikla seg med produktet du er med på å lage.

Dagens designtips

Google Analytics har vært et omstridt verktøy i lang tid. Ved å inkludere det på nettsidene vi lager hjelper vi Google med å samle inn enda mer data om våre besøkende. Nå har det landet ferske avgjørelser fra datatilsyn i EU som tyder på at verktøyet bryter med GDPR og er ulovlig å bruke.

I lys av Schrems-II dommen ble det klart at overføringer av personinformasjon til USA ikke er i tråd med de beskyttelsene en europeisk borger har krav på. Etter denne dommen valgte organisasjonen Non Of Your Business (NOYB) å melde 101 nettsider for brudd på GDPR fordi de brukte Google Analytics, og dermed sendte persondata til USA.

De siste dagene har det kommet to avgjørelser fra europeiske datatilsyn som tyder på at loven tolkes slik at bruk av Google Analytics vil være å anse som et brudd på GDPR sine restriksjoner mot overføring til tredjeland.

EDPS — datatilsynet for EUs organer — har gitt en reprimande til EU-parlamentet for deres bruk av Google Analytics på en intern nettside for COVID-testing. Dette ble ansett som en ulovlig overføring av personinformasjon til USA, og dermed brudd med den versjonen av GDPR som gjelder for EUs organer.

Østerrikes datatilsyn har i en av de 101 innklagede sakene fra NOYB avgjort at bruken av Google Analytics var i strid med GDPR. Dette er viktig, da Østerrikes datatilsyn er utpekt til å lede en felles innsatsgruppe for å avgjøre alle de 101 klagene. Det er dermed stor grunn til å tro at alle de andre sakene vil gå i NOYBs favør.

Avgjørelsen tar også høyde for om det er tilstrekkelig å benytte seg av funksjonaliteten i Google Analytics som skjuler IP-adressen til brukeren. Max Schrems (ja, den Schrems), som også leder NOYB, svarte klart nei på dette på Twitter.

Alt dette tyder på at bedrifter som benytter seg av Google Analytics, og tilsvarende analyseverktøy der dataene sendes til USA, snarest må legge planer for å gå over til alternativer som ikke bryter med rettighetene til europeiske borgere.

Vi må slutte å bruke Google Analytics

Hva skal til for å få et godt samarbeid mellom produkteier og designer? Og et godt samarbeid i teamet? 



Hverdagen i et team fungerer dårlig når vi tenker at jobben vår er begrenset til “rollen” vår 

Vi må slutte å snakke om arbeidsoppgaver knyttet til en rolle. Vi må snakke om hvilke arbeidsoppgaver teamet har. Hva skal til for å lage et knallbra produkt? 

Det er, selvfølgelig, så mye mer enn de klassiske arbeidsoppgavene som “tegne en skisse”, “være i et møte” eller “skrive en kodelinje”. For eksempel hvis en produkteier som jobber i et team kun er opptatt av å måle effekten av produktet, men ikke ønsker å jobbe sammen med teamet på alt som skal til for å få til et godt produkt, så vil samarbeidet skurre.

Vi har ulike roller inn i et tverrfaglig team for å ha med ulik kompetanse og perspektiver, men det er et must at vi faktisk samarbeider i teamet. Hva betyr det i praksis? Det betyr at vi ofte må gjøre arbeidsoppgaver som ikke nødvendigvis er én rolle sitt typiske ansvar. 

At en produkteier kan ta ansvar for rekruttering av brukere til intervju. At en designer kan ta ansvar for personverndokumentasjon. At en produkteier argumenterer for å bruke tid på teknisk gjeld. At en utvikler kan ta hovedansvaret for å ta notater fra et brukerintervju. 

Det er ikke nødvendigvis en klassisk arbeidsoppgave for rollen — men det er en del av det å være med i et team som lager et digitalt produkt. Teamet må forstå hvor hver enkelt kommer fra og hva arbeidsoppgavene til hele teamet er. 

Opplever du at folkene i teamet ditt har for mye fokus på sin egen rolle? Det finnes ikke noe enkel medisin, men her er noe som kan testes ut:

Være mer bevisst antagelsene vi har om hverandre: Snakk om forventninger til hverandre. Hvilken bakgrunn har du? Hvilket fag “kommer du” fra? Hva er din erfaring med å lage digitale produkter?



Hvem tar beslutninger? Hvilke beslutninger tar designer og hvilke tar produkteier?



Snakk om forventninger til hver enkelt: Hva opplever du at du blir målt på? Hvem har forventninger til deg utenfor teamet? Hva gjør du på jobben når du tenker “dette er en bra arbeidsdag”?



Test ut Team Canvas og spesielt delen om roller. En morsom variant er å ikke beskrive sin egen rolle og bidrag inn i teamet, men at de andre skal beskrive din rolle. Prøv å la folk lufte noen antagelser om hverandres bidrag inn i teamet.

Vårt tips: Hverdagen i et team fungerer best når vi tenker at jobben vår er alle de arbeidsoppgavene teamet har. At vi jobber SAMMEN.

16-Dec

Today's posts

Notatboken min

Java versions are easier with jEnv

Put event logic in event handlers in React

Hvordan sirkularitet skaper mer motstandsdyktige verdikjeder

Dagens designtips

Vi må slutte å bruke Google Analytics

Hvordan samarbeider vi? Del 3