14 dagar att til jul! Treng du nokre tips til hektiske innspurtsdagar, leiter etter inspirasjon til gode brukaropplevingar, eller lurer du kanskje på kva julesong du skal sette på til arbeidet og kva julefilm du bør få med deg før jula ringes inn? Eg har tatt juletemperaturen på fem av designarane våre i eit forsøk på å finne svar.

Guro Johanson, interaksjonsdesignar

Kva jobbar du med akkurat no?\ Jeg jobber hos Vipps, og der jobber jeg i et team som jobber med å forenkle hverdagen til både bedriftskundene og de ansatte i Vipps. En av tingene jeg holder på med akkurat nå er å slå sammen flere interne verktøy til ett, slik at de ansatte i Vipps skal slippe å forholde seg til så mange ulike systemet når de hjelper kundene.

Kva er du mest nøgd med å ha fått til i år?\ Jeg er mest fornøyd med hvor langt vi har kommet i løpet av det siste året totalt sett. Vi gjør stadig små forbedringer for brukerne våre, og til sammen har alle endringene gjort at systemene vi jobber med er blitt veldig mye bedre enn det var. Det er fort gjort å glemme hvor mye mange små ting får å si til sammen.

Kva er favorittverktøyet ditt i designverda og kvifor?\ Det må vel være Figma. Jeg synes Figma er helt genialt – rett og slett fordi det løser så mange av mine behov i ett. Før måtte jeg bruke flere ulike verktøy for å gjøre det samme som Figma gjør for meg i dag. Det er veldig praktisk å kunne jobbe med andre designere og utviklere i samme fil samtidig, og se live hva vi holder på med.

I tillegg er jeg veldig glad i WhatFont, som er en enkel og praktisk utvidelse til Chrome. Den viser hvilken font og størrelse en tekst er skrevet i, uten at jeg må inspisere koden.

Kva er ditt beste tips til hektiske innspurtsdagar før jul?\ Jeg har ikke noe revolusjonerende tips å komme med, dessverre. Men når jeg har mye å gjøre så liker jeg å sette opp en liste over alt som skal gjøres, og prioritere den med det viktigste først. Jeg lager oppgavene så små og konkrete som mulig, slik at jeg får mange små seire når jeg kan markere de som utført!

Kva er den beste bruker-/kundeopplevinga du har vore bort i løpet av året?\ Her vil jeg trekke frem Eyr, som gjør det mulig å få snakke med en lege fra der du er. Det var veldig praktisk da jeg skulle reise til Afrika. Jeg trengte bare å fylle ut et enkelt skjema om hvor jeg skulle, så fikk jeg svar fra en lege i løpet av dagen om hva jeg trengte av vaksiner og medisiner. Så kunne jeg bare møte opp på et apotek når det passet meg og få satt vaksinene der.

Bonusspørsmål: Kva er favorittjulelåta og favorittjulefilmen din?\ Det blir ikke ordentlig juleaften uten Tre nøtter til Askepott! Favorittjulelåt er vanskeligere å velge... men Det lyser i stille grender har jeg vært glad i helt siden jeg var liten.

Robert Austnes, visuell designar

Kva jobbar du med akkurat no?\ Jeg jobber med litt av alt om dagen. Mye av tiden går til administrative oppgaver i Bekk, mens på prosjekt hos Vy er jeg innom designsystem, nytt ikonbibliotek og utvikling av den nye taxitjenesten som dukker opp om ikke så altfor lenge.

Kva er du mest nøgd med å ha fått til i år?\ Jeg er fornøyd med å ha bidratt til å bygge Vy sin nye merkevare. Det er bare i startfasen enda på uttak digitalt, men med et stadig bedre designsystem, omskriving av kode og flinke designere som dytter på, skjer det mye bra fremover.

Kva er favorittverktøyet ditt i designverda og kvifor?\ Sketch. Jeg bruker stort sett bare det i hverdagen. Men du skal ikke undervurdere litt penn og papir heller, det kommer fort mye bra ut av litt rabling i blokka.

Kva er ditt beste tips til hektiske innspurtsdagar før jul?\ November og desember er veldig hektiske måneder, både på prosjekt og i Bekk. Så jeg prøver å være flink til å prioritere og planlegge uken på søndager. Det kommer jo alltid litt inn fra sidelinjen, men da har jeg i alle fall oversikt over det mest prekære, så det ikke går i glemmeboken. Så prøver jeg å ta meg tid til å koble av mellom slagene med en sykkeltur eller en løpetur i marka.

Kva er den beste bruker-/kundeopplevinga du har vore bort i løpet av året?\ Jeg liker veldig godt den nye NRK-appen Heydays gjorde. Både design og brukeropplevelse er veldig bra.

Bonusspørsmål: Kva er favorittjulelåta og favorittjulefilmen din?\ Julelåt må være The Pogues, Fairytale of New York. Favorittfilm må vel være Alene Hjemme 1 og 2. Da er det jul!

Ola Claussen, interaksjonsdesignar

Kva jobbar du med akkurat no?\ Akkurat nå jobber jeg med å få søket på Finanstilsynets nettsider til å bli nytt og bra. Det betyr et dypdykk ned i en rar verden av hvordan det maskineriet fungerer. I tillegg jobber jeg en del meg Sentralfag, et internt system som Finanstilsynet bruker for å holde oversikt over alt de følger opp.

Kva er du mest nøgd med å ha fått til i år?\ Det jeg er mest fornøyd med å ha fått til i år må faktisk være søket som vi jobber med akkurat nå. Ikke fordi det kommer til å bli superinnovativt eller råere enn Google, men fordi vi har fått til en god prosess sammen med kunden. Design og utvikling har gått hånd i hånd, vi leverer smidig, designet blir litt til underveis og vi lærer underveis. Det har ikke vært noen selvfølge at prosessen skulle være slik, men jeg er veldig glad for at vi har fått til det når man ser hvor vanskelig det kan være å jobbe med søkeresultater som materiale.

Hvorfor er dette så fett for meg som designer? Det å sitte som en designer og prøve å forutsi hvordan et søk vil fungere og hvilke treff man får er så å si umulig, men det er også det som blir grunnlaget for en god brukeropplevelse. Så det å få lov til å jobbe med design av søk samtidig som man har et søk som faktisk fungerer, få lov til å endre mening underveis når man får ekte feedback og ikke bare synsing er gøy!

Kva er favorittverktøyet ditt i designverda og kvifor?\ Store whiteboards har alltid vært favoritten. Det er noe tilfredsstillende med å ha en helg vegg å tegne på! Og så er det så enkelt å viske ut ting som man ikke blir fornøyd med!

Kva er ditt beste tips til hektiske innspurtsdagar før jul?\ Tv-peis!

Har du to dataskjermer tilgjengelig så jobb på den ene mens du fyrer opp YouTube og søker opp «Fireplace no ads» på den andre. Sett på noen gode tunes, gjerne julemusikk! Det kan få enhver lang og hektisk dag til å bli litt bedre! Min favoritt: «4 Hours Fireplace in Full HD With Real Crackling Sound»

Kva er den beste bruker-/kundeopplevinga du har vore bort i løpet av året?\ Hvis det er en ting som i hvert fall har fått meg til å endre litt adferd så må det være å ha fått smartklokke med eSIM. Jeg er ikke noe stor fan av å ha med meg mobilen over alt, samtidig så får jeg FOMO-følelsen når jeg ikke har den. Så det å nå kunne la mobilen ligge igjen hjemme når jeg skal ta meg en tur, uten å måtte føle at jeg har glemt noe har vært en digg greie.

Bonusspørsmål: Kva er favorittjulelåta og favorittjulefilmen din?\ Favorittjulelåten må bli Both Sides Now av Joni Mitchell selv om den kan være litt trist. Favorittjulefilmen blir Hjemme Alene.

Hans Christian Øren, visuell designar

Kva jobbar du med akkurat no?\ Akkurat nå jobber jeg med Pekepinn og barn.

Kva er du mest nøgd med å ha fått til i år?\ Det jeg er mest fornøyd med er at Pushwagnesizer har fått så mye oppmerksomhet.

Kva er favorittverktøyet ditt i designverda og kvifor?\ Adobe Illustrator. Jeg får stor kreativ frihet der jeg kan lage alt fra enkle skisser til mer detaljerte illustrasjoner.

Kva er ditt beste tips til hektiske innspurtsdagar før jul?\ Pass på å få gjort alt ferdig slik at du ikke sitter på juleaften og jobber.

Kva er den beste bruker-/kundeopplevinga du har vore bort i løpet av året?\ Det er mange, men de to siste er Déplacé Maison og Pygar.

Bonusspørsmål: Kva er favorittjulelåta og favorittjulefilmen din?\ Favorittjuelåta er Driving Home for Christmas av Chris Rea, og favorittjulefilmen er Hjemme Alene 1

Thea Snilsberg Søfting, interaksjonsdesignar

Kva jobbar du med akkurat no?\ Jeg jobber med å hjelpe studenter å finne folka de bør bo med i Leile. For tiden så utforsker jeg hvordan vi kan være mer rådgivende i tjenesten vår for å hjelpe brukerne våre å oppnå suksess, så det går mest i konseptutvikling og innsiktsarbeid.

Kva er du mest nøgd med å ha fått til i år?\ Generelt hele året på Leile, egentlig! Vi vet at verdiforslaget vårt treffer, og det føles godt å vite at vi har funnet et så riktig og konkret problem å ta tak i. Selv om vi ikke har klart å løse problemet deres helt enda, så er jeg stolt av å ha vært med å forme Leile til det det er i dag.

Kva er favorittverktøyet ditt i designverda og kvifor?\ En god tusj og papir vil nok alltid være favorittverktøyet, men i løpet av året har Figma bitt mitt go-to designverktøy. Hovedsakelig bruker jeg det til å skisse, prototype og jobbe med flyten i tjenesten vår, men det fungerer også utmerket som et verktøy for diskusjon og samarbeid i teamet.

Kva er ditt beste tips til hektiske innspurtsdagar før jul?\ Generelt når det er hektisk er det utrolig viktig for meg å skrive ned absolutt alt jeg må og skal gjøre, enten det er på jobb eller privat. Jeg har blitt veldig glad i Things, der klarer jeg å holde styr på alt!

Kva er den beste bruker-/kundeopplevinga du har vore bort i løpet av året?\ Animasjonene i Klarna-appen er utrolig søte, og generelt har de et veldig gjennomarbeidet design og en god brukeropplevelse. Jeg er også en person som sjekker været hver eneste morgen, så er veldig glad i varselet jeg får automatisk fra Yr-appen når jeg våkner!

Bonusspørsmål: Kva er favorittjulelåta og favorittjulefilmen din?\ Julefilm er definitivt Elf, og julesang er Jul i Svingen av Ingebjørg Bratland.

Juletempen på fem designarar i Bekk

Hacktoberfest provides a great opportunity for people to win a t-shirt. But it is also a great way for maintainers of open source code to get some help with their issues. Here are some of my experiences from being a maintainer this October.

First of all, if you don't know what Hacktoberfest is, get a quick introduction here: https://opensource.christmas/2019/6

The main thing I learned from trying to be a maintainer during Hacktoberfest is that Hacktoberfest is really popular. Most of the issues I created were picked after few minutes. The power of tagging the issues with "hacktoberfest" was truly remarkable. I had to laugh when two people asked for the same issue, and not long after a third person submitted a pull request (#21).

I think that defining issues with a small scope and no (or little) requirement of understanding the domain of the application is important for having success as a maintainer during hacktoberfest. I tried to follow these principles and had success with issues like "Initialize TypeScript", "Rewrite this script from bash to Node.js" and "Rewrite this class component into a function component". These kinds of issues should be possible to do "mechanically" without necessarily understanding much of what the app really does.

Things might go wrong, and I experienced this. Through Hacktoberfest I got help with rewriting some React class components into being function ones. I reviewed the code, it looked good to me, and I merged it. The app was configured to deploy automatically when the master branch was updated. And of course this PR had more than a few flaws, and quite a lot of time was spent fixing it. Having some tests might be a good idea when accepting PRs from the community. And more importantly: no auto-deploy to production. :face_palm: There were also some PRs that really were not following our team’s preferred code style. Often the easiest thing to do was just merge it and fix it ourselves. But using tools like ESLint and Prettier with strict configurations can be very valuable to make it easier for outsiders to write the code you prefer.

The Hacktoberfest official pages also have some tips for maintainers to get the most out of Hacktoberfest. I did not know about this before after October, but make sure to check out the webinars there next year.

Trying out being an open source maintainer during Hacktoberfest was really fun. People are very active and helpful. It comes at a cost though. Reviewing (potentially bad) pull requests, writing well-defined issues and maintaining good README and CONTRIBUTING guides will take some time. But man, is it rewarding and fun! I can’t wait for next October.

Things I learned, summed up:

Hacktoberfest is very popular

Write well-defined, small issues

Create issues that don't require domain knowledge

Use GitHub tags (hacktoberfest, good first issue, help wanted)

Assign people to issues if they request one.

Be ready to receive contributions. Have a good README, maybe some tests, a build step that lints and tests.

Hacktoberfest from a maintainer’s perspective

You double checked, triple checked, even quadruple checked, and it is really there! You have just found a vulnerability in someone else's system. Maybe you just got access to something you shouldn't have, you can prove that an attacker could easily take down the system, or you found your way around the payment process in a shop. Whatever the bug, you now need to disclose it, but in a responsible manner.

Responsible disclosure is an important step in security testing. It is meant to provide the owner of the system with the information necessary to fix the issue, and give them a reasonable amount of time to implement a fix. This means that you will have to treat your findings as confidential, until they are fixed. Only then can you write your cool blog post explaining how you hacked the local sushi shop and got 25 kilos of maki delivered to the mayor's office.

We practice responsible disclosure because we think it is important to give fair warning about a vulnerability. While it is possible that the bug might currently be exploited by others, this is quite unlikely, and given that the vendor fixes their system quite fast, we are actually protecting their users by not going public with what we know. Had we performed irresponsible disclosure, and written up a blogpost the minute we found our bug, there is a high risk that others would exploit it before a fix was in place, maybe forcing the site to be taken down, to avoid even more raw fish at the doorstep of the town hall.

Best practice for responsible disclosure

If you found the vulnerability through participating in a bug bounty, there are clear (and strict) rules for how you are to disclose your findings. In most cases, the bounty program guaranties that you will not meet any legal issues if you follow their disclosure regime. You should make every attempt to follow this procedure. Should you however find a vulnerability on a site not covered by a bug bounty program, the following steps should generally be followed.

The first thing you need to do is find someone to contact, that is in a position to both understand, verify and fix the issue at hand. If you are lucky, the site has set up a security.txt-file at /.well-known/security.txt. This file should contain all contact information necessary.

More likely than not, the site does not have any such contact information. You will have to start sending emails to random people. I would suggest using any generic contact email, contact form on the site (unless you believe this to be compromised), but also look up people who work at the company and attempt contacting them directly. If you have no luck yourself, you could reach out on social media, asking if anyone knows someone at the company that can get in touch with you.

In your contact with the company, you should outline the vulnerability you have found, describe what you consider to be its likely impact, and set a timeframe for when you would expect a patch to be available. This timeframe would also be the time you must keep the vulnerability a secret. As the company researches the issue, and attempts to make a fix, you may be asked to delay disclosure. As long as the terms are reasonable, and there does not appear to be any increased risk for the users of the service, it would be polite to accept this. Should you however feel that there is little progress, and the delays are only used to push the issue further out, you may consider if full disclosure is needed to pressure the vendor.

What if there is only silence?

You may experience some issues with reporting your findings. Maybe you can't find contact information for anyone in the company, maybe there is no response, or maybe you get an initial response, but then hear nothing more. Unfortunately, this is not too uncommon. Not all companies are prepared to deal with a situation like this. You should do your best to get in touch with someone who can help, and follow up with the vendor if they stop responding. However, should all your attempts fail, you may be forced to go public with your findings, without a fix being implemented. This should always be a last resort, and you should have given warning about this in all your communication with the vendor. Many researchers operate with around 90 days after initial contact as their limit, including Google Project Zero, but there may be circumstances where this can be substantially shortened. If you suspect that the vulnerability is being actively exploited, can impact a large number of users, or other circumstances that in your opinion would shorten the acceptable timeframe for disclosure, this might be the right thing to do.

Legal risks

There are certain legal risks with disclosing security vulnerabilities to a vendor. If the company is not well educated on the subject of security, they may attempt to turn on you, and accuse you of hacking with an evil intent. If the issue is made public, you may receive threats of lawsuits. This can be done in the hope that the company will look strong going after the "evil hackers". You should also investigate any laws in your jurisdiction that might impact you when disclosing a vulnerability. If you are unsure about the legal risks you are facing, you may opt to report the vulnerability anonymously, or contacting a lawyer to have your liability assessed.

With this said, more and more companies are joining bug bounties, and publicly announcing that anyone coming forward with a vulnerability in good faith, will not be subject to any legal action.

Responsible disclosure

Companies and developers love the cloud. The cloud provides scalability and resilience to some of the most critical applications for a company. Due to the cloud, companies are no longer required to have large server installations on-premises. Actually, many companies are able to fully migrate almost all of their daily operations into the cloud. So, what are the downsides? Well, according to Info World, there are some major concerns regarding the cloud, one of them being costs. There are many ways to combat costs, and today I want to introduce you to one of my favorite ones, the spot market.

Why use the Spot Market?

What if I told you that renting these servers could give you a discount of up to 90% compared to a regular on-demand server. Still not convinced? Have a look at the graph below.

The graph shows the pricing around Black Friday 2019. As you can see, if you had hosted a server at Amazon eu-west-1c, you would have paid only 10% of the on-demand price! Sounds nice right!? But, there is a catch! Depending on the cloud provider, your provider reserves the right to at any time shut down and remove your server at almost no notice! Let’s dive deeper into the world of Spot Market, and why it's good to prepare to kill your application.

What is the Spot Market?

The Spot Market is in short, the unused/spare resources available at a datacenter/zone. Instead of these resources just being left in an idle state, these resources are auctioned to the highest bidder. So, how do we bid, and how does that process work? Well, TLDR; in order to get an instance, you specify the maximum amount you want to buy your resources for. If your max value is lower than the market price, you will have your server. However, should the market price surpass your bid, then that server is given to someone else. Pretty simple actually. Its kinda like buying and selling stocks.

All the four major cloud providers have some sort of spot market and they are called:

Amazon - EC2 spot instance

Google - Preemtible VMs

Microsoft - Low priority VMs

IBM - Transient virtual servers

Some of the features varies across all the providers, nevertheless, the concept remains mostly the same. For a more detailed comparison, have a look at this article. In this article, we’ll focus on Amazon EC2 spot instances.

How do I use the Spot Market?

To utilize the Spot Market (safely), there are some steps and takes I want to share. There are more to the Spot Market than I can write about in this article, but here are some key takeaways.

1. Identify states in your app

The first step into getting ready for the Spot market is to identify what parts of your app that holds states. Our goal is to make every interaction with our app as atomic as possible, meaning the app should not have processes that depend upon a previous task. This could be as simple as a write-cache, a background task or a file processing that is handled after a file upload is completed, you name it. I recommend having a look at the 12factorapp for some best practices and suggestions that may help along the way.

2. Take advantage of managed services

Managed services (often) have the advantage of scaling to your demand. Therefore, leaving the responsibility of hosting and scaling the service to the cloud provider could be a good idea. Some of the services to consider having as a managed service are typically:

Raw storage (Block storage, object storage).

Database services (SQL, NoSQL, Document Storage, K/V store, Column stores).

Messaging and related services (Event streams, Message brokers).

CDN Services.

Notification services (Email, SMS, Websockets, chatbots(?)).

The list goes on and on… Some may even use Blockchain as a service. Nonetheless, the main point is to utilize these services and let somebody else manage the scaling where that makes sense for your application. Just keep in mind that in some cases it might not make sense to use a managed service if it does not fit the needs of your application.

3. Plan the scaling

Finding out how your application should scale is an important step in your journey to the cloud. In most cases, applications should be written in a way that makes them able to scale horizontally (adding more servers). However, if your application or logic makes that impossible, vertical scaling could also be an option. If your application receives little to no traffic during specific intervals (i.e nights), then running many instances might not be a requirement.

Summary

With this knowledge, you are on your way towards the spot markets. I would recommend investigating the various features that your cloud provider has. Remember, the Spot Market is simply a tool that can be utilized. In many cases, this tool reduces the costs of running your application. In my opinion, if you have an application that works for the Spot Market, then you have a very resilient application that actually will handle an enormous amount of workload. If you found this interesting, I recommend digging into some of the links below. Good luck with your next cloud project.

Prepare to die - An introduction to Spot Market

Alle beslutningsunderlag har alltid skjermbilder av hva produktteamet skal lage. Skjermbildene er ofte dårlige og langt i fra hva som er riktig å lage. Hvorfor er de nødvendige?

Hvorfor har beslutningsgrunnlag skjermbilder?

Kotlin brings with it a lot of good things like Null Safety and full interoperability with Java, but data classes might be one the things you most often notice during day to day work.

Most larger applications, especially those consuming or producing REST apis need lots of DTOs (data transfer objects). These are used to represent plaint data objects which is only used to hold data.

In java an example of such a class could be:

It is possible to use third party libraries or an IDE to help with reduce the amount of code, or generate most of the boilerplate code. Still I prefer to not have the extra lines of code, and if you are going to add or remove fields you still have to regenerate constructors, getters/setters and equals()/hashcode() methods.

Kotlins Data classes

Using data classes in Kotlin the same DTO as above becomes:

The compiler automatically derives

getters and setters for mutable properties and getters for immutable properties.

equals()

hashCode()

toString()

componentN()

copy()

Creating new a new christmas tree object is done like this:

Using and accessing the values is done like this:

The toString-method prints the values like this:

Summary

Kotlin data classes gives us less and more concise code, and with this more maintainable applications.

It’s in the small things

A quick and easy guide to creating components that control their own state, if you want them to.

React is a pretty neat piece of technology. Its component-centric design lets us create reusable pieces of code - pieces that can be used over and over again in new contexts with new demands to its flexibility. When you have something this flexible, though, you need to put a lot of thought into how you design its interface. If your component has internal state, should it ever be overridable? Should you be able to set defaults? Control it for a bit, and then let it control itself?

An example: the humble expandable panel

I'm currently implementing a design system for our client, and I was tasked with creating an expandable component. The initial implementation looked something like this:

Now this works fine for our initial usecase. It lets us toggle the visibility of our content in an accessible way. However, somebody soon comes along and asks us for the ability to control the visibility programmatically.

Let's take you through how you can implement this functionality once, and through the magic of hooks, never have to think of it ever again.

First, let's introduce two new props - isOpen and onToggle, and make it completely controlled from the outside:

This is flexible, but a pain for when you don't need the flexibility. Instead, let's control the state if the consumer doesn't provide it for us.

Woah, that was a lot! We're keeping track of the state internally, updating it if it changes externally, and calling the correct updater function if available.

But even if this looks pretty ugly - especially when you sprinkle this into an already complex component - it works!

Luckily, React lets us refactor this kind of reusable logic into what's known as custom hooks. Let's create a new hook useControllableProp and pull out some of this complexity:

We've renamed the code to be a bit more general, and made the internal updater function require an argument, but that's it. Our expandable panel code now looks like this:

The beauty of this hook is that it can be reused across your codebase whenever you need something to be controllable sometimes. Here's a text field with the same logic applied:

It's a hook that has served our needs well, and that we hope will help you out as well.

Other ways to achieve the same

There are, of course, other ways to solve this particular problem. One of the most powerful ones is called the state reducer pattern, popularised by the one and only Kent C. Dodds.

Control your components

Every team has to make various decisions before, and during, the development of a digital product. One of these usually involves yarn, npm or another tool to build and package javascript code. Some developers have a burning desire to go in a certain direction, and sometimes they end up spending a considerable amount of time trying to make decisions that in fact will have little impact in their everyday life.

To understand why this is an interesting decision to make in the first place, we need to have a look at the history of package management in javascript.

Pre npm: frontend dependencies are downloaded manually and stored into the repositories 📁

2010: npm is released and supports nodejs 📦

2012: npm usage is dramatically increasing - primarily due to Browserifys browser support 🎉

2012: npm get a competitor, bower, that entirely supports browsers 💻

2012-2016: The number of dependencies for frontend projects increases exponentially 🤯

2012-2016: Building and installing frontend applications becomes slower and slower 🐢

2012-2016: An infinite amount of (duplicated) dependencies are stored in nested folders within the magic node_modules ☢️

2012-2016: rm -rf node_modules the most frequently used command as a frontend developer..? 🗑

2015: bower lose the battle against npm 💀

2015: node_modules are changed to a (more) flatten file structure! 🕸

2016: left-pad becomes the worldwide news of the day 👈

2016: yarn is released 🚀

Supports both npm and bower repositories

yarn.lock locks installed versions and provide deterministic dependencies. No more rm -rf node_modules!

yarn install spend about half the time versus npm install (without using cache)

Caching and offline mode enables build processes to consume nearly no time

2016: npm releases shrinkwrap 🧯

An attempt to handle dependency locking

Unfortunately, several errors and promising more than it could manage - the reputation of the tool became poor

2017: npm 5 is released 🔓

package-lock.json is their new tool, shrinkwrap is put aside

package-lock.json take on the fight against yarns lock file

2018: npm ci is released 🛬

Build code using package-lock.json directly

No expensive security and version analyses on the dependencies

Build time is drastically reduced on the build server!

2018: npm 6 is released 👮‍♀️

npm check security vulnerabilities for dependencies to be installed

No significant variance in build time between yarn and npm

2019: tink is in beta mode 🦋

Avoid using node_modules and rather have one file with hashes for each dependency in the project

Not yet production-ready

...

Phew 🥵

As we can see, after the release of yarn, npm has been inspired (and forced?) to develop lots of good tools and mechanisms. yarn should get credit for addressing some important problems related to npm and put pressure on their competitor back in 2016. Both speed, security and deterministic package handling are essential features that allow today's developers to focus and concentrate on creating value - and not fighting the tool.

Conclusion 🤔

For convenience, I would recommend most teams (who have to make numerous other and more important technologically decisions) to choose the easiest option - npm. It is shipped with node and is, in 2019, sufficient enough to handle package management in a good manner.

Always an exception? 🧐

When using monorepo, yarn workspaces is a popular alternative whereas npm doesn't offer an equivalent alternative. lerna is a package that also supports usage of monorepos and works with both npm and yarn (with workspaces)

pnpm 🥉

PS: It should be mentioned that pnpm is the third option for package management. pnpm's selling point is not downloading a package if it is already downloaded in another repository - which is similar to dependency management in Java, maven. At the time of writing, pnpm is not as mature and production-ready as yarn or npm

Should you choose npm or yarn?

As a developer I spend most of my time at work in my IDE, for me that IDE is IntelliJ IDEA. During these years I have learned a few tricks, some useful keyboard-shortcuts and found a few plugins that have helped me be more effective in my day-to-day work. I want to share these lessons with you in the form of 4 IntelliJ ninja tricks!

First and foremost, learning some keyboard shortcuts will yield great awards. And the good thing in IntelliJ is that to start off you only need one: CMD + SHIFT + A (find actions)*. This keyboard shortcut of shortcuts gives you access to all possible actions within IntelliJ, and their corresponding keyboard shortcut!

The second thing I love to use in IntelliJ is Scratch files (CTRL + SHIFT + N) . I use these as temporary notes or, after choosing a fitting extension, as a quick way to prettify the json or xml structure I want to look at. These files will not be saved as part of your project, and will disappear as you close them. This way you do not have to worry that they end up in your git-repository by mistake.

My third ninja-trick is concerned with debugging. If you have to test a branch of your code, and want a specific method to return a certain value you can set a breakpoint and use an action called Force return. Using the find actions from my first tip, this is easy to find. Great for those nutty corner cases!

Lastly I want to recommend some great plugins that exists in the marketplace:

Presentation Assistant: Every shortcut you use is shown in a green line at the bottom of the screen - great for pair programming and learning each other new shortcuts!

Key Promoter X: Helps you to learn keyboard shortcuts for all the things you are using your mouse to do. It tracks what you use keyboard shortcuts to do and what you are missing out on.

SonarLint: If you use sonar in your ecosystem, this plugin is perfect in order to get instant feedback while you program instead of getting these buildtime at your build server

EsLint: If you are running EsLint this is great to get early feedback on linting errors on your code.

These are my four ninja tricks to get the most out of IntelliJ - what are yours?

* Keep in mind that the default keyboard shortcuts may vary from Mac, Linux and Windows. Check them out in the Keymap reference in IntelliJ (Also easily available in find actions) or online here: https://www.jetbrains.com/help/idea/mastering-keyboard-shortcuts.html

IntelliJ Ninja Tricks

In this blog post, we will share some experiences on how we got to use functional languages in production. We will also provide some tips on how to convince others that functional programming (FP) is the way to go. No functional language, or any other tool for that matter, can be regarded as a silver bullet for every problem, so it is important to consider carefully what will be the right tool for the job.

Personally, I have been involved twice with introducing a functional programming language to my customer. First time, the original technology stack could not handle the complexity of our customer's expectations. The second time was also due to some challenges with the existing technology and we experienced that we used a disproportionately long time to change things that should be easily done. This led to a longer process where we could figure what suit us best. In this case we were able to use enough time to slowly learn both what would be the better way to go and also the technology itself.

Step 1: Scala

The first time more in detail, we had stuck in a dead end with the standard J2EE stack back in 2011. There were not too many attractive Javascript (JS) frameworks at the time and we found it challenging to develop frontend in JSF and pure JS. On the team, we had two developers who had Scala experiences, and they were also familiar with a web framework that could help us solve many of our problems. Everyone agreed that the development was to slowly and something had to be done. Based on the current situation and a team of developers which were trusted advisors in the organization it was decided to move away from the standard J2EE stack. This allowed us to work full time with Scala. In the very beginning some of the developers, myself included, were somewhat skeptical of departing from the common and trusted syntax we were used to in Java. This soon proved to be needless worries. Scala gave us the tools we needed, and we quickly became productive in our new language.

Share your ideas

In this case, we had a specific problem which we did not see how to get out of without replacing some of the frameworks. In turn, this also led to the use of a functional language. Of course, we cannot go around hoping to end up in such big trouble that the only way out is to replace the whole tech stack, but nevertheless there are plenty of challenges facing which might be solved in a better manner if we take the time to step back. Often the team needs an experienced trusted advisor to convince the business side that such changes are needed. The same trusted advisor might also be biased by earlier discussions and by how things are as is. Therefore I think it is important that trusted advisors also are able to see the possible changes that might have been thought of as unreachable. Since this is not always the truth less experienced developers are often the ones who come up with the ideas for change. Regardless of who suggested the change it is important that the team has an open arena where ideas like this can be shared and discussed. It is important that every team member feel the trust in the team so no one hesitates to share their ideas. After discussing with the team there has to be an agreement before it is advisable to approach the business side. Sharing knowledge within the team will lead to better ownership and it will be crucial for the viability of the new technology. It is not necessary that everyone in the team knows the language fully, but it is important that everyone in the team is comfortable with the change and that there are enough developers in the team to rely on for those with less experience.

Step 2: Elm

My second experience introducing FP was in early 2017 and now we actually saw that the framework we introduced in 2011 did not provide the flexibility we needed. One of the main problems was the lack of separation between frontend and backend in our code. We decided that we had to move away from this framework and find a better way of writing frontend and backend more decoupled. But! The first good news is that we have no intention of walk away from Scala. Scala works perfectly well for us as a backend language, although we first got to use it due to introducing a web framework in 2011. As opposed to the first time we had a thorough review within the team and had a broad consensus that we wanted a new frontend technology. The team had Scala.js foremost among the options until we got a better understanding of what Elm could give us. It became clear to everyone that here they got something more stable than what we had previously seen among "languages" that compile to JS. What also became the nail in the coffin for the positive vibe around Scala.js was that no one else in Bekk uses this framework. Therefore, it would be more difficult for the team to seek help locally. We had already experienced this situation, as the framework we wanted to remove had the same lack of use within Bekk and not widely used elsewhere either.

Start small, learn fast

Although the main reason for introducing new frontend technology was a legacy application, we did not start introducing Elm here. We started with some smaller new applications to learn as much as possible so that we had more experience when meeting the larger and more complex challenges. This is also a good way to lower the risk when introducing new technology. Since spring 2017 we have arranged three summer internships with several students participating each summer. Elm has been involved every year and we have been equally amazed every year how quickly new developers learn to use Elm. This also negates the concern that new developers are unable to adapt to new languages.

Step 3: Profit(?)

So, do you want to introduce a functional language in your project? Well, introducing just another language will in most cases not fix your problems by itself. What you might need is another library or framework. If you want to convince someone in your team, or even the business side, that functional programming is the way to go, you might not want to sell them the language directly, but find a framework that suits the problem and that accidentally happen to be written for a functional language. On that way you definetly have to fight some battles. Remember to also fight the ones you have lost before! And for the third time: Syntax does not define the difficulty in our field. Developers do know how to adopt new languages!

Introduce functional languages to your production stack

If you have paid some attention to the artificial intelligence community the latest years, you’re bound to have heard of neural networks. These kinds of computational algorithms have pushed the boundaries of machine learning in pretty much every sub field there is. But what are they really?

Neural networks are computer algorithms that are loosely modelled after the human brain. Our brain can do what it can because of interconnected neurons. Simply put, neurons are entities that receive information through a set of synapses, perform some sort of calculation, and pass the result to other neurons through its outgoing synapses.

Artificial Neural Networks are computational algorithms that try to mimic this behaviour. As neurons are fundamental in our brain, artificial neurons are central in artificial neural networks. They work the same way; each neuron receives a set of input signals, combines them in some way, and passes the information along. The real power of artificial neural networks emerges when you connect layers of neurons together to form a network.

Traditional artificial neural networks are structured in layers. Each neuron combines its input signals and passes it along to the neurons in the next layer. The output of the last layer is the output of the network. The shape and form of the output depends on what you want the network to do. If you want it to recognize cats - a simple digit, signifying a cat or not, would suffice.

These neural networks are trained to do specific tasks. If we want our network to tell whether an image depicts a cat or a dog, we have to train it to do so. This is done by first feeding an image of a cat or a dog to the network. The network then does its internal computations, before an output is produced. This output is compared with the truth. If the network thinks it was given a picture of a dog when in reality the picture was of a cat, it will alter the behaviour of its neurons slightly in order to make a better prediction of a cat in the future. The network uses an algorithm called gradient descent to modify the behavior of its neurons. The specifics of gradient descent is beyond the scope of this article, but I'll include a link below if you want to learn more.

In order to reach near-human performance, the network needs to be presented with a lot of labelled pictures of cats and dogs. Each time the network makes a wrong prediction, the neurons are modified slightly. After a lot of modifications, the neurons are able to work together to identify whether or not the given image is of a cat or dog.

These networks can be used for much more complicated tasks than differentiating between cats and dogs. Artificial Neural Networks have pushed the boundaries of pretty much every sub-field within machine learning, from self-driven cars, voice assistants, automatic video-game playing, content recommendation - perhaps this article was recommended to you based on predictions from a neural network.

I hope this gave you a quick introduction to neural networks. By itself, each neuron is not very complicated. But stacking them together really proves how the whole can be greater than the sum of its parts. If you want to delve further into the world of artificial neural networks along with practical knowledge of how to implement them, I recommend this Coursera course by Andrew Ng.

Thank your for reading, and merry Christmas!

Neural Networks

Grid layouts are nice until you need to do something slightly outside of its bounds. Want to learn a quick trick to escape?

I'm a huge fan of grid layouts. As a developer, I love how easy they make it to achieve good vertical rhythm, a clean element flow and a consistent design across widely different layouts. It is - in other words - the bees knees.

There are tons of great CSS grid implementations out there, but the simplest one is probably the one built in to CSS itself - the display: grid;:

If you hold back a bit on the grid features you use, you can even make it look pretty in Internet Explorer 11!

However, even CSS's grid feature lacks the option of "bleeding" a grid column out into its gutter. It's a design I've had to implement a ton of times - and it always ends up breaking my grid implementation. Or, well, it used to.

What's a bleeding edge?

In the printing industry, bleed refers to printing outside of the area that's being kept after trimming. When you print stuff this way, it lets you print to the very edge of what's being produced.

On the web, I refer to bleed as the area outside of a grid cell. Here's an example on how it can look:

How can I start bleeding too?

Good question! First, donate blood to your local blood bank. Then, dip into the world of box shadows.

Box shadows is this blurring shadow effect that's often used to create the illusion of depth. It often looks like this:

Box shadows are rendered outside of the regular layout flow, and doesn't affect its surrounding elements. This is a powerful property, that when used right, can help us achieve our bleed effect!

First, let's create a basic grid with 5 columns:

Second, let's scaffold up some HTML to apply this CSS to:

Here's a row of 5 one-column columns, and one three-column column below them. It looks like this:

Now, let's apply our bleed effect. Let's start by creating a new modifier class .grid-item--bleed:

Whoa, what happened here? We're specifying two box-shadows - one offset 1rem (equal to the column gap) to the left, and one offset 1rem to the right. This gives the effect of our container "bleeding out" into its margins, all while keeping the content happily aligned inside.

As a final touch - let's use some CSS custom properties to clean up our code:

It's a bit more wordy - sure - but now everything will be in sync even if you feel like changing parts of your design.

Here's a code pen with the code above for you to play around in.

Thanks for reading, and I hope this helps!

10-Dec

Today's posts