Så du skrev feil i terminalen. Igjen. Glemte sudo. Skrev less istedenfor ls. Dette er meg hver. eneste. dag. Men fortvil ikke, det finnes hjelp og snarveier!

Terminalen din kan hjelpe deg når du tuller til, noe jeg gjør støtt og stadig. Den kommer nemlig med historikk som du kan aksessere relativt lett, og gjøre at du ikke må skrive hele kommandoen din en gang til.

!! eller “…Bare gi meg forrige kommando igjen!!” ‼️

Dobbel utropstegn, !!, er en livredder for oss som trenger eller har trengt sudo. Du paster en kommando du fant på nett for å installere et verktøy du trenger. Bare for å bli møtt med en melding om at du ikke har tilgang til å installere ting. Du glemte sudo. Igjen.

Frykt ikke! !! betyr rett og slett forrige kommando. Så her kan vi bare skrive sudo !! og vi får installert det vi skulle. Enkelt og greit!

!$ eller “#$@!%, du vet jeg mente git og ikke gti” 🤬

Greit, nå har jeg funnet ut hvilke filer som ligger i /sykt/lang/sti/til/mappe med ls /sykt/lang/sti/til/mappe , og vil lese innholdet i den ene fila. Jaja, jeg får bare auto-complete med tab eller copy-paste hele stien inn i less.

Dette trenger du heldigvis ikke å gjøre! !$ betyr alle parameterne til forrige kommando. Så dersom forrige kommando var ls /sykt/lang/sti/til/mappeså blir less !$ til less /sykt/lang/sti/til/mappe slik at du lett kan legge på /filnavn på slutten.

Hvis du skrev gti og ikke git som meg, så kan det også være like rask å skriv git !$ istedenfor å bla deg tilbake i forrige setning for å rette opp skrivefeilen din!

Cd meg hit og dit 📂

Jeg kan ikke innrømme hvor mange ganger jeg har trykket enter for fort etter å ha skrevet cd. I blant så fort at jeg ikke har begynt på en ny sti. Da tar cd meg glatt til rotmappa på maskinen min. Som definitivt var det jeg mente å gjøre. Jaja, da er det bare å begynne å cd fra rotmappa til jeg er tilbake der jeg var, og så gå dit jeg skulle. Eller?

cd - to the rescue! cd har nemlig også en historikk! - betyr forrige sted jeg var, -[n] lar deg gå n steg tilbake i cd-historikken. Så hvis jeg vil tilbake der jeg var etter å ha skrevet cd .. 3 ganger på rad, er det ikke verre enn cd -3.

Husk på det neste gang du havner på blåtur i terminalen din opp til rotmappa!


Sulten på mer? 😋

Dersom du umiddelbart tenker "Hva mer kan jeg finne av historikk i terminalen min som jeg kan refere til i kommandoer?" så har denne flotte, CSS-sparsommelige manualen til bash enda litt mer snacks: https://ftp.gnu.org/old-gnu/Manuals/bash/html_chapter/bashref_9.html#SEC115







Terminaltriks for deg som skriver feil

Resetting state in a React application is a common thing to do. You get some new data in your props, and you want to set your state back to the initial values, and often it is done with useEffect. However, useEffects can be messy and hard to understand, and it's because you (and I) are using them wrong (🔥). Let's take a look at how to solve this in a better way by using the key attribute.

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

Resetting state with useEffects

When a user is navigating through your application you may want to reset some of the state to show the correct data. Take a look at the example below of a simple article component:

In the code above you have the Article component which gets an articleId as a prop, and you have a local state keeping track of the number of likes a user wants to give the article. We also have a useEffect that listens to the articleId and resets the value of likes whenever it changes. This is because we want to give the user a clean slate when he or she navigates to another article and wants to rate that article as well. This is a simple case, but it is pretty annoying to have the useEffect which must monitor the articleId, and reset everything whenever it changes. And it doesn't end there, because all child components for the Article component must also have the logic of resetting state to make sure all data is related to the same article further down the tree.

The useEffect hook is handy, but in most cases, you don't need it. UseEffects are for synchronizing effects, not setting state back to their default values. Let's look at how and why using the key attribute instead of a useEffect will save your application from many unnecessary lines of code and re-renders.

Resetting state with the key attribute

