Christmas is fast approaching, and with it, a new year. It’s time to leave bad security habits behind in 2020, set aside some time for a digital cleanup, and move forwards with a clean slate.

This doors format is that of a bingo card with different tasks and tips to consider which can increase your personal security. Below the board is a short explanation of that door, together with useful links to more information. Some of these points are probably well known to most of you, such as setting up a password manager, but maybe I can still give a few important pointers.

In 2019, I finished my Master Thesis on how to detect Identity theft in online banking. Working on this gave me insight into how people may commit identity theft, and how you can protect yourself against it. It is honestly quite shocking how some very simple steps can give a significant increase in your personal security.

This is one of those tips we always see, and with good reason—a password manager is essential to keep up with good password policies. Take a look at this blog post by H. K. Henriksen from 2018 to learn more about why you should have a password manager.

Many identity thefts happen between close relations. It might be a close family member or someone else that you have let into your home. Get control over where you have sensitive documents or code generators, and in so doing, limit who might have access to them.

Go through your old passwords and make them great (again). If you wonder about how to make the best possible passwords, we've got you covered.

The times we leave our mobile just laying about is honestly a bit scary when considering how much sensitive information we have on it. Adding password protection to your mobile should be a no-brainer. Make sure that you do not use the same pin on your lock screen and a banking service (e.g. Vipps or BankID on mobile). If you do that, you might accidentally let others log in to your bank. This is especially important for protecting yourself against familial identity theft.

What information can you find out about yourself online? Use this information to construct a social engineering attack that you might fall for. Knowing is half the battle; If you recognize possible attack vectors, then maybe you will think twice if you are ever the victim of such an attack.

What information did you manage to find about yourself? Take this opportunity to once and for all remove some of that information you know should not be there.

This brilliant service, created by security researcher Troy Hunt, can tell you if your email account is part of a known data breach. They also offer to notify you if your email is part of a future data breach.

Go through privacy settings on services that you use (e.g. Facebook, Google). Remove anything that you do not agree with. Maybe even get rid of the service altogether, if it’s too privacy-invasive.

Do you and your partner have a shared account for which only one person owns the account, and then simply share the login credentials? If so, you should stop reading this, and go create a proper shared account for which you can both log in using your respective user accounts. This is extremely important in case one of you ever were to misuse the shared account. At least in Norway, the registered owner of that account will be held accountable no matter who did the misdeed. Most banks should offer a simple way to create such a shared account.

This links back to nr 5. It can be bothersome to constantly having to re-enter a password on your phone. Adding a biometric access option can reduce this burden, as well as mitigate against shoulder surfing. Many people let their family members know their screen-lock password. Just remember that even if you do this, then you should at least never add their biometric information as a valid unlocking option. I’ve seen people add their partner’s biometric information on their phone, forgetting that that person now also might have access to other personal information on their phone, e.g. a password manager, or banking services.

Do you recognize all transactions in your bank statements? Even small, innocuous values can add up after time.

Look at app permissions on your phone. Remove what you can. Apps ask permission for the strangest thing. Sometimes, these permissions make sense to fulfill the app’s purpose, but in my experience, this is more the exception than the rule.

At least in Norway, it is possible to block others from making a credit check on you. Barring access to credit checks can prevent identity theft, such as someone taking up credit loans in your name. It is, of course, possible to remove this block later, in case you need to take up a mortgage. Datatilsynet describes how to do this.

Take some time to install software updates. Check both your PC, mobile, and other devices you may have.

Have a look at recent activity for your accounts. Do you recognize all listed units? Delete anything you do not recognize. If you become overeager, you can always renew the permission later. At least you are no longer logged into that loan mobile you used while your phone was in for reparations.

How do you feel about someone having access to anything on your phone or computer? If this makes you even the tiniest bit queasy, encrypt your devices. Luckily, many phones encrypt their data by default as long as you have added password protection. Take a few minutes to check how your devices handle encryption.

Are you vulnerable to privacy attacks and identity theft? 

Today's users tend to keep your web site open for ages. No, not because they love using it all the time, but because they opened it in a tab - most likely on their phone - and now it's there forever.

I log all errors in my web apps to Sentry, and every time I deploy a new version, I see a ton of these buggers cluttering my logs:

The what and why

First - let me explain what a chunk is, and why this happens.

A chunk is - well - a chunk of JavaScript. They are created whenever you code-split your application. I typically end up splitting my app up per route, so I get a single chunk per page in my app. Whenever the user navigates to that particular page (or before, if I preload it), the relevant chunk is requested from the server.

I deploy most of my web apps to Netlify (like this one), and whenever I deploy a new version, they wipe the old files and upload the new ones (well, they create a new deployment without any of the stuff from the previous deploy). So whenever the user continues using my site after a deployment (often days later), and goes to visit a new route, it can't find the requested chunk!

The fix

Now, there are several ways to mitigate this problem. You could deploy to an Amazon S3 bucket instead, and keep all old built files forever), you could pre-load all of the resources whenever a user visits the landing page, or you could use a CDN for hosting your stuff, which will cache your files.

I didn't want to do either of those though, because I'm lazy, and felt inspired. So I found a great workaround - already built into React Router! 🤯

The BrowserRouter component accepts a forceRefresh prop, which will turn all of those client-side links into regular ol' <a /> tags. This will make the app receive a new version of your web app from the server, alleviating all potential issues with stale JavaScript and missing chunks. In addition, the user gets your newly deployed version sooner than they would have otherwise.

So let's say you want to force your app to be updated at least once every 6 hours. How would you implement something like that? Turns out - it's pretty simple!

First, we create a new wrapper component for the BrowserRouter component - we'll call it AutoRefreshingRouter:

Next, we create a state variable shouldRefresh and pass it to the BrowserRouter's forceRefresh prop.

Finally, let's change that flag after an hour with a call to React's useEffect and a timeout!

Here, we ask the browser to wait 6 hours, and then set the shouldRefresh flag to true. We make sure to clear the timeout in the clean-up return value function if we ever re-mount the component.

And that's it! Since I deployed this fix, I haven't seen a single bug in production. My users are happier, and I don't get a bad feeling whenever I see Sentry telling me I screwed up.

Hope this helps you in your project as well. Thanks for reading!

How to force-refresh your app every once in a while

If you planned for doing a presentation or two in 2020, as with the vacation plans, it might not have gone quite as planned.

We have asked people in Bekk what their favourite tips and tricks are when presenting digitally. What new possibilities arises?

In this article, we summarize our main findings in 12 concrete tips. Enjoy!

Tip NO. 1 - Screen all the things

As you now present in your own, closed out and private area, you can really make use of all the screens you have available. It may be helpful to view your presentation on screen 1 and webcam on screen 2 (where you now also can have your speaker notes and attendee-list.

Tip NO. 2 - Finally, eye contact for everyone

Make sure that the screen or computer with the webcam recording is at level with your eyes, so you will look directly into the eyes of everyone in the other end. In the digital era, you can finally have eye contact with everyone. Yeah!

Tip NO. 3 - Consider unmuting in the audience

Disclaimer; this tip depends on both the presenter and the presenter style. For some, and in some occasions, it is beneficial to get some kind of feedback from the audience, at least from some of them. This is especially so if this is your first digital presentation. Just a "mhmmm", or similar acknowledgements in between your slides can help a lot in making sure that the audience still is there and are able to hear you speak.

Tip NO. 4 - Trust your technology 👊

If you don't like, from the previous tip, people making small "audience-like" sounds in your presentations, just try to remember that the technology most likely is working well, that everyone can hear you, and are able to see you and your slides.

Tip NO. 5 - Remember that technical difficulties can happen to everyone

Even the long-reigning Queen Elizabeth experienced difficulties on her video call, and so can you! Don't be sad if you experience it too, we've all been there.

Tip NO. 6 - Bring a friend

Everyone can see you in front of the camera. But. They can't really see what's going on behind the camera 😏 You might feel more at ease if you can have a family member, colleague, friend or loved ones in front of you while you speak.

Tip NO. 7 - Get comfy

You are (often) in your home when giving a digital Corona-presentation. Make sure to make good use of it! Take on your favourite slippers, enjoy your favourite cup of tea, and have the presentation in a room in your home where you feel at ease and comfortable.

Tip NO. 8 - Smoke test everything!

Check that everything works. At least once. Well in before-hand. Do you have internet access? Or do you need a personal hot spot on the fly when your service provider decides to give you some good-ol downtime in the middle of the day? Is your preferred video stream service up-and-running today, or do you need to find an alternative? Check your screen-setup, video-recording and microphone. Some of us have also recorded ourselves in trial-runs to see what can be improved. Personally I find recording myself highly embarrassing, however this is something that's highly recommended!

Tip NO. 9 - Audience, show your face!

This is important. If you ever have held a live digital presentation you know what I mean. You want to see an audience, and reaction! Everything helps. You may for example let them know in the beginning that you would appreciate to see some faces while presenting. If you are now comfortable with asking them, ask a colleague or friend to stay on video while you present.

Tip NO. 10 - Energize! ⚡

Sitting down while presenting can actually affect you presentations negatively (if you are not very conscious about this), and many digital presentations tend to become somewhat monotonous. Give the next digital presentation while standing. Unconsciously, this will give your presentation new energy and action!

Others tips here also include; use your hands! Change facial expressions! Laugh! Change your tone of voice and pitch!

Tip NO. 11 - Be careful with reading the chat

If you really want to read the chat underway and engage the audience in this way, be very careful as this may interrupt your whole speaker-flow (which is perhaps the most precious aspect of your presentation). If you still want to read the chat, set aside a specific time in your presentation to do so.

Tip NO. 12 - If you record, don't edit

Another positive aspect by you broadcasting your presentation digitally is that it's a very short way to making it accessible to many, many others by merely clicking the record-button. However, be aware that if you edit the video too much afterwards, the presentation becomes increasingly hard to follow.

Something else?

A big thank you to everyone that gave away these neat tips and tricks on digital presentations 💖 I'm sure that there is a lot more tips still out there. Please let me know on Twitter if anything comes to mind --> @nicolai_a_hagen.

How to improve your digital presentations (pt. 2)

Constraints Liberate, Liberties Constrain — Runar Bjarnason

Link: https://youtu.be/GqmsQeSzMdw

Length: 51 minutes

How much should we abstract our software? These choices we make have impact on the expressiveness and precision of our programs. In this video Runar Bjarnason, now one of the co-creators of Unison language (https://www.unisonweb.org/), dives into these contradictions we face with building abstractions.

Bonus video 🎉

Faster JavaScript with Category Theory - John Bender

Link: https://youtu.be/PtD-WKSC6ak

Length: 31 minutes

This video is not particularly relevant to the first, but it is a recent discovery on my part and you might enjoy ut too. It's an oldie but a goodie! John Bender gives an insight into category theory while showing how jQuery could be faster through the power of functional programming and category theory! If you know just a little javascript you will be able to keep up with this talk. 😄

Video spotlight: Constraints Liberate, Liberties Constrain

Et av områdene med mest bevegelse for tiden er markedet for strømmetjenester.

Disney er lansert globalt, HBO relanseres som HBO Max, filmer slippes direkte på strømmetjenester uten å gå veien om kino og ingenting tyder på at dette skal stoppe opp.

Men er forretningsmodellene for strømmetjenester ferdig innovert? Kan vi vente at noen vil prøve ut noe helt nytt på dette området fremover?

Håvard Hvassing og Jens Andreas Huseby tok en prat med Birgitte Seim-Haugen, som er produkteier for Strim i RiksTV.

Hva er framtiden for strømmetjenester?

Data is today recognized as the single most important resource to contribute to economic growth in the next decade. Connecting data in new ways creates new opportunities for innovation and new services. The public and private sector have engaged in this development by sharing many valuable datasets. But are todays methods for data sharing suitable for the future?

The data economy

Data has become the oil of the 21st century. And over the next 5 years we will have produced more data than the previous 5 000 years of humanity. However, unlike oil, data is a renewable resource, and as long there are computers, data will keep flowing through the fibre pipes that constitute the Internet. Not convinced? Please take a look at how much data is generated each minute.

With the increased amount of data flowing across devices and increased amount of data sources across public and private sectors, the value of data has gained political attention in the world.

For instance, the EU says:

Most economic activity will depend on data within a few years. The value of the European data economy for the 28 Member States is expected to grow from €377 billion in 2018 to €477 billion by 2020 and €1.054 billion by 2025

Similarly, other governments and political bodies recognize the importance of data as a source of innovation, new business models and improvement of existing digital services.\ \ Thus, with the increased amount of data, during the next 5 years we will witness a large ecosystem around both public and commercial data sources which will contribute to this economy.

How is data shared today?

Data today is mostly shared via web based APIs. Perhaps as a consequence of the famous Wogels quote that APIs will rule the world. Perhaps as a consequence of other uncontrolled factors in technological evolution. But the matter of fact is that APIs are the dominantly preferred medium/method for a data producer to share data with third party consumers.\ \ And the promise of APIs are many. Firstly, APIs are language independent. You can make APIs in almost every concievable programming language there is. And everyone can read from an API in any other language. It takes only a couple of lines of code to fetch something from an API. Secondly, APIs are platform independent. You can host APIs on premise, in the Cloud, on a Raspberry Pi, on your watch, you name it. As such, the ecosystem around APIs is enormous. REST based APIs have existed for a decade. And recently, we have seen the emergence of alternatives such as GraphQL. And web based APIs exist for almost anything imaginable, including how to brew beer. So what is the problem with APIs when it comes to sharing data?

Shortcomings

Let's assume you are an entity that wants to make your data available either as a completely public dataset, or a commercial dataset. We are in the year of 2025, where 50% of all data is produced on the fly by the 40 or so billion IoT devices. When even your vacuum cleaner is generating vast amounts of datatoday, it's not hard to understand that over 50% of data created in the world will be generated by IoT.\ \ Let's also assume that your system is generating a couple of gigabytes of data each day - by any means not a large amount even in todays systems. That would mean you would have some terabytes of data at hand.\ \ Let's further assume your data set is popular and you have a couple of hundred potential consumers of said data set.

\ What do you need to make your data available through an API?

You need engineers to develop, maintain and operate the backend and API. You probably need to make it performant, robust, secure and other things non-functional.

You need some place to host the API, either on prem or in a Cloud service.

You need some kind of network access to the API and enough bandwidth.

What kind of problems arise for those that want to make use of your data? Perhaps combine your data with other data to make a new service.

They would need engineers to make a robust ingest pipeline, sucking the data out from your API. Anyone who has done this, know how error prone and brittle these types of pipelines can be. In order to make them robust, extra care must be taken.

In order to make use of it, they most likely need to copy the data. Perhaps even historic data, hammering your API to get all those terabytes of data. So if there are a lot of consumers of a dataset, and some datasets have already today thousands of consumers, there will be multiple copies, with more or less synchronized datasets around, where only your data is the real source of truth.

Sharing data through an API is not the most human-friendly way of making data useful for others. In practice you are limiting data access to those that are tech-savvy, while in real life there are many business developers, analysts and other who could have equal use of data to innovate and create new business models.

The questions arise

Is an API really the best way to share such a data source?

Are APIs really well suited if the data in question is binary data such as audio, images, video or files?

Or if your data is real-time data, do you really want consumers to hammer your API endpoint to get up-to-date data?

Furthermore, what do you think would happen if you have 10 systems that share datasets to othe? Or 50? The points above become a problem of multiplication, and you realize that sharing data through APIs is resource-intensive with both special expertise necessary and system capabilities on both ends of the API.\ \ In the example above, we have only described a single data producer. Imagine how many connections in the graph you would get if there were thousands of data producers and thousands of data consumers all intertwined in a web sharing data back and forth via APIs. The problem is factorial.

Possibilities

Luckily, some have already faced issues with the described model with regards to data sharing, and possible solutions are emerging. \ \ One of the examples of such a solution is to make your dataset available through a Cloud provider data marketplace. AWS and Google have both such marketplaces

https://aws.amazon.com/data-exchange/

https://console.cloud.google.com/marketplace/browse?filter=solution-type:dataset

An example of a dataset made available through this mechanism is the OpenStreetMap dataset. There are hundreds of other datasets available in these marketplaces. The advantage of this mechanism is that the Cloud provider takes care of the infrastructure, and it is equally easy, or in some regards easier for consumers to make use of the data.\ \ Another possibility is to provide data through a messaging interface / streaming platform, decoupling the producer from consumers and providing a model for serving real-time data to third parties that is better than APIs, which are in nature based on a request-response model. There are many open source alternatives to these types of systems, such as Kafka, and a lot of Cloud providers also provide general purpose managed services based on a messaging / data push interface. A well known example of a purpose-built system based on a data push-model are the notifications you recieve on your phone from all the applications you use. \ \ A third possibilty if you have huge amounts of binary data, such as video, is to make such data available in the buckets on Clouds, such as S3, GCS or Azure Storage.\ \ No matter what type of data you have or will have in the future, in order to make good choices for how to share data, you must familiarize yourself with the possibilities and the shortcomings of the alternatives I have mentioned as well. Perhaps even better alternatives for data sharing will emerge. Or perhaps we will be stuck with APIs forever. Time will tell.

Rethinking data sharing in the next decade

Elm and other functional programming languages might look weird and scary to newcomers. Once you get to know them, however, functional languages becomes very clear and satisfying to work with Let's look at the MVU - Model, View, Update - architecture. The architecture is also known as TEA - The Elm Architecture - but is useful in other languages as well

A program can be split into three very simple pieces; model, view, and update. We'll start with the model. This contains the state of the program.

The state of the program is currently represented by one property, a counter of how many gifts someone has received that is represented by an Int type. The Model is represented by what is called a record, and is a central store for all the data we use to represent our application with. The `Model` will at all times contain the most recent data that we want to use in our program. So if a user has clicked something that changes the state of our program this should create a new state which will be the current state of the program.

So how is the model updated? That's where the update function comes in. The update function takes in the current Model and a Msg that describes how the Model should change, and returns the new Model`

As we can see from the signature of the `update` function it takes a Msg, and the Model, the state of the program. The Msg defines what is to be updated, and is a type that is a collection of all the different ways we can update the Model. Our central state is then updated in accordance with how update handles the specific Msg that is received, and the new state is outputted as part of the tuple ( Model, Cmd Msg).

The second part of the tuple that is returned is the Cmd Msg, which can seem a little cryptical at first. To be able to do operations separate from elm's "model, view, update" lifecycle we need to use commands depicted as the type Cmd. These commands will be operations like changing the url path, or fetching some data from an API. As we can see the type Cmd also takes a msg, which represents an arbitrary message. Notice that `msg` and `Msg` are different, `msg` (with first letter lower cased) represents any arbitrary type, while `Msg` (with first letter upper cased) represents an actual type, in this case defined by us. In our case we have defined this as Msg which is the type of messages that can update our Model in the update function. This Msg part of Cmd Msg is an important element of understanding commands in elm as this is a way of saying "do this command, and give it back to my update function". The program then proceeds to update the Model in the way that `update` is defined to handle that specific `Msg` that is provided to the `Cmd` type.

The last element in the MVU, is the view. This is where the html is defined, where we decide how we want the page to look, and how the various html elements should be arranged.

If we didn't have any elements to interact with, or didn't need anything to change in our application, then we would not need to pay attention to the other two elements in the MVU architecture. Like most applications we do want to build a webpage that changes as the user interacts with elements in our application.

We can see from the definition of the view function that it receives a parameter of the Model type which we have learned is the state of our program. The view will use the data we have chosen that resides in the Model to represent the application correctly. This will always be the newest version of the state, so whenever a Msg type is dispatched to the update function, this Msg will proceed to update the Model and the view will be rendered with the newly updated Model.

The return type of the view function is also interesting. This is Html Msg where Html is the core building block of html code. Msg is what we would like to happen when the user interacts with our `Html. For instance, what Msg should be sent to the update function when a specific button is pressed

As an example, let's see how a view that allows the user to update their gift-receiving counter would look like.

When the button is pressed, the Msg ReceivePresent will be dispatched to the update function. This updated the model, which then causes the view to be refreshed with the new state.

Let's talk about TEA - The Elm Architecture!

Imagine you're sitting on the train on your way to work, and you suddenly get an epiphany on how to solve that mind numbing coding problem that's been bothering you over the last few days. You whip out your laptop, create a new Kotlin file, implement the standard main function, and hit "Build" to verify that everything is OK. By the time IntelliJ responds with a "green light", your stop has been announced on the speaker system and you have to drop what you were doing. At the office, the solution you once had so clear in your mind now is lost to the void. If only you had a tool to quickly verify that code snippet, with less overhead!

This example is arguably a little overdramatised (*), and you would probably be better off just scribbling down some pseudo-code in an arbitrary text file, instead of going through the process of setting up a new project. Although, there might be certain times where we want to have some code executed and output printed as fast as possible, to be able to quickly verify or refute some assumption. A quick feedback-loop like this is also very convenient in a learning phase, be it a new concept or a new language. Luckily JetBrains has got our backs and provided us with just the tools we need: Scratch Files, Worksheets and REPL capabilities.

* Besides, theres not really much commuting these days with mostly everyone working remote

Scratches and Kotlin Worksheets

If you want the whole suite of IntelliJ built in auxiliary coding tools, you pretty much have two types of alternatives for your code sketching needs. Firstly there's Scratch Files (or Scratches for short), which aren't tied to any particular project, and are stored in a separate area (*). Kotlin Worksheets are similar, but will be tied to a specific project upon creation. Personally I tend to use mostly scratches, but it can be convenient to have them included in the project itself, in which case worksheets would be the go-to alternative. Additionally, scratches support a wide variety of different languages and extensions, in addition to Kotlin. We'll be focusing on Scratch Files for this article.

Scratches can be created either via the menu File > New > Scratch File, or by using the built in shortcut if you find that more convenient: ⌘ + Shift + N or Ctrl + Alt + Shift + Insert for Mac and Windows respectively, if using the default keymap. Finally choose the Kotlin format for your scratch file, and you're good to go; a file with a .kts extension will be opened in a separate tab. To avoid losing your scratches, it may be an idea to rename them and move (or copy) them into a more persistent location.

* Your scratches can be found under Scratches and Consoles in the IntelliJ project tree

Features of scratches, and how to run them

Auxiliary tools

We're ready to put that ingenious Kotlin idea of ours to the test! With the scratch file open in IntelliJ, let's take a look at what kind of features we get:

We can see clearly that our Kotlin code has been syntax highlighted in addition to code completion being active, like we're used to when working with regular Kotlin files. In general we can pretty much write Kotlin code like we normally would in any other IntelliJ Kotlin project. One thing to note here is that a Kotlin scratch file does not require us to create an entry point, i.e. a Kotlin application main method, so we're able to start typing and executing Kotlin code right away. The output will be conveniently displayed in a window to the right of our source code upon hitting Run Scratch File.

Including project modules

By default we have access to the native Kotlin language constructs as well as the the Kotlin Standard Library in the scratch file context, which is why we're able to invoke the iterator and forEachRemaining functions in the example above. Should you want to use functionality from other modules defined in a project of yours, you can do so by choosing the Use classpath of module option and select said module from the dropdown. You may now import and reference functionality defined in the module from within your scratch file (*):

* If you get an Unresolved reference error in the Scratch Output, make sure the functionality from your module is defined inside a package.

Customising scratch file execution

We have two additional options that can be toggled to alter how our scratches will be executed: Interactive mode and Use REPL, where the former simply enables our scratches to be run automatically if we stop typing. Use REPL means that we will switch to a Read-Eval-Print-Loop execution style, where each expression will we evaluated and its output printed individually. As a result if we append new expressions to an existing scratch file, IntelliJ doesn't have to execute the whole file, but rather only the last expression we added. Personally I like to toggle both options, which lets me sketch out code and see the resulting output instantly.

Use cases

The example provided in the beginning, although a bit contrived but realistic nonetheless, is just one of the possible use cases. Depending on your work and learning process, using scratch files can be an excellent way to try out new Kotlin concepts, or simply using it as a place to dump some logic that you do not want polluting your project. If we look a little closer at the extension that IntelliJ uses for scratch files, .kts, it is implied that scratch files are simply Kotlin Script files opened in a particular IntelliJ context. Sharing code snippets, and even longer scripts, now becomes a trivial operation, since we can create a arbitrary .kts-file and exchange it with a friend or colleague. Given that they are using IntelliJ the file can simply be dropped into Scratches and Consoles and they'll be able to execute it and see the output in a matter of seconds. Additionally, scratches are a nice offline alternative to the Kotlin Playground.

Alternatives with even less overhead

To create and use a scratch file you have to at least get IntelliJ up and running with a project, in order to access the scratches folder. If you're comfortable not having the auxiliary tools that IntelliJ provides, like syntax highlighting for instance, a more lightweight approach can be used. It's possible to make use of the Kotlin REPL to execute Kotlin code snippets directly on a command line and avoid IntelliJ and a corresponding project setup all together. Invoking kotlinc on a command line will give access to an interactive shell in the Kotlin compiler, where we may execute individual Kotlin code snippets and read output from the console. The standalone Kotlin compiler can be found here: https://github.com/JetBrains/kotlin/releases/latest. The Kotlin REPL tool is also accessible from within IntelliJ.

Whether you opt for auxiliary tools or the barebones approach, you've hopefully gotten a few new alternatives the next time you're in need of some quick code sketching!

Kotlin code sketching in IntelliJ with Scratch Files and Kotlin REPL

Basert på økonomisk teori bør det overordnede målet for private virksomheter være finansiell verdiskapning. Men hvordan skapes egentlig finansiell verdi? Og hva bør prioriteres mellom lønnsomhet og vekst?

Et selskap investerer kapital i prosjekter som genererer avkastning på kapitalen gjennom kontantstrømmer. Den finansielle nåverdien av et selskap er verdien av kontantstrømmene (avkastningen) selskapet klarer å oppnå i fremtiden, diskontert for kapitalkostnaden til kapitalen som bindes opp i selskapet. Kapitalkostnaden reflekterer den avkastningen alternative selskaper/prosjekter med tilsvarende risiko vil generere. Dersom selskapet oppnår en avkastning som overstiger kapitalkostnaden skaper den verdi, og dersom avkastningen er lavere enn kapitalkostnaden ødelegger det verdi. Dermed følger det at verdiskapning baserer seg på å øke kontantstrømmene (avkastningen) selskapet klarer å oppnå på sine prosjekter og investeringer. Kontantstrømmene kan hovedsakelig økes gjennom å øke lønnsomheten eller veksten.

Kampen mellom lønnsomhet og vekst

Verdiskapningen som følger av å øke lønnsomheten eller omsetning avhenger av den spesifikke virksomheten og situasjonen den står overfor i dag. Grafen over viser verdien til et tenkt selskap, og hvordan det påvirkes av forskjeller i lønnsomhet (målt ved totalkapitalavkastning) og vekst. Selskapet har en kapitalkostnad på 9%. Dersom selskapet har en lønnsomhet som er det samme som kapitalkostnaden (9%), skapes det ikke noe verdi ved at selskapet vokser. Dersom selskapet har en lavere lønnsomhet enn kapitalkostnaden, ødelegges det verdi for hver ekstra omsatte krone. Dersom selskapet har veldig høy lønnsomhet, oppnår det relativt begrenset verdiskapning av å øke lønnsomheten ytterligere. Vi ser med andre ord at hva som bør prioriteres av lønnsomhet og vekst avhenger av virksomhetens situasjon.

Lønnsomhet og vekst på bekostning av hverandre

Lønnsomhet og vekst kan ofte gå på bekostning av hverandre. Dersom du har kjempelave marginer og nærmest gir bort et produkt gratis, er det sannsynlig at kundene flommer inn døren og gir deg høy omsetning. Dersom du har høye marginer og snyter kundene dine maksimalt, er det sannsynligvis få kunder som er interessert. Et selskap i situasjon A i figuren over bør fokusere alt de kan på å øke lønnsomheten uten å fokusere på vekst i det hele tatt, snarere tvert i mot. Dersom de ikke klarer å oppnå en lønnsomhet som er over kapitalkostnaden vil de skape verdi ved å legge ned virksomheten. Et selskap i situasjon B i figuren over bør derimot fokusere alt de kan på å oppnå vekst uten å ha like stort fokus på lønnsomhet. For de aller fleste selskaper som befinner seg et sted i midten, vil det alltid være en avveining mellom lønnsomhet og vekst. Beslutningen om å fokusere på vekst, lønnsomhet eller begge deler bør derfor være fundert i grundige nyttevurderinger av verdiskapningen som oppstår av de ulike strategiske grepene.

Vekst som forutsetning for lønnsomhet

Noen ganger er vekst en forutsetning for å oppnå lønnsomhet. Enkelte bransjer har betydelige stordriftsfordeler, der du er nødt til å ha en viss kritisk størrelse for å oppnå en lønnsomhet på linje med konkurrentene. Det er vanskelig å lykkes med et flyselskap som bare har ett fly, en dagligvarekjede med bare en butikk, eller et bemanningsbyrå med bare en ansatt.

Spesielt innen fremveksten av nye teknologiske start-ups innen sosiale medier og delingsplattformer er nettverkseffekter rådende, og det er avgjørende å oppnå en kritisk masse av brukere. Du hadde aldri brukt Facebook hvis du bare hadde tre venner som brukte det, og du hadde aldri brukt Nabobil hvis de bare hadde en bil tilgjengelig. De sterke nettverkseffektene sørger også for at konkurransesituasjonen blir kraftig svekket når en aktør først har tatt et marked, slik vi ser av den nærmest monopolistiske posisjonen Google, Facebook, Uber og andre har oppnådd. Når man først har en «Facebook» som fungerer, er det vanskelig å få noen til å ta i bruk en ny tilsvarende tjeneste uten betydelig differensiering og innovasjon. Samtidig har disse tech-selskapene ekstremt lave variable kostnader – slik at lønnsomheten er nærmest proporsjonal med antall bruker. Derfor er det i disse bransjene spesielt viktig å fokusere på vekst, både for å øke kvaliteten på produktet og kapre markedet for å oppnå en monopolistisk posisjon på sikt. Da kommer lønnsomheten «av seg selv».

Lønnsomhet som forutsetning for vekst

Dersom et selskap ikke er lønnsomt og taper penger, vil vekst føre til enda flere tapte kroner og sånn sett være kostbart. Veksten kan ikke finansieres fra selskapets drift og man vil måtte låne penger eller få med seg eksterne investorer. Mange vekstselskaper har ikke tilgang til gjeldsfinansiering, og gjeld kan generelt medføre en del ulemper som strenge lånebetingelser, høye rentekostnader og økt konkursrisiko. Å hente penger fra eksterne investorer vil medføre utvanning av de eksisterende aksjonærene, og enkelte selskaper vil kunne ha problemer med å hente kapital på attraktive verdsettelser. Disse problemene unngås dersom man har oppnådd lønnsomhet før man fokuserer på vekst, og man har da muligheten til å vokse raskere og uten å måtte hente inn kapital for å gjennomføre veksten.

Et selskap som AirBnB har oppnådd rekordvekst uten lønnsomhet som følge av at de har kunnet hente store mengder kapital til høye verdsettelser og dermed lav utvanning for eierne, takket være solide fremtidsutsikter til monopol og høy lønnsomhet. Men de aller fleste selskaper har ikke like unike verdiforslag med like gode fremtidsutsikter som AirBnB. Virksomheter innenfor tradisjonelle, kompetitive bransjer som for eksempel flybransjen, olje og gass, oppdrett, retail, finans og så videre vil ha problemer med å hente kapital dersom de taper penger, og bør dermed fokusere på å få lønnsomheten på plass før de fokuserer på stor vekst.

Når søken etter finansiell verdiskapning går for langt

Maksimering av finansiell verdi for aksjonærene har historisk vært det ledende målet for private selskaper. Men private selskaper har en rekke andre interessenter de også bør skape verdi for – kundene, de ansatte, samfunnet, miljøet og så videre. Higen etter å maksimere aksjonærverdi kan bli for kraftig og få uheldige konsekvenser for øvrige interessenter, som man har sett mange eksempler på gjennom tidene. Selskaper som driver feilaktig markedsføring og selger kunder feil produkter, utnytter ansatte og driver sosial dumping, "beacher" skip på strendene i Bangladesh, skaper finansielle katastrofer grunnet overdreven risikotaking og så videre. Utelukkende fokus på maksimering av finansiell verdi, og insentivordninger som utelukkende støtter dette, kan raskt være veien til uetisk og problematisk drift. Hvis man kun blir målt på egenkapitalavkastning og aksjekurser kan det fort oppstå en uheldig kultur preget av snarveier og moralsk tvilsomme beslutninger.

Konsernstrategi

Finansiell verdiskapning bør være et av hovedmålene som inngår i en konsernstrategi, der lønnsomhet og vekst vør være hovedfokusområder. Om et selskap bør fokusere på lønnsomhet, vekst eller begge deler vil avhenge av det spesifikke selskapet, dets eksisterende lønnsomhet og vekstrate, konkurrentlandskap og bransje. Det er derfor viktig at man har en analytisk og datadrevet tilnærming der man ser helheten og estimerer effektene av ulike strategiske retninger. Private virksomheter har også et stort samfunnsmessig ansvar, og bærekraft og samfunnsansvar bør også være viktige komponenter i konsernstrategien slik at man unngår at jakten på finansiell verdiskapning går for langt.

Hvordan skapes finansiell verdi?

Ever wanted to implement a search as-you-type? What about transforming something while the user is scrolling. Just add an event listener for this works, but it can really impact the browser performance. Fetching from the server on every keypress isn't just unnecessary, it may also be hard on your server. This can be solved by two functions, debounce and throttle. Let's have a look at the difference between the two and how they can be implemented

What is the difference?

Throttle and debounce are two very similar ways to handle function calls to optimise performance. Throttle is normally used when you have a function that is called continuously while the user is interacting with your page, e.g. while scrolling. Debounce is used to call a function when the user has stopped interacting, e.g. when they have stopped typing in an input field.

Let's say a function is fired many times. By using throttle, the function will be called at a set interval, every n milliseconds. By using debounce, the function will be called n milliseconds after the last fired function.

Search-as-you-type

Let's say you have an input for searching, but you want to give the user results while typing. Sending a request for every key entered is not only heavy on the server, it is also unnecessary if the user types more letters before the response gets back from the server. We can utilise debounce to instead send the request when the user has paused typing.

debounce is a higher-order function that takes two arguments, func, the function that will be debounced, and wait, the wait in milliseconds before the passed function will be called, unless it's cancelled by a second call.

So if we type a key in the searchField a request to the server will be sent after 500 milliseconds, but if the user types another key before that time has elapsed, the request is delayed another 500 ms.

Let's see this in action. Type something into the search input, and if you pause for more than 500 ms a "search" will be triggered. Don't expect any results here though.

We can also improve our debounce a bit by passing the parameters from the event to our debounced function, allowing our function to get the value of the input.

The reason the returned function is not an arrow function, is because it would have resulted in this being bound to debounce and not the returned function, and the context would have been lost to our debounced function.

We may also expand debounce and add a third attribute to our function, maxWait. This allows us to force the function to be called at least every n milliseconds, which can be useful in some cases.

Let it scroll, let it scroll, let it scroll

While debouncing calls the function after the user has completed typing, a throttled function is called every n milliseconds, limiting how many times a function is called. Throttling is best suited when a continuing function call is needed, like on scrolling, window resizing or drag and drop.

Here we're creating a function throttle, and utilise it by a function that should be called when the user scrolls the browser window.

Similar to debounce, throttle is a higher-order function. The function that is returned will be called by the event listener, that is when the user resizes the window. As long as the flag waiting from the previous function call is set, func will be called after wait.

And here it is in action:

As you may notice, the throttled boxes are "lagging" a lot more than the ones not throttled. So in this scenario a throttle isn't really needed, but in cases of for example resizing you will have great use for throttle. A resize event can be especially heavy since the browser needs to rerender everything.

How long do we need to wait?

For both debounce and throttle the wait should be set to your situation and find what gives the best performance for your users and application.

Let's wrap it up

I hope this makes it clearer how debounce and throttle differs from each other. To

I also recommend taking a look at how some libraries have solved these functions. Lodash and Underscore.js both have implementations that are well tested and they have probably thought of other cases that I haven't done here.

Debounce and throttle

Hva har Marie Kondo og Hey til felles? Hvordan kan de hjelpe en rotete sjel å få styr på nyhetsbrev og viktige e-poster? Her får du et innblikk i hverdagen til en designer som elsker organisering, ispedd et aldri så lite review av e-posttjenesten Hey.





Jeg digger organisering. Kanskje på et litt nerdete nivå. Jeg var nok blant de første til å “binge” hele Marie Kondo-serien på Netflix. Da the Home Edit dukket opp midt under korona, ble det flere timer med "rydde-TV". Det er rart hvordan noen av oss blir fascinert av sånt. Det går litt i kategori med "Sinnasnekker'n Sverige", "Luksusfellen" og "Tid for hjem" - en såkalt guilty pleasure. Det er ikke akkurat realityserie, men det er et eller annet veldig tilfredsstillende med å se at folk rydder opp i livene sine.

Jeg er også en person som kan kose meg med å browse og bestille matchende oppbevaringsbokser fra Clas Ohlson. Sånn at innholdet av korn, frø og mel kommer til sin rett, i like gjennomsiktige bokser. På denne måten er det mye enklere å finne det jeg skal ha, og jeg ser med en gang når noe må fylles på.

Man skulle derfor kanskje tro at jeg er en ryddig person. Det kan jeg avkrefte. Er det én person som roter i husholdningen, så er det meg. Jeg er litt usikker på hva som skjer. Det kan gå fra å være superfint og strøkent, til neste dag å være ting overalt. Jeg har derfor hatt stor nytte av å innføre noen av tiltakene til Marie Kondo.

Alt du eier bør ha en fast plass

En viktig brikke i Marie Kondos filosofi går ut på at alt du eier, bør ha sin egen plass. Og det du eier skal helst gi deg glede, eller “spark joy” som hun så fint sier. Dette har hjulpet meg mye, og i 2020 har jeg tatt for meg skuff etter skuff. Sortert ut ting som jeg ikke trenger lenger, og forsøkt å gi hver ting et fast sted. I tillegg er klærne mine nå brettet vertikalt, og det er mye lettere å finne riktig bukse med én gang. Likevel hender det jeg fyker rundt og leter etter ting, som her om dagen da jeg til slutt fant Bilkollektivet-kortet i lomma på bunaden, som var pakket vekk for flere uker siden. En må kanskje regne med noen glitcher i matrixen.

Jeg vil si at det digitale livet mitt er omtrent som det virkelige. Noen steder har jeg stålkontroll. Andre steder, not so much. Jeg kunne snakket om et skrivebord som er så fullt av skjermbilder, at jeg i desperasjon før et kundemøte smekker alt sammen inn i en mappe som heter “desember”. Det som kanskje er hakket verre, er innboksen min.

Ganske sikker på at mange grøsser av å se dette. Andre nikker kanskje gjenkjennende. 5479 uleste e-poster. Hvordan kan en som har komplett orden i kjøkkenhylla, samtidig ha SÅ mye rot i sitt digitale liv? Godt spørsmål. Jeg tipper at 80 % av e-postene er nyhetsbrev som jeg av en eller annen grunn en gang i tiden har takket ja til. Men altså ikke meldt meg ut av.

Det er en stund siden jeg har praktisert inbox zero. Og det er ikke sånn at jeg ikke sjekker e-postene mine. Jeg tror jeg bare har blitt litt blind. Blind for notifications, og blind for å åpne ting som ikke er relevant. Det blir en jevn strøm av åpnede og ikke-åpnede e-poster, både viktige og uviktige, fordi jeg ikke har et godt sted å plassere dem. Jeg er klar over at jeg kan putte ting i mapper, og legge på labels, men jeg har rett og slett ikke fått til en god rutine på dette. Verktøyet er der, men prosessen ei.

Hey

På Y-konferansen til Netlife fikk jeg høre om Hey - en e-posttjeneste som ble lansert i juni i år. Hey skal røske tak i de virkelige e-postproblemene. Kunne dette løse min manglende oversikt i innboksen? Jeg bestemte meg for å gi det en sjanse. Her følger mine erfaringer med Hey i løpet av knappe to uker.

The Screener

Det første konseptet jeg blir introdusert for, er en screener. Hey lar meg ta stilling til én og én avsender: Ønsker jeg å motta e-post fra denne personen eller bedriften? En liten lyspære blinker i bakhodet mitt - dette høres da kjent ut? Akkurat som med Marie Kondo-metoden, skal jeg altså her ta tak i én og én avsender, og vurdere om jeg skal la den få spille en rolle i mailboksen min. Etter å ha takket ja til Hey som avsender, rekker jeg å se at jeg har mottatt ikke mindre enn seks e-poster fra dem. Antageligvis tips og triks for å lære meg systemet, men det oppleves litt i overkant mange. Jeg har uansett ikke tid til å lese dem med én gang.

Et par dager senere logger jeg inn med ny giv og lyst - klar for å sette meg ordentlig inn i sakene! Dette møter meg:

47 nye avsendere på bare to-tre dager. Jeg innser at dette er en glimrende mulighet til å få meldt meg av en haug med nyhetsbrev. På kort tid har jeg både meldt meg av, og screenet alle de 47 avsenderne; noen ønsker jeg å få e-poster fra, andre takker jeg rett og slett nei til. Magisk!

Alt får endelig sin plass: Imbox, The Feed og Paper trail

De få nyhetsbrevene som er interessante velger jeg at skal gå direkte til “the Feed”, i stedet for at de skal lande i innboksen. Eller "Imbox" - som det heter hos Hey. For i Heys imbox skal jeg bare ha viktige - "important" - e-poster. I feeden derimot, lar Hey meg scrolle gjennom nyhetsbrev i et helt annet format. Alt er åpnet, akkurat som på Instagram. Får jeg derimot kvitteringer eller ordrebekreftelser, kan jeg velge å sende disse direkte til "the Paper Trail". Jeg kan også velge at alt først skal gå til Imboxen, og selv sortere det videre om jeg ønsker det. Imboxen gir også en naturlig imbox zero-state når jeg har åpnet og sortert dagens mail.

Hvorfor er dette digg? Her blir det naturlig å trekke en parallell til Marie Kondo: For at man enkelt skal kunne holde det ryddig må alt ha sin faste plass. Og har det ikke en fast plass, ja så må man opprette eller lage en slik plass. Her blir Imboxen stedet for viktige ting jeg må ta stilling til, Feeden stedet for å sjekke ut teaterforestillinger, og Paper Trailen blir fylt opp av ordrebekreftelser, kvitteringer og hentemeldinger fra Posten nå før jul.

I tillegg minsker den kognitive lasten hver gang jeg åpner imboxen. Noe som er et viktig UX-prinsipp i seg selv. Jeg slipper å ta stilling til nyhetsbrev, og kan heller oppsøke dem når jeg har lyst. Færre valg = mindre tid brukt til kjipe ting = bedre brukeropplevelse.

Andre smarte funksjoner

Notifications er default satt til å være av. Jeg kan legge til notater til e-postene mine. Og jeg kan bruke hurtigtaster til ALT.

Kommer det en e-post jeg ønsker å svare på, men det passer litt dårlig akkurat nå, markerer jeg den med “Reply later”. Dukker det opp noe jeg må ta stilling til, men ikke skal svare på, kan jeg legge den til side i en pen liten bunke - lett tilgjengelig.

Jeg kan til og med kopiere ut små ting fra e-postene som er relevante, såkalte “clips” for enklere å finne dem igjen senere. Perfekt til hentekoder på posten eller lignende som man ofte må skumlese for å finne igjen.

Etter 8 dager er det nesten sånn at jeg gleder meg til å åpne Hey. Hvor mange nye avsendere kan jeg luke ut i dag? Snart senker ikke bare natten seg, men også skuldrene mine, og jeg får mer og mer julefred for hver dag som går.

For godt til å være sant?

Det finnes garantert noen negative sider ved Hey. De har ikke integrert en kalender, og man kan ikke bruke sitt eget domene - foreløpig. Av mindre features skulle jeg ønske det fantes en “angre”-knapp når jeg har gjort en handling. Jeg har foreløpig bare testet dette til privat bruk, men nettsiden lover at “Hey for work” skal komme i 2021.

Likevel - jeg digger konseptet. Og jeg tror mye av grunnen til dette, er at Hey har tatt tak i et virkelig problem. De har ikke bare laget nok en e-posttjeneste som er prikk lik alle andre sin, men tenkt nytt rundt hele konseptet: Hva har man behov for? Hva er smertepunkter? Hvordan kan dette produktet støtte opp under brukerens faktiske prosesser og hverdagsliv? Og ikke minst - hvordan kan produktet gi en rotete sjel litt mer system i sakene?

Jeg har nå igjen to dager før jeg må betale for Hey. En forholdsvis stiv pris til å være e-post, med 99 dollar per år. Men - jeg har blitt kvitt over 40 nyhetsbrev. Jeg har sagt nei til avsendere jeg strengt tatt ikke trenger å motta noe fra. Og jeg har på magisk vis klart å opprettholde en slags zero imbox. Kanskje er det litt som med kjøkkenhylla mi: Når jeg først har fått ting på plass, så er det mye lettere å holde orden. Du skal ikke se bort fra at dette blir årets julegave. Til meg selv, fra meg selv, med ønske om en ryddig og fresh start på 2021.



Tusen takk til Helen Le, Kjersti Barstad Strand og Ola Claussen for innspill, korrekturlesing og support.

19-Dec

Today's posts