Have you ever wondered what the amazing Christmas dinner and the Event Loop in JavaScript have in common? Well, not much. But I will use the preparation of this delicious meal to make the event loop a bit more edible.

The Light Bearer

But before we continue, today is St. Lucia Day! St. Lucia Day is a big deal here in Norway. On this day we walk around the corridors with lights on our heads and hand out St. Lucia Day Buns! Google how to make them, and enjoy. St. Lucia is the bearer of light, who makes the dark winter disappear and brings joy, light and a common ground. Just like JavaScript did for browsers. Ok, that was a cheap shot, I promise it’ll be the only one, please keep reading.

The dinner component

The star of the Christmas dinner, for many Norwegian families, is the Christmas Ribbe (pork belly). But you can’t shine like a star if you’re not accompanied by other great participants. For example the sausage, or the potato. With this trio, you can’t go too wrong with the dinner, so we are going to keep them in this saga. Now we have all the elements to learn about the event loop.

My plate is full

First thing first, JavaScript is single-threaded. Which means it can only run one task at a time. Most of the time this is totally fine, but if the task takes more than a second, let's say one minute... then we have a problem, since JavaScript then waits for the response before it continues with the rest of the tasks. If you’re new to JavaScript you might not see the problem with this. However, as a consumer of the internet you’ve probably been frustrated by a frozen browser, that may have been caused by this problem. Because when JavaScript is frozen, then the UI is frozen, and we do not want that ❌.

As a thought experiment, let’s say we are single threaded as well. Therefore, when we read the recipe for the ChristmasDinner, we read the recipe from top to bottom, executing tasks as we go.

On this Christmas dinner recipe, the preparation and cooking of the ribbe is first on the list. So we start there, with the first task, seasoning. This should be done 3 days beforehand, and then the ribbe shall cook for 4 hours on Christmas Eve. If we could only execute one task at the time then all the other cooking, sausages or potatoes, would have to wait until the ribbe is done. By that logic, good luck impressing your family with an elegant delicious dinner. And just imagine if ribbe was the last task on the recipe, then your family would eat ribbe 3 days after the rest of the dinner 😱 Luckily, we’re not single threaded, the same goes for JavaScript... in some way. The reason I can make such a bold statement is because the browser gives us some handy features we can use when executing our code, Web API.

Before we dive into the Web API we have to establish that the JS engine uses a call stack for all tasks it has to execute. Since it’s a stack, it’s first in, last out. Just like a stack of plates. Let's dive in. The Web API includes the DOM API, setTimeout and HTTP request, among others. The stack won't take the task out of the stack before it returns a value. This is where the setTimeout, for example, comes in handy. By wrapping the function in a setTimeout the call stack sends the function to the Web API. Then the Web API holds on to the callback until the timer is done, before returning the function. Hence, the JS engine doesn't freeze.

The oven event

So, now we know that JavaScript can handle multiple events by using the features provided by the Web API. For simplicity we will only focus on the cooking, and then we can think of the oven as the Web API. We’re prepping the ribbe, using all our capacity on the seasoning. When the seasoning is done we’ll put the ribbe in the oven letting it cook for 4 hours. This action cookRibbe will invoke the setTimeout function, illustrated by the oven letting us know the ribbe is done.

When the ribbe is done, we can push the callback back on the call stack for execution. Although it sounds simple, this is where it gets a tad more complicated. The Web API is not allowed to push the callback straight back on the call stack. Why? Remember when we talked about JS being single threaded? Yeah... it’s still a thing. Therefore the Web API pushes the callback onto the queue.

And this is where the event loop enters the saga. The event loop has one job, pushing callbacks from the queue onto the call stack. If the call stack is empty, the event loop pushes the callback straight onto the stack. There you go, pretty easy right?



The plot twist

Sadly, it’s always a twist. Most likely you are busy mashing potatoes, and are not able to take the ribbe out of the oven right away when it’s done 😬. The ribbe will then sit in the oven until your hands are free and you can take it out. And if you already have the queue stacked up with stuffing sausage or setting the table, the callback will be pushed to the back of the queue. There it might wait, in this example, for hours. In the browser, for minutes.

When the stack is cleared and the queue is empty, then the task can be executed. Hopefully the ribbe did not have to wait for hours in the oven and you’ll be the family hero. But if the queue is full, the ribbe will be burned. Let’s just hope JustEat delivers on Christmas Eve.