The key attribute is commonly used when rendering a list of items in React. Maybe you have seen a warning in your console saying Warning: Each child in a list should have a unique "key" prop, telling you to add a unique key to the siblings of components. This is to help React identify a specific component in a list of components, making sure to update the correct item when changes are made to the list (i.e. filtering or removing items in the list). 

In addition to using key on list elements, you can use it on individual components as well. This will solve our case with resetting case because instead of forcing new data on the same mounted component and resetting every state with useEffect, React will create a new instance of the component for each key. Read more about the key attribute in the React beta documentation for more information.

Let's add the key attribute to the component in the example above to reset the state. Take a look at the example below:

That's it! You add an attribute and you can drop the redundant useEffect 🎉. 

For more info, look at this neat article about resetting state from the React documentation.

TL;DR

Use the key attribute on a component to reset all state in a component, not the useEffect hook – useEffects are for side effects and not state updates.

Use key to reset state in React

Universell utforming. Vi vet alle hva det er, vi vet alle at det er superviktig - og riktig! - å få til, og vi snakker om det hele tiden. Og den aller vanligste måten å jobbe med det på, er fremdeles som tunge skippertak en gang i mellom. Hvordan får universell utforming til å bli en del av teamhverdagen? 

Det åpenbare svaret - som jeg også hører fra designere og utviklere når jeg spør om hvordan de håndterer uu i løsningen sin i hverdagen - er at "de må tenke på det på hver oppgave, og hver gang de slipper noe ut i prod: har vi sikret uu på dette?"

Og det høres så såre enkelt ut. Men hadde det vært så enkelt, så hadde vel ikke løsninger likevel vært så mangelfulle på når det kom til universell utforming? Så hva er det som kommer i veien for at vi faktisk sikrer det løpende?

Jeg har to hypoteser:

1. Tverrfaglighet smerrfaglighet
Det jeg synes jeg hører absolutt oftest fra designere når vi snakker om uu, er: "...men det er liksom utviklerne som må gjøre det". Og så vaskes det hender overalt ut i fra det. Og ja - opprettholdelsen av uu krever riktig koding. Men hva ved brukeropplevelse gjør vel ikke det?

Og så er jo tverrfaglighet i seg selv fremdeles vanskelig i mange team. Jeg ser fortsatt boards hvor design basically har sin egen kolonne, eller egne "brukerhistorier", og designere som sukker over at de blir sittende uten så mye å gjøre "fordi utviklerne utvikler". Det er ordentlig vanskelig å spenne over faggapet - eller egentlig å fylle det, sånn at det ikke oppleves som et gap. Måten man snakker sammen på, og deler ansvar og utfører ting sammen på, krever konstant øvelse. Og når det er vanskelig for oss i de fagene vi er så godt kjent med - da er det ikke så rart, kanskje, at det blir vanskelig med uu, som vi vel alle er ganske usikre på, alle sammen.

2. Universell utforming er et "sjekkpunkt"
Jeg tror uu er litt som måling: i et halvmodent team, så snakker vi om det, og minner oss selv på at "det må vi gjøre" - men så er det forbanna vanskelig å likevel gjøre det. Det blir stående som en egen oppgave eller aktivitet - og dermed kan den også prioriteres opp eller ned.

I et team som er modent på måling, er måling helt integrert i teamets hverdag. Da er det ikke et eget punkt på en liste, og hvert fall ikke en egen kolonne i et board - for teamet prater om det hele tiden, det er selvsagt at ting måles, og hver funksjonalitet bygges med målingsbehovet i tankene. Det blir en del av flyten. Det kan fortsatt prioriteres opp eller ned, men det prioriteres integrert med funksjonalitesprioriteringen. Jeg tenker at uu er litt det samme. I ordentlig modne team på uu, er ikke "uu" på et område en oppgave som må assignes noen. Det er ikke noe som må stå på en liste som må krysses av. Det er mer som måling eller sikkerhet - når du utformer løsningen som designer, er det en integrert del av arbeidet du gjør, og når det implementeres i kode, er det en integrert del av tankene du gjør deg. Og det diskuteres sømløst som en del av utforming og utvikling av funksjonaliteten - ikke som en separat greie.

Hva tror dere?
Stemmer hypotesene? Eller er det noe helt annet som kommer i veien?

Hvordan får vi universell utforming til å bli en del av teamhverdagen?

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



Gå for kontinuerlig kommunikasjon!

En helsesjekk for kommunikasjonen i teamet er å vurdere hvor ofte dere snakker sammen. Et tegn på usunn kommunikasjon er at én av teammedlemmene har flere møter med andre enn med teamet. 

Rollene i et team er naturligvis i ulike møter, og da må vi ha som mål å kontinuerlig kommunisere til hverandre det en har hørt i de ulike møtene. Slik kan en skape en god felles oversikt og det styrker teamets evne til å ta gode valg.

En konsekvens av å ikke ha kontinuerlig dialog er at viktig informasjon ikke deles til riktig tid. Produkteier får gjerne forespørsler og informasjon fra mange forskjellige kilder. Dersom produkteier ikke får informasjon, oversikt og forståelse for hva som bør gjøres fra fagpersonene i teamet, står de med et begrenset beslutningsgrunnlag når de sier ja til å “slippe inn” oppgaver i backlogen. Vi har i flere situasjoner opplevd konflikter som kunne vært unngått ved å dele mer informasjon tidligere.

For eksempel kan utviklerne komme frem til at det er nødvendig å gjennomføre omfattende tekniske forbedringer. Dersom produkteier ikke forstår hva som bør gjøres, hvorfor det bør gjøres og når det bør gjøres, kan dette resultere i at produkteier har et helt annet syn på hva som bør prioriteres.

Eller at designer ikke deler innsikt løpende eller ikke tar med teamet på innsiktsarbeid. Da kan produkteier argumentere for å prioritere inn oppgaver basert på innspill og bestillinger fra andre aktører, mens designeren mener det ikke vil treffe brukerens behov. Har en først prioritert noe, så er det verre å ta det tilbake. 

Det beste er om en ikke kommer i situasjonen der en av rollene har prioritert opp noe for hele teamet, uten at hele teamet er involvert.

Vår erfaring er at tett dialog i stor grad styrker oss som utviklingsteam! Med tett dialog mener vi at teamet snakker sammen hver dag, gjerne flere ganger daglig.

Hvilke rutiner har dere for tett og kontinuerlig dialog?



God standup for daglig kommunikasjon? Ukentlig prioriteringsmøte?



Kanskje det kan hjelpe å ta en gjennomgang av hvilke møtepunkter teamet har?

Vårt tips: Del informasjon løpende og kommuniser med teamet daglig.

Hvordan samarbeider vi? Del 1

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.

Hvem er jeg?

Ruben Kive Horn

24 år gammel

Født og oppvokst i Asker

Studerte industriell design på NTNU i Trondheim

Jobbet som designer i 2 år under studiet og 4 måneder i Bekk

Jeg ble designer fordi jeg har alltid hatt en forkjærlighet for ting man ikke tenker over at funker bra. Jeg har alltid hatt den meningen at bra design, det kan være vanskelig å legge merke til siden det fungerer så i flyt med handlingene våre som brukere. Det å lage de usynlige løsningene, det vil jeg etterstrebe!

Hva gjør jeg?

For tiden jobber jeg med Statens vegvesen i fartsdatateamet, et nyoppstartet team som jobber for å tilgjengeliggjøre data om fartsnivået på norske veger. Med denne dataen vil trafikkanalytikere i Statens vegvesen, utrykningspolitiet, kommuner og fylkeskommuner få muligheten til å vedlikeholde og bygge veiene mer datarettet.

Det har vært utrolig spennende og gøy å lage en helt ny tjeneste som ikke erstatter noen eksisterende tjeneste. Vi har gitt brukerne tilgang til data som de sårt trenger og som inntil nå har vært kronglete å få tak i for dem. Det har gitt oss muligheten til å oppleve – sammen med brukerne – at et helt nytt mulighetsrom av potensielle løsninger har åpnet seg.

Den største utfordringen vi har hatt i dette oppdraget er avgrensning av mål og ambisjoner for løsningen på grunn av mangel på tid. Fra oppstart i august har vi kun hatt fire måneder på oss til å sette oss inn i domenet trafikkdata, undersøke brukerbehov og bygge løsningen fra bunnen av. Dette har virkelig lagt press på oss mot å jobbe smidig og finne ut av hva de minste leveransene som gir verdi er. Jeg er sikker på at dette har vært utfordrende for alle i teamet (og kanskje frustrerende til tider), men det har i sin tur vært en god erfaring for oss som fagpersoner, litt som å trene intervaller.

Hvilket tips ville jeg gitt meg selv i starten av oppdraget?

Det tipset jeg ville gitt til meg selv i begynnelsen av dette prosjektet er å booke brukere til intervjuer, brukertester og samtaler laaang tid i forveien, gjerne lenge før man er klar til å ha den samtalen eller brukertesten slik at man slipper å måtte vente. Ingenting motiverer så mye som en tidsfrist!

Dagens designtips

In the previous article we considered how noise reduction filters may be useful in practical applications. In this article we walk through the mathematical and technical aspects of implementing the noise reduction filters used there. We conclude with final remarks comparing our regularization operators to the broader class of moving averages.  The reader is assumed to be conversant in elementary calculus.

Mathematical definition

In this section we build up to the mathematical definition of our discrete mollifier transforms. Considerations of implementation are found in the appropriate sections below.

The continuous case

Pulling a rabbit out of the hat, consider the standard mollifier with parameter epsilon:

the constant A > 0 being chosen so that

To be particular,

The standard mollifiers are smooth (infinitely differentiable) functions vanishing outside the neighbourhood of the origin with radius epsilon.

The insight is that convolution against the standard mollifiers produces smooth functions, even if the original function undergoing the convolution is highly irregular. To be precise, introduce the integral operator sending a function to its convolution against the standard mollifiers:

We call this the mollification of u with parameter epsilon. The convolution is well-defined whenever u is locally integrable in the Lebesgue sense, in which case its mollification is in fact a smooth function. We have thus obtained the smoothing operator in the continuous case:

It is from the good convergence properties of the mollifications back to the original function, as epsilon tends to zero, that the procedure gains its attractiveness. We will not delve into further details on that matter here, preferring instead to turn our attention to the discretization of the mollification operators themselves.

The discrete case

To discretize the mollification operators, we approximate the integrals defining the mollification of a locally integrable function u by means of the trapezoidal rule. Other schemes for numerical quadrature may be applied, but the trapezoidal method reduces in the final analysis down to a particularly nice convolutional form suitable for efficient implementation on a computer, and obtains satisfactory error bounds.

Construe now u as being sampled at n equidistant points, indexed from 0 to n-1, and take epsilon to be k≥1 times the mesh size. Abusing notation ever so slightly, the integral we wish to approximate at index j is thus

Sparing the reader the inevitable juggling of indicies, the discrete mollification of u at index j works out to be

at least for indicies j satisfying 0 ≤ j-k < j+k ≤ n-1, that is, for k ≤ j ≤ n-k-1. It is this form we next seek to implement.

Implementation

We consider the naive implementation of the discrete mollification in Python. It is a simple exercise to port this snippet into any sensible programming language. Readers concerned with efficiency may consult the following subsection and optimize as they see fit.

Translating the discrete mollification operator above into Python directly produces:

The effectiveness of the discrete smoothing operator defined above may be witnessed in the following figure.

Optimizations

Considering the convolutional form of the discrete mollification operators, the computational efficiency may be improved by precomputing the weights for various k and performing the convolution in a more optimized fashion, say through scipy.signal.fftconvolve. We undertake no such endevaour here.

Correcting the tails

The attentive reader may have noticed that the first and last k sample points of the original signal are left unaltered by our implementation, producing noisy artifacts at the tails of our filtered signal. This is undesirable and easy to fix.

Remembering that the discrete mollification is only defined for indicies j satisfying k ≤ j ≤ (n-1)-k, we may simply pad our signal at both ends so as to achieve these inequalities for the portion of the padded signal corresponding to the original signal. In code:

Here is the result:

Comparison with the class of moving averages

We now conclude with a brief comparison of our discrete mollifiers with the broader class of moving averages. A moving average is a convolutional operator of the form

with the weights summing to unity:

Even though our discrete mollifiers are not strictly of the moving average type, they are so asymptotically. Indeed, one may show the estimate

for some constant M≥0 independent of k, proving

Summary

In this article we have undertaken the construction, analysis, and implementation of a family of discrete smoothing operators. Furthermore, the convolutional form of these operators paves the way for efficient implementation in any programming language, making noise reduction filters broadly available. We also related the discrete mollifiers defined here to the broader class of moving averages, discovering their asymptotic membership to this class.

14-Dec

Today's posts

Terminaltriks for deg som skriver feil

Use key to reset state in React

Hvordan får vi universell utforming til å bli en del av teamhverdagen?

Hvordan samarbeider vi? Del 1

Dagens designtips

Smoothing Out Noisy Signals Using Discrete Mollifier Transforms – Part 2