That’s it. This is why you as a developer may be a bit frustrated. Even though you set a timeout it might not be executed when you intended. And now you know why.

The delicious Event Loop

Social media applications spy on you, and probably send home some data about you every second you use the app. But what about the applications that have another business model? Do you trust that your bus pass app, developed by your the municipality, or your smart vacuum cleaner is not sending your data back to the developers? Often, we have no idea, and until recently iOS-users had no good way of inspecting the traffic that was sent from their devices.

The problem with owning an iOS-devices is that the information going between the device and a server has been difficult to inspect. Prior to me discovering Charles, I had no good ways of checking what and how often data was transmitted from an app. Previous rigs for inspecting the traffic included doing MiTM-attacks from my router, and still then it was hard to inspect HTTPS traffic. Just watch how tedious this guide from Fiddler is. Another option for inspecting the traffic was to jailbreak the device. From a security standpoint you should not jailbreak or root your device, as SANS and NorSIS states. While jailbreaking the phone exposes you to a new world of cool applications and tweaks, the security problems that follow are not worth it in my opinion. Most Norwegian banks and public services will not allow the use of their apps if they detect you are using a jailbroken device, so you will in most cases lose functionality by jailbreaking.

There is a better way!

Charles should be a familiar name when we talk about packet analyzers and proxy tools for debugging. What you might not know is that Charles also has a client for iOS. Proxyman as well as some smaller apps like Stream and Thor HTTP Sniffer have also been allowed in on the AppStore.

How to get started spying on your applications.

Force close the app you want to spy on.

First time you open the Charles Proxy App, you will be prompted for permission to install VPN Configurations, press “allow”.

The app will start the proxy and should show that it is active.

Tap the gear icon in the top left. Then tap “SSL Proxying”.

At the bottom of the screen you will find instruction for installing and trusting the Charles Proxy CA Certificate. Follow the instructions, install the Certificate and make sure that the Certificate Status shows “Trusted” when you come back in the Charles Proxy app.

Now toggle the “Enabled” switch in the SSL Proxying screen to "On" and go back (close the settings menu) to the main screen of the app.

Open the app you want to spy on, and let it load completely.

Switch back to the Charles Proxy app and tap on the Current Session.

You should see a lot of requests, pick the endpoint you want to inspect, and tap on it.

Tap “Enable SSL Proxying”.

Go back to the main screen of Charles and clear the Current Session by swiping to the left and tap “Clear”.

Force close the app you are spying on and open it again. Let it fully load.

Go back to Charles Proxy and tap on the new Current Session.

Look for the endpoint from step 9, and tap it.

You can now see the request and response body for all paths.

Some considerations when using this.

Many applications use multiple endpoints, and send your data all over the place, so finding the correct endpoint may be tricky.

You will find endpoints and access-tokens for many applications where developers thought that information was private because it is obfuscated/hidden. Use it with care, as some restrictions may apply. Some companies state that you need explicit consent for using their API’s even though they provide no security.

Spy back on the apps spying on you

Elm doesn't have nulls or undefineds, it has a Maybe type. While it's a pleasent type to work with, it might take some getting used to if you're coming from a language like Java or Python. Let's take a look at how we perform some basic operations over the Maybe type.

Imagine we're creating a game and we're adding a feature that will display the player's high score at the end of a run. When the game is run for the first time, there will be no high score recorded. It seems reasonable to use Maybe Int to represent a high score.

To display this on screen, we'll first have to convert the value to a String and then wrap it within an Html element:

This works, but can be improved. By making use of two functions known as Maybe.map and Maybe.withDefault we can get rid of the pattern matching, and thereby increasing the signal-to-noise ratio of the code.

Maybe.map works by applying a function to a Maybe if, and only if, it contains a value. If the Maybe is Nothing, then the result of Maybe.map is also Nothing. So if you want to convert a Maybe Int to a Maybe String you can do this:

So far, so good. We can use this to re-write our original function:

This might not seem much better than what we started with. Some of you might even consider this to be worse. The good news is that we can make use of another function to get rid of the pattern match all together, which is Maybe.withDefault.

Maybe.withDefault takes in a concrete value and a Maybe. If the Maybe type contains a value, that value is returned. If, however, the Maybe is Nothing, then the concrete value will be returned.

By using Maybe.map in combination with Maybe.withDefault and some pipe operators, we can simplify our original function further:

Compare this to our original attempt. What have we gained?

I'd argue that it's more clear what this function does now. You can see at the bottom line of the function that no matter what happens in the lines above, we're going to return a value wrapped in Html.text.

It's also clear that if we have a high score, we're going to convert it to a String and if we don't have a high score we'll simply return the empty String. You can of course see this in our first attempt too, but only after you've mentally parsed each branch of the case-expression.

This was just a simple example. More complex uses of Maybe will benefit more from use of Maybe.map and Maybe.andThen.

In summary

Pattern matching on Maybe is powerful and flexible, but might not result in code that is easy to understand. Making use of specialised functions and piping them together can lead to less code that is also more intuitive.

What do we do with what's inside the box?

For the last decade I've called Oslo my home. And aside from the usual goals of getting an education, landing a job and living my life, I've had a side quest: Finding the best places for hot chocolate in town.

Now before I go any further, I want to make it absolutely clear that this post is not sponsored by anyone. It's simply the culmination of my love for hot chocolate. And programming.

My criteria for good hot chocolate:

Must have the right consistency and creaminess, not too watery

Must not be too sweet

Any toppings is simply a bonus, but will not make my list by itself. It's all about that base.

I must like it

But before I present my top three list, let's make the React Leaflet map.

Setup

This will be a React project written in TypeScript, requiring Node version 10 or up and NPM version 5.2.0 or higher (since we’ll be using npx). I'll be using create-react-app to set up our barebones React app, and will add the flag --template typescript to make it Typescript-based:

npx create-react-app hot-chocolate-map --template typescript

We'll also need some NPM packages, so navigate into our newly created application folder and add them:

cd hot-chocolate-map && npm install leaflet react-leaflet @types/react @types/leaflet --save

My personal preference is to make some additional folders in our project structure. A components folder for our React components and a domain folder for any custom TypeScript types. Did you know you can make multiple new folders by typing in multiple folder names to mkdir?

mkdir src/components src/domain

Run the application with npm run start and let's begin programming! The barebones React app should open in a new browser window.

The map basics

We'll start by making our map component FavoritesMap.tsx inside the components folder. I'll add the basic setup for our React Leaflet map here, as well as the imports we’ll need later.

Let's also simplify App.tsx, our app's starting point, and include our FavoritesMap component:

Now we get to the part that always trips me up. Always. Because in theory, this should be everything required to make a basic map, right? Wrong. The Leaflet map needs a set height in order to display correctly. So let's append that to App.css:

Huzzah! We have an empty map!

The hot chocolate favorites

Let's have a look at my list of favorite hot chocolate places, how to describe them as a TypeScript type and add them as markers on our map. These are all product names in Norwegian, with an English translation in parentheses.

🥇Varm belgisk sjokolade (Belgian hot chocolate) at Steam kaffebar

🥈Varm sjokolade (Hot chocolate) at Kaffebrenneriet

🥉Sjokolade på pinne (Hot chocolate on a stick) at Espresso House

Both Kaffebrenneriet and Espresso House have multiple coffee shops in Oslo. I've added ones close to Steam kaffebar for convenience. Please note, given the current situation I haven't visited these shops recently. Some menus may have changed.

Onto the TypeScript type. Per item we have a product name in Norwegian, a product name in English, a vendor, a location and (since we'll display it on a map) latitude and longitude. Let's also add a description and make it an optional field.

Create a new file domain.ts inside our domain folder and add the following HotChocolate type definition:

Import the type HotChocolate in our FavoritesMap component.

import { HotChocolate } from "../domain/domain";

Now we can add our hard coded list to FavoritesMap:

Loop through these HotChocolate items and make markers. Replace the marker placeholder in the MapContainer with the finished marker list.

For extra holiday coziness, "koselig" as we say in Norwegian, I've added a custom marker icon to the markers we just made:

And the CSS for the icon in App.css:

And then we're done. Let's look at our finished map.

End notes

In the spirit of keeping it simple I’ve taken some shortcuts here. For instance, in a real world application one might need the favorites list for more than just displaying it on a map. Defining it in App.tsx would make more sense and passing it into components as needed with props or hooks. And the different TypeScript @types dependencies would also normally be added as developer dependencies.

Thank you for following along, I hope you enjoyed this seasonally appropriate map. Happy holidays! ☕

A Hot Chocolate Map with React Leaflet and TypeScript

The container paradigm is upon us, and some love hacking and writing code for Kubernetes - while others struggle, finding maintaining or releasing for it difficult. How do you even test a Kubernetes deployment on your own computer anyway? In this post we will have a look at how the stripped-down Kubernetes variant K3s can be used to take the new hot container continuous delivery tool Argo CD for a spin on your own laptop or personal server - without much of the complexity Kubernetes requires.

Kubernetes: oh so wonderfull, but oh so complex

Ah, Kubernetes. In the fast-paced realm of cloud computing, it seams a long time ago that Kubernetes, or K8s for short, came winning out of the container orchestrator wars. With the amount of hype it's had and it's seeming omnipresent, it's hard to belive that it's just been 3 years since K8s came out on top as the preferred container orchestrator, leaving other products like Docker Swarm and Mesosphere in it's wake.

The container paradigm hasn't been just smooth sailing. Many adopters have struggled with all the loose parts, and K8s has suffered lots of critique for it's complexity. Lots of this criticism can be dedicated to projects too small to be using it in the first place, surfing on the hype of "all the big players using K8s so we should too", but there is certainly a case to be made for the effort and knowledge going in to managing a cluster. On top of that, doing local development has been a bit clunky, and for some teams, managing clusters for things like CI can be expensive.

Thankfully, there is a solution for those who want to leverage the strengths of deploying applications and services declaratively with Kubernetes, but without big parts of the complexity: K3s. That's right, it's K8s - 5 = K3s.

K3s and k3d

K3s is developed by Rancher Labs and is a Kubernetes flavor built to bring the power of Kubernetes to the edge, IoT devices, local development or for usage in situations where, quote,

"Situations where a PhD in K8s clusterology is infeasible".

What does this mean? In practice, K3s is a "full" Kubernetes-compatible system with a single binary under 40Mb in size. Lots of deprecated or optional parts of K8s has been removed to shrink it down, but the biggest differences is the replacement of etcd, the distributed key-value database, in favor of the versatile SQLite database, a favorite among many developers for mobile and embedded solutions. For high availability clusters, SQLite can optionally be swapped for another database, like MySql or PostgreSQL.

Since K3s is designed to be simple and easy to install, it can also be run via Docker (fancy that, a container orchestrator tool that run in a container itself!). This project is, logically enough, called k3d. k3d makes it quite simple to create single- and multi-node K3s clusters locally, on a VM, as a part of CI systems, etc.

To summarize, K3s and K3d removes a lot of the friction and complexity associated with running Kubernetes, making it a good choice for local Kubernetes development, edge computing devices or your local server. Sounds exiting? Let's use K3s via k3d to deploy apps with another hot product: The container continuous delivery tool Argo CD.

Continuous Delivery with Argo CD

Argo CD is a GitOps tool that has a simple, but powerful objective: To declaratively deploy applications to Kubernetes by reading the application's Kubernetes-resources from version control, like a Git repository. Every commit to the repository is threated as a change that will be executed by Argo CD against the Kubernetes cluster, manually or automatic. In this way the entire deployment regime is controlled by files in version control, which substantiates an explicit release process. As an example, if a new version of the application is to be released, an update to the image tag is written to the resource files and checked in. Argo CD syncs with the repository and rolls out the new version.

Since Argo CD itself runs on Kubernetes, it's quite easy to setup and works perfectly to deploy applications on K3s.

Setup Time

To test Argo CD with K3s on macOS, the easiest way is to run a single-node cluster via Docker and k3d. First, install `k3d` with Homebrew:

With the k3d command, in place, set up a single-node cluster called laptop:

A quick docker ps shows two containers, k3s itself and a proxy. That's all we need.

Next up, use the k3d command to add the new cluster to the local kubeconfig so we can interact with it:

Now using kubctl to check available nodes should list information about the available K3s installation.

Now, to begin the installation of Argo CD, create a namespace for it:

The rest of the installation is a simple kubctl apply from the Argo CD installation manifest. A lot of Kubernetes resources will be set up, so this might take some time.

After a minute or two depending on the speed of your machine, all Argo pods should be in place.

To access the Argo CD UI, create a port-forwarding object and attach it to the Argo CD service (We want this port forward hanging, so use a dedicated terminal window).

Navigate a browser to https://localhost:8080 to find the Argo CD login screen.

To login, use username admin. The first-time password is the name of the Argo CD Api Server pod, funny enough. That can be fetched like this:

With the password in hand, Argo CD will let you in.

From here, hook up a new Application with the following details:

KeyValueApplication nameguestbookProjectdefaultSync PolicyAutomaticRepository URLhttps://github.com/andmos/argocd-example-appsTARGET REVISIONHEADPATHguestbookCluster URLhttps://kubernetes.default.svcNamespaceargocd

And hit create. This will start the deployment of a simple guestbook application with a service, endpoint and a deployment containing a single replica set. Everything is synced by Argo CD from the given Github repository. When everything is created, Argo CD will show a all-green, all synced up map of all Kubernetes objects.

To access the deployed guestbook, set up a new port forward for the guestbook-service:

Hit up http://localhost:8081 to see it.

And thats it! We now have a glorified guestbook application deployed from Argo CD to Kubernetes, running as K3s via k3d on a local machine. Hopefully this spars some ideas on how to use K3s / k3d, Argo CD or hopefully both.

Cleaning up

To clean up the machine and delete all content from the k3d cluster, use the delete command:

Post Script

When writing this article I went in total flux over whether to write "k3s", or "K3s" with a capital K. To find out, I reached out to the main author on Twitter, Darren Shepherd and asked him. The answer was quite amusing, I recommend reading the following Twitter-thread!

I'd like to know too. I always wanted it to be lowercase but when people edit my writing they make it upper case, especially when starting a sentence. So I really have no clue. @GuerillaNerd do you know?

— Darren Shepherd (@ibuildthecloud) December 8, 2020

Ah, and one more thing: For more, in-depth use of Argo CD, watch out for the 16th.

Take Argo CD for a spin with K3s and k3d

Have you ever tried to use the compare operations on two instances of your self-made data class in Kotlin just to realize it is not possible? By employing operator overloading, you are actually able to do so!

From Wikipedia:

Operators are constructs defined within programming languages which behave generally like functions, but differ syntactically or semantically.

The most common operators are the arithmetic operators +, -, / and %, and they are widely used in all sorts of programming languages. But these are only a few of all the operators defined in Kotlin (for an exhaustive list, take a look at the official documentation here). All operators have a fixed symbolic representation, such as + and -, and a function with a fixed name that specifies its functionality. You can see all the arithmetic operators with their corresponding functions in the table below.

When working with the basic types in Kotlin (such as Int, String, Boolean, etc.), all operators work in a sensible way. We can, for example, write 2 + 2 and Kotlin calculates the sum of 4. We are also able to compare strings with an equality operator, such as "myfantasticstring" == "myfantasticstring".

But what about the user-defined types? Let's say we have a simple date class defined as

What happens if we try to subtract two MyDate objects? We get an error because the operator function is not yet defined for this data class. Operator overloading comes to the rescue.

We can define the operator function for subtraction as an extension function:

That's all. Easy, right? Now we are able to calculate the number of days between two MyDate-objects just by subtracting them from another. The operator function can also be defined as a member function on the data class itself. Let us say we want to check whether a House is smaller or bigger compared to another House. We could implement it as follows:

These are just two basic examples of how you could use operator overloading in your application. You can define the operator function both as a member function and an extension function on a data class. Just remember to mark the overloading operator function with the operator modifier. Operator overloading might be a great solution to your problem, but be aware, comprehensive use could make your application both complex and confusing.

Operator Overloading

En liten julegave til dere fra oss i faggruppa Tegning, form og animasjon. Vi har på hvert vårt hjemmekontor visualisert noen fraser, uttrykk og ting dere har hørt i møter i år. God jul 🎅

Her er noen ord og uttrykk vi bruker i design- og utviklings-hverdagen. Klarer du å gjette hva tegningen betyr?

Ikke les videre hvis du ikke vil vite fasiten:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Hamburger-meny, 2. Dropdown, 3. Radioknapp, 4. Bug, 5. Sticky, 6. Musepeker

Ting du har hørt i møter i år

When making web applications most times you fetch stuff from some remote location, and usually with XHR. These operations are asynchronous and can fail for a myriad of reasons. Handling them well is important to make sure the users of your applications have a good time.

There have been written many blog posts detailing the issues with naive approaches and offering solutions.

http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

https://medium.com/javascript-inside/slaying-a-ui-antipattern-in-react-64a3b98242c

https://blogg.kantega.no/slaying_a_ui_antipattern_with_typescript_and_react/

The topic of this article will be a practical one. I have been using https://github.com/devexperts/remote-data-ts for some time now and find that it solves the problem for me in a nice way. The problem with this library is right there in the readme:

Docs & Examples Coming soon (check the source)

This is not really the best way to start your relationship with a new library. Usually I would have closed the tab right then and there, but up until that point the alternatives I'd found all had some parts that irked me. Some used strange naming conventions, some didn't have the utility functions needed to be usable, and some kept using any or other weak typing choices.

Do note that when I say "strange naming conventions" I mean naming conventions that differ from established FP-lingo. When I work with something that is a functor I expect it to have map, not doIfSuccess.

So I decided to read the source. It helped a bit. I found out that the examples in the readme just weren't correct. There is no foldL on any instance of RemoteData<E, A>. Kind of annoying.

I also found out that all functions for working with RemoteDatas are curried functions that take the RemoteData as their last argument. This feels good as it makes piping stuff nice. However, JavaScript/TypeScript does not have any built-in syntax to support piping (yet https://github.com/tc39/proposal-pipeline-operator). Ah well, let's get back to that later. Time to try using the library.

As with a regular Either type, this follows the convention of having the error type as the first type variable and the success type as the second one. Since we're explicitly creating a success-case we can safely use never as the "error type".

This should work, right? The success-type of data is a number so I should be fine passing my function that increments that number to map. But alas, it doesn't work! TypeScript complains that x in our callback is of type unknown.

Okay, let's try giving TypeScript some more to work with:

Ah, there we go. TypeScript is happy and it compiles and works.

Now, for a more realistic example we want to handle more cases, and for that we can use fold. fold takes four functions for handling (in order) the initial, pending, failure and success cases.

This all looks pretty nice, but it is kind of annoying to have to specify the types of the arguments to the failure and success callbacks. Sure, we could specify the types as type arguments like so: fold<string, number, string> but it still feels redundant. The information is there in the type of data after all! Surely there must be a better way to do this.

So, what to do? Luckily for me, I have a colleague who I knew had been using this library before. He pointed me in the direction of what was being hinted at in the first line in the README: "Heavily based on fp-ts lib." What it should have read was "This library is annoying to use without fp-ts. Please also install and use fp-ts, as this library on its own is like a car with square wheels. Sure, it might get you where you're going, but it won't be comfortable".

That colleague I mentioned also pointed me straight to the answer to my frustrations: https://gcanti.github.io/fp-ts/modules/function.ts.html#pipe. Remember I mentioned that having the data as the last argument tends to make "pipeline style programming" nice? Yeah, this was that I needed.

If you didn't read yesterday's article I recommend you read it, as it explains both fp-ts in general and how pipe works in particular.

Now, with this new superpower we can finally write our code without having redundant type information all over the place in addition to it looking way nicer:

A more complex version of our first example could also be written

And there you have it. This is how to nicely handle remote data in TypeScript. Now that you know how it's supposed to be used, reading the code over at https://github.com/devexperts/remote-data-ts/blob/master/src/remote-data.ts should give you a better feel for how you can use it in your application.

Handling asynchronous data in TypeScript

Hvis du låner en krone, og det er den første kronen som eksisterer. Hvor er den andre kronen du må ha for å betale renten på den første kronen?

Min samboer og jeg abonnerer på 2 aviser, Finansavisen og Klassekampen. I en annen situasjon hadde disse motsetningene gjerne vært oppskriften på opphetede diskusjoner om kapitalisme, grådighet og hva som er kjennetegnet til et bærekraftig samfunn. Men det er heldigvis ikke dette som preger de viktigste diskusjonene i hjemmet. På hver sin måte tilbyr begge avisene god journalistikk, men som oftest med vidt forskjellig perspektiv eller meninger. Mens Klassekampen tordner med overskrifter som «Skattefesten for eliten», hånler og harselerer Hegnar i sine meningsinnlegg om uvitenheten og enfoldigheten hos alle som tilsynelatende ikke deler hans syn om markedsøkonomi og fri konkurranse.

Det er ikke alltid lett å enes om hva det er som får verden til å gå rundt, eller hva det er som er bærekraftig. Men når diskusjonen blir innviklet og meningene sterke, syntes jeg ofte det enkleste er å først etablere en felles grunnleggende forståelse. Et enkelt og sant bilde som begge parter kan være enige om.

Til denne artikkelen, ønsker jeg derfor å dele en grunnleggende forståelse om penger – hvor de kommer fra, og hvorfor penger har kneblet oss til en levemåte der penger må brukes, penger må bytte hender, og penger aldri kan sove.

Penger vokser ikke på trær – eller?

Forestill deg en verden uten penger! For 500 år siden var Inkariket det mektigste samfunnet i Sør-Amerika, og dette uten noe som helst forhold til penger. På samme måte som kommunisme, var arbeidskraft verdienheten, og denne kunne både lånes bort (tjeneste for tjeneste) eller handles med (slaver).

I 1532 A.D. ankom Francisco Pizarro og hans conquistadors, «erobrere». De hadde reist fra Spania, inspirert av legenden om ELDORADO. Etter å ha nedkjempet inkaene, gjorde de en oppdagelse i Bolivia, «Cerro Rico», pengefjellet! Over de neste 250 årene under Spansk styre, ble 2 billioner unse med sølv hentet ut fra gruvene (ca 56,7 milliarder kilo). Sølv var for Inkaene, ikke noe mer enn skinnende metal: men dette skinnende metallet kunne en lage mynter av, med andre ord, en transportabel MAKT. Selve oppdagelsen hadde gjord det spanske imperiet søkk rike, men selv med alt dette sølvet, kunne det ikke stoppe den økonomiske og politiske nedgangen til det spanske imperiet.



The Ascent of Money - Niall Ferguson

Det spanjolene ikke forstod da, er at penger er bare verdt hva andre vil gi i bytte mot det.

Spanjolene hadde gravd opp så mye sølv til å finansiere sine erobringer, at metallet i seg selv opplevde et eksepsjonelt verdifall. Myntene gjorde ikke Spania rikere, men prisene dyrere – ettersom en økning i pengemengden jaget en uendret mengde av varer og tjenester.

Hvis du låner en krone, og det er den første kronen som eksisterer. Hvor er den andre kronen du må ha for å betale renten på den første kronen?

I dagens samfunn, er vi ganske fornøyd med sedler og mynter som penger, vi er til-og-med fornøyd med penger vi ikke kan ta på og som kun eksisterer i nettbanken, og i noen få tilfeller er vi også fornøyd med penger vi ikke engang forstår, så lenge en ikke mister passordet til den krypterte valutaen.

Men hvor kommer alle disse pengene fra? Banken? Sentralbanken?

Sentralbanken styrer ikke størrelsen på pengemengden. Pengene du låner av banken fantes ikke før du tok opp lånet. Før trodde man at bankene låner ut penger andre sparer, men bankinnskudd er bankenes gjeld og ikke en formuesgjenstand som kan lånes ut.

Men det er altså når banken gir et nytt lån, at penger skapes. Penger skapes i form av nye innskudd når bankene gir nye lån:

Når en låntaker får innvilget et lån, gir personen et gjeldsbrev til banken

Banken på sin side underskriver gjeldsbrevet i form av et innskudd i banken

Slik sett omgjør banken gjeldsbrevet fra låntaker til penger låntakeren kan handle med – og det er i dette øyeblikket nye penger er skapt! For når en bank innvilger et lån, godskriver den samtidig kundens konto tilsvarende lånebeløpet. Dermed er penger, i form av innskudd skapt.

For å forstå hvordan dette logisk kan fungere, kan man se tilbake til bankenes opprinnelse – da gull var penger:

Folk trengte et sted å oppbevare sitt gull, og gikk til gullsmeden som trygt kunne oppbevare det i hvelvet. Kunden fikk da en kvittering på verdien i form av sedler, og dette fungerte godt i handel. Gullsmedene begynte etterhvert å låne ut penger – ikke gullet, men disse kvitteringene. Dette gav ekstrainntekt ettersom gullsmeden kunne kreve renter.



Men gullsmedene begynte etterhvert å oppdage at kundene sjeldent kom tilbake for å kreve gullet tilbake, fordi alt kundene trengte var kvitteringene. Og for å tjene enda mer, kunne gullsmeden utstede flere kvitteringer enn det var gull i hvelvet. Gullsmeden kunne i tillegg kreve renter på disse. Renter på gull som ikke fantes. Så lenge lånene ble tilbakebetalt, var dette god butikk og ingen ville legge merke til det. Gullsmedene ble rike, og dette var starten på det moderne banksystemet vi kjenner i dag.



For når gullsmeden gjorde dette, da skapte gullsmeden penger. Men det gjorde også gullsmeden sårbar i tilfellet kundene som hadde gullet sitt i hvelvet krevde det tilbake. Og da praksisen ble oppdaget opplevde gullsmeder det vi i dag kaller for et "bank run", noe alle banker frykter.

Allikevel, så likte myndighetene hva denne kredittveksten hadde gjort for økonomien. Så i stedet for å forby praksisen, innførte de reguleringer, eller et minimum, på hvor mye reserver bankene måtte ha. Og de rike bankene klarte på sin side å overtale myndighetene til å opprette sentralbanken, som skulle forsyne bankene med likviditet, i form av gull, Dette i tilfelle et "bank run" skulle skje igjen.

Tilbake til det gjennomgående spørsmålet om hvor den andre kronen er?

Svaret er at du må låne en ny krone for å betale renten på den første kronen, og den andre kronen må du igjen betale renter på, som igjen krever et nytt lån, og slik fortsetter det inn i evigheten!

Man kan si at penger har kneblet oss til en levemåte der vi stadig må ta opp mer gjeld enn det vi nedbetaler. Men i dagens samfunn er diskusjonstemaet gjerne at det er alt for høye gjeldsnivåer. Og mange har gjerne et syn på at gjeld er noe man skylder, og iboende i vår norske folkeånd skal man vel helst ikke stå i gjeld til noen. Selv med rentenivåer tilnærmet lik null.

Sant nok som det er, så kommer det en dag hvor gjeld skal betales. Men hvis alle hadde gjort dette ville det ført til økonomisk depresjon. For hvis vi nedbetaler mer gjeld enn vi tar opp nye lån, er det ingen penger som skapes som vi kan bruke til å nedbetale eksisterende gjeld pluss rentene!

For å oppsummere, er det følgende grunnleggende forståelse å ta med seg videre:

Penger skapes av gjeld, og

Dagens system har bare en begrensning – den totale mengden gjeld

...men gjeld er heldigvis ubegrenset, derfor er også pengemengden ubegrenset, og den må konstant vokse. Men som vi lærte av spanjolene om hva som skjer når pengemengden vokser raskere enn mengden varer og tjenester vokser. Jo da stiger prisene og pengene blir mindre verdt, og det er dette som er balansekunsten; penger og forbruk.

"Money never sleeps" sa Michael Douglas sin tolkning av den griske finansmannen ´Gordon Gekko´ i filmen Wall Street fra 1987. Og rett som det er, penger er til for å brukes, penger må bytte hender, og penger kan-og må aldri sove – Det er stillstand som ikke er bærekraftig, noe det siste året har gitt oss en dyrekjøpt påminnelse om.

Hvorfor kan aldri penger sove?

Presentations can be a powerful tool for setting common goals and encouraging action, much in the same way a coach will create a better team.

GROW is a process or model often used when coaching as a way of setting goals or solve problems. The acronym consists of Goal, Reality, Options or Obstacles (or both) and Way forward.

Using this as a guideline when planning your presentation can help with conveying your message in a more structured way.

G is for Goal

Presentations are a means to an end, in that the presentation itself is rarely the goal. We communicate for a reason, be it to affect attitudes or encourage action. Stating your goal, or the shared goal, is key in making sure your audience is taking part on the same journey you are. It also helps you maintaining structure when planning the rest of the presentation.

Reality

Once you have your goal set and stated, we can move on to looking at the current situation. The aim is to create a common understanding of reality, its challenges and what works.

With goal and reality laid out, it becomes clear what the gap between the two are. How far away are we from reaching our goal?

Obstacles or Options, or both

Given what we know, what is preventing us from reaching said goal? While there are any number of obstacles preventing us from reaching our goal, we need only focus om the major ones. Think of obstacles as risks that should be mitigated. If you are having trouble weeding out the most important, it can be helpful to rank them based on impact and how manageable they are.

Wrapping up; the Way forward

We know where we want to go and now it is time convince the audience on how to get there.

There are a plethora of methods for creating structure to your presentations. Common for most of them is that they aim to help you create compelling arguments and clearly convey your message. The GROW-model is useful when highlighting a specific issue and you have suggestions for solutions.

GROW your presentations

Hvordan bidrar en inkubator til at nye selskaper lykkes? Har etablerte virksomheter som skal innovere behov for tilsvarende støtteapparat?

Jens Andreas Huseby prater med Bjarne Tvete, Partner og CEO i Aggrator - Inkubator Ås

13-Dec

Today's posts