I had been working as a developer for a good 12 years when I was approached by my manager, and asked if I could assume the position of team lead for a while.

I was humbled to be asked - however the mere thought of performing some of the tasks required by someone in that position in that particular setting was very frightening.

I had been working with the former team leader, who left on maternity leave. She had to perform public speaking in different situations. One were the daily standups where a relatively small group of coworkers briefly discusses their various day-to-day tasks. To be in charge of this, and make people listen to you, felt somewhat more challenging than just be one of the contributors to the standup.

Moreover, the team lead also had to do a bi-weekly priority meeting, with a few more participants. This required a lot more preparation, and a lot more focus on the team lead, who would have to steer in the meeting in the right direction.

And if that wasn’t the worst part of it - every three weeks the team lead had to perform a demo where everyone in quite a big organisation was invited. The demos had routinely attracted a full auditorium consisting of something like 200-300 people.

Mostly because of this, I turned the offer as team lead down. Leaning back to do what I was already doing - developing software safely in front of my own computer - was much preferable to this.

I told my spouse that I got this opportunity - and she pointed out that while it maybe felt right at the moment to turn this down, I had maybe forfeited the chance to be asked again.

After a couple of days my manager told me that he had found no other suitable successors, and actually asked me again! A bit out of sense of duty I accepted.

As goes for most people, I dreaded holding any form of presentation, all eyes on me.

First there was the standups. This felt a bit uncomfortable at the beginning, but people were focusing and the meetings were over pretty fast with minimal interference by me. I got routined quite quickly - learned to crack a couple of low-key jokes every now and then, and playing with the order the participants introduced their daily works and challenges helped to relieve a lot of the tension.

The priority meetings was a bit more challenging, but just a bit - after a while I found similar ways to look forward to these in the same ways as standup.

So cue the big demos.

They were held on a Friday morning - the Thursday nights before I hardly slept at all due to the stress of standing on the stage with hundreds of pairs of eyes looking at me.

There were a couple of times where everything just went down the drain.

Once we were supposed to demonstrate some functionality, and the two teams presenting right after us were dependent on our functionality actually working.

Guess what - it didn’t, due to an ancient version of Firefox on the demonstration machine every team had to share for their demos.

Another time I actually got a message from a developer on my team which simply stated “Nothing is working.” Very comforting message to get.. I just went with my usual poker face, said with as little emotion as possible to the audience - “sorry, nothing is working, we have to show you this in three weeks instead”.

However, even if these weren’t exactly good and comforting experiences, I eventually felt very confident after performing these enough times.\ So we screwed up a couple of times - big deal.

“What is the worst that could happen?” Well, as we have read, all the work you have planned to show could stop working. In the long run, no one really remembers this.

I have some tips to reduce nervousness before a presentation.

I have found out that these works for me, your mileage might vary.

I try to tell (at least one) joke every presentation. The bar is surprisingly low in such a setting, and it makes me look just forward to telling it.

It does not have to be something who would be a candidate for Best Comedy award - for instance making some testdata with quirky names might be enough.

One I just made a lot of test data with a made-up story of how I as a test person could be in that situation, and - well, I guess you had to be there to find it funny, but it made it much easier for me, the presenter, and that is the point.

The most important advice is practice and not taking yourself too seriously, which is easy to say, but comes.. with practice.

Now I can honestly say that I have little to zero negative thought about holding a presentation at any time.

How I stopped worrying and started to love holding presentations.

Pia Solheim og Hilde Marie Flesland Torall tar en prat med Camilla Brustad-Nilsen som er digital forretningsutvikler i Storebrand

Bølge, en innovasjon som feilet?

«Hvis du ikke betaler for produktet, er du produktet».

De som har sett filmen The Social Dilemma fra 2020 vil garantert kjenne seg igjen i dette ordspråket. Det er en spissformulering på en stadig vanligere inntektsmodell hvor selskaper tilbyr tjenestene sine gratis mot at brukerne aksepterer å bli eksponert for annonser. For aktører i dagens mer og mer digitaliserte verden finnes det mange innovative inntektsmodeller å basere seg på – men kan et hvilket som helst selskap finne nye måter å tjene penger?

En inntektsmodell er komponenten i en bedrifts forretningsmodell som beskriver måten de ønsker å ta seg betalt for produktene sine. Den skal gjerne si noe om hvem som betaler, på hvilken måte de betaler, hva de betaler med, og når. Bedrifter og produkter kan ha flere inntektsmodeller – freemium er et kjent eksempel som gjerne kombinerer annonseinntekter for gratisbrukere med abonnementsinntekter fra «premium»-brukere. Når man har valgt en inntektsmodell, kan man sette opp en prisstrategi. Denne skal maksimere profitten innenfor rommet som inntektsmodellen tillater. Uber er et enkelt eksempel for å illustrere forskjellen: Inntektsmodellen deres er å ta en andel av transaksjonen mellom passasjer og sjåfør for turen, mens prisstrategien er dynamisk prising basert på tilbud og etterspørsel i et gitt område til enhver tid.

For mange forretningsmodeller har inntektsmodellen stått uendret i lang tid. Vi kjøper matvarer på butikken og betaler for dem der. Vi går til frisøren, får en hårklipp og betaler for den. Bedrifter kjøper maskindeler av underleverandører ved behov og betaler stykkpris. Men det blir stadig klarere at disse «tradisjonelle» inntektsmodellene hverken er uerstattelige eller optimale. Spesielt «as-a-Service»-tankegangen har spredt seg til stadig flere bransjer, hvor man ofte ser en innføring av abonnementsmodeller (gjerne kombinert med heldigitale kjøpsopplevelser og hjemlevering) eller betal-per-bruk i stedet for tradisjonell stykkpris gjennom detaljhandel. Matkasser er et godt eksempel på dette i dagligvarebransjen. Massasjetjenesten Squeeze er et tilsvarende eksempel i servicenæringen, hvor kundene betaler en fast medlemspris i måneden for én massasje med opsjon på flere til en rabattert pris. I B2B-markedet kan vi se til flymotorleverandøren Rolls Royce, som tar seg betalt for timer i lufta i stedet for per motor de selger. Kunden betaler dermed kun for bruk, mens leverandøren tar ansvar for alt av vedlikehold, reparasjoner og oppfølging. Idéen strekker seg faktisk så langt tilbake som 1962!

Eksemplene over viser oss at nye inntektsmodeller dukker opp overalt. Hvor skal man begynne hvis man vil innovere i sin egen inntektsmodell? For det første er det bør man se til andre bransjer for inspirasjon. Abonnementsmodellen ble opprinnelig kun brukt for aviser og trykksaker, men brukes nå for å få tilgang på alt fra barneklær til biler. Videre er det viktig å forstå kundens faktiske behov. Det gjorde Rolls Royce med sin betal-for-bruk-modell: Kundene er opptatte av at flyene deres fungerer når de skal, ikke av flymotorer eller serviceavtaler. Til slutt bør man utfordre etablerte sannheter og tørre å tenke utenfor boksen. Hvorfor kan man for eksempel ikke fly gratis mot å se reklame hele flyturen? Kun fantasien setter grenser!

Hvordan finner selskaper nye måter å tjene penger på?

When using fully-managed Azure SQL databases, there are mainly two different cost/resource models to choose between. In my team, we have been running the Standard tier, which has a fixed amount of resources provisioned, and thus a predictable fixed cost. The alternative is the Serverless tier that scales the database on demand, and instead, you pay-per-use.

One of our important production databases uses a lot of computing power while performing various tasks once every morning, and then smaller sporadic load the rest of the day and night. A good fit for the Serverless tier? Could we achieve the same performance at a reduced cost? Read on, and I will let you in on what I figured out.

Standard tier

First, let's talk about the Standard tier. It has a simple method of deciding how much power you need by saying how many DTU (Data Transfer Units) you want. This divides into eight different intervals from S0(10 DTU) to S12(3000 DTU). Our database is on the S9 (1600 DTU) tier. This means the database has a list price of around 20 000 NOK/month. The power is needed to be able to cope with its many tasks serving as an analytical platform. We need capacity for analytical reporting, operational dependencies, systems running queries, and other stuff. The following picture shows how the Standard tier, alongside its close relatives Basic and Premium can be configured in the Azure portal.

The flexible vCore tiers

But there is another whole category of tiers that offers much more flexibility, and that is the vCore tiers. They are structured around vCores (virtual cores) as the unit of computing power instead of DTU. Think of vCores as cores in a CPU. Here is where we find the Serverless compute tier inside the category tier General Purpose. The General Purpose tier looked okay for our usage, knowing that Hyperscale or Business Critical would be much more expensive.

The main price driver here is the number of vCores you want. But how do you know the equal vCores to your DTU found in the Standard tier? A quick Google search told me that ~100 DTU = 1 vCore. Our current tier S9 is 1600 DTU. 16 vCores would be 6000 NOK/month more expensive, so I went with 12 that had around equal price as we pay now to see how it performed. Previously we have been using the one before S9, S6 with 800DTU, but we experienced load problems and had to bump it up, so 12 might be okay.

Testing vCore amount in the Provisioned tier

First, I tested our normal daily operations that require a lot of power with 12 vCores in the Provisioned tier to see that it was performant enough. I was happy to see that the execution time was equal. My goal was not simply to change to a vCore tier, although it has interesting features that I will not talk further about here. I wanted to specifically test the Serverless tier. Having locked down my vCore count without exceeding my budget, I went on to configure the Serverless tier.

The cost of the Serverless tier

As shown in the image below, I configured maximum vCores to 12. I knew that would be performant enough for our most heavy operations, and I let the minimum stay on 1.5 vCores to allow maximum scalability. The cost for the Serverless tier is 0.001294 NOK / vCore / second. This means that the cost calculations at maximum and minimum are as follows:

I sure hoped this wasn't running on max most of the time, because that would be twice as expensive as our current solution, and I am here to save money! 

The Autopause feature

One of my concerns was regarding a feature called Autopause, which is enabled by default. Enabling this will put the whole database to sleep when there is no activity after a given amount of time. That means there is more money to save, but there is a catch. I found an article where I read that the first connection to the database would fail. So, I disabled this feature to not cause any unwanted interruptions for systems or other consumers.

Deploying to production

All our infrastructure is configured in code written as a mix of Powershell and ARM(Azure Resource Manager) templates. I didn't click save when fiddling with the GUI in the Azure Portal. I changed our ARM template to reflect my changes and re-provisioned the database to deploy my change. The configuration looks something like this:

Note the property "autoPauseDelay": -1. This value disables the feature.

What I was most interested in after deploying was the following

Is there any performance degradation while scaling to meet the increase in load?

Would consumers notice anything in terms of response times or performance?

How much would this actually cost us? Can we save money?

To answer my first question, I did some manual analysis by timing known operations and how long they take after the change compared to before. I found it to be of equal performance, if not actually better.

My second question is a bit tied to the first. I notified all our consumers of what I have changed and made them be extra aware while doing operations. I asked them to give immediate feedback if systems, reports, queries, etc. behaved any differently in terms of performance. I am pleased to say no one complained once.

Cost analysis of our database

Then to the most important part of my experiment. How much does it cost? To find this out, I had to monitor my "vCore second" usage manually. Not so glamorous other than staring at a graph in the Azure portal several times a day. By knowing how many vCore seconds we had used the first hour, I could multiply that to calculate predictions about how our monthly cost would look if our current load pattern continued. I then continued calculating such forecasts as the hours and days passed on. That way the cost was under control, and I didn't exceed my budget. If the numbers after say, a few days, showed that this is in fact not cost-effective, I would have reverted my change.

This picture shows vCore seconds used over a pretty average week for our database. Notice the spikes in the load that reflects the daily tasks I mentioned previously, as well as the reduced load during the weekend. If all weeks were like this week, our database would cost 0.001294 NOK * 1.55 mil vCore seconds * 4 weeks = 8022 NOK/month. This is actually not very far from the truth. We have had the Serverless tier running on this database for a little over a month now, and the cost has been 10895 NOK/month. That is nearly half the price of the S9 1600DTU tier!

Now, that we actually managed to cut the price in half is dependent on a few things. Remember that we did not go 1-1 on the DTU to vCore conversion. We managed with 12 vCores equal to 1200 DTU instead of 16 vCores equal to 1600 DTU. This was also because the previous Standard tier S6 only sport 800 DTU. That caused too much load problems for us, and there is nothing in the middle before S9 with 1600 DTU.

Next, the nature of our load patterns seems to be a very good fit for this kind of elastic and scalable approach. We require a lot of power when we are performing some of our important operations and not so much the rest of the time.

Is the Serverless tier always cheaper?

I have overheard others seeing a lot of increase in cost by going to the vCore Provisioned or Serverless compute tier. This approach is certainly not the way for all use cases. If you consider moving away from the DTU model, make sure you actually need the features and the increased flexibility of the vCore tiers. Or that your load patterns make a good fit for a serverless approach. DTU might be sufficient and cheaper for your case.

Conclusion

On this particular database with its spiky load patterns, we actually managed to cut our cost in half without degrading performance using the Azure SQL Serverless tier. My experience is that the database scales fast when required, and backs down nicely when the load decreases. Having this on-demand resource strategy is all about saving money, and for us it did. Be careful if you attempt to try this out, as vCores and especially Serverless tier vCores are more expensive than, e.g., tiers using DTU. Pay close attention to your vCore second usage after deploying and do forecast calculations when the database has experienced normal load after a few hours or days. Good luck!

Prices used in this article are public list prices taken from Azure's websites

Can you save money with the Azure SQL Serverless tier?

As frontend developers, our focus is on the users experience in our application. How fast and efficient the application is and how smooth the functionality can be. We all might say security on our minds, but we often rely on somebody else to handle this. Luckily, modern web frameworks, like React, come with built-in security against one of the dangers of the web – Cross Site Scripting (XSS) attacks. But what does React actually defend us from and more importantly what does it not?

The danger

One of the most common security issues found in web applications is XSS vulnerabilities. XSS is a type of vulnerability that enables an untrusted source to place malicious data or scripts into a web application viewed by other users. Because the browser interprets these scripts as a legitimate part of the code, the attacker gains full access to the current application running in the users' browser. With this access the attacker can bypass access controls, steal the users’ secrets like passwords or credit cards or do unwanted action on behalf of this user.

The most successful way to prevent this attack is to never let untrusted data be a part of your application. This is however not feasible in most cases. Web applications today is often based on user input like comments and status or fields for entering information needed to give the users the services they are requesting.

Another way to protect against XSS attacks is to be conscious of where the untrusted, meaning external, data are used in your application. Whether the data are placed inside two HTML-tags, in an attribute or an event handler of an HTML-tag or in other JavaScript-functions. All untrusted data should be encoded based on where this data are used in your code to ensure that the application only interprets this as data and never as actual application code. If malicious scripts are entered in your application you can make sure the scripts are rendered, but never executed.

Built-in defences

React is one of the modern frameworks that has built-in defences against XSS vulnerabilities. When a component is created, React is aware of the potential of malicious code injection. By default, React will escape all data embedded in JSX. Escaping basically means to remove or replace characters that can be interpreted as code. Thus, insuring that nothing can be executed unless explicitly written code in your application.

One example of an inserted script:

will with escaping output like this:

Because of this escaping it is safe to place untrusted data in JSX like this: return ( <p>{ cristmasCarolFromUntrustedSource }</p> ); as everything is converted and rendered as string. Even if there is a script in cristmasCarolFromUntrustedSource, it will not be executed.

The same also applies with the use of Reacts API and React.createElement("p", { props }, cristmasCarolFromUntrustedSource). React will escape the children and protect the props, meaning the arguments in the createElement function.

React is great when it comes to security and handle a lot of vulnerabilities for us. But React can’t be responsible for it all. Using something secure incorrectly can turn insecure fast. So far React seems quite safe in regards to XSS vulnerabilities, which it is. But what happens when you find yourself outside the scope of React auto-escaping?

#1 Data passed to dangerouslySetInnerHtml must be sanitized

According to Reacts own documentation, dangerouslySetInnerHtml is Reacts replacement for innerHtml. One use case for this function is if a response from an external source is formatted with embedded HTML styling and you want to render it as originally intended.

As shown in the Built-in defences section, escaping converts characters like < and > into &lt; and &gt; and making the rendering of this as string instead of code to be interpreted. As the point of dangerouslySetInnerHtml is to render the HTML given, React cannot escape the input as usual, leaving your component vulnerable for attacks.

Although injecting HTML with dangerouslySetInnerHtml will not execute <script>-tags by default, there are other ways of triggering a script to run. One example is using an event handler on theimg- or in this case iframe-tag like this:

Because of the vulnerabilities attached to this function React has given it an ominous name and making sure developers see the documentation by enforcing the input to be given in a prop called __html. However, enforcing the input in a prop might make developers believe that this value is being escaped, like props normally are when passed through functions in the React API such as createElement.

In most cases, you should avoid using this function and gain the same result by using the react framework. In cases where you find no other options be sure to sanitize the input. Unlike escaping, a sanitizer does not convert or replace characters. What it does instead is look for the unsafe parts in HTML and remove them, leaving our example above like this:

#2 URLs should never be from an external source

We have covered how escaping and sanitizing the untrusted data covers security issues on the web, unfortunately it does not cover the issues linked to URLs.

URLs is widely used in a web application. It can be used for navigation with an a-tag or for getting resources like an image, video or content from another domain in an iframe. Lets use the example with the iframe again only now the iframe is in the application and tying to display content from another page:

This is perfectly safe... As long as you control the url.

Even though React escapes the props in your a-tag there are still valid ways of triggering malicious code which is not handled by Reacts escaping. Thejavascript:

If you let users add their own URLs the chances are you will be exploited. Here is an example:

It is not just a React problem, but it is important to mention to show that React can’t handle every scenario end every threat. It is neither just an iframe-tag problem. The same problem occurs in src-attributes and the href-attribute of tags in general. Trying to fix this by banning the word javascript and remove it will not suffice. The same can be done by using data: like this:

If you need to let the users add urls, try to control as much as possible yourself. For instance, if users are adding links of their favourite react.christmas article, the first part:https://react.christmas/ can already be coded and the user input can then be year and day. Then, javascript: or data: will just be a part of a string and not harmfull. If this does not satisfy requirements check that the URL starts with what you expect i.e http or https.

#3 Keep your framework updated!

This might seem to be an obvious one, but is still an important reminder.

In Whitehat security's annual security report, they found that in one year there has been a 50% increase in vulnerabilities due to unpatched libraries. We use third-party libraries more and more, but it can be hard to be sure if the library has security vulnerabilities or not. In fact, another finding states that as much as 1/3 of all security vulnerabilities are inherited rather than written in the application. Although Reacts developer team strive for security, errors can and will be made. Keep your framework updated as well as other third-party libraries you may use. Another tip for keeping the framework secure and your team updated on known vulnerabilities in your libraries is to use githubs dependabot on your repository. To read more about that check out the blogpost from the [2nd of December in security.christmas](https://security.christmas/2020/2).

I will leave you with this: Never trust data from an external source. It does not matter if it is from a user, an API or the address bar in the browser. Handle this data as malicious and take security measures based on where this data is embedded in your code.

🎶On the third day of christmas a developer sent to me.. 3 React security tips!

As developers, we usually use some sort of pipeline to build and deploy our code. Tools like Circle CI, Gitlab CI/CD and Github Actions are popular. Can your pipelines be a security vulnerability? Can you use your pipeline to create a more secure application?

Pipelines come in many shapes and variants. Usually, they print some kind of console output, which can be very useful when something goes wrong and we need to debug. However, this output might also be of great interest to an attacker. Especially if it happens to contain any credentials or other sensitive information, such as passwords or tokens for code repositories, container-image/package-registries, and so on. Such secrets are often placed in some kind of vault, a mechanism in the pipeline tools for storing secrets. Vaults are worthless if the pipeline print its secrets anyway. Do also take into consideration who has access to read the output from the pipeline.

A good mindset is to consider every dependency as an attack vector. That includes dependencies the application has in runtime, during test, or when built. Of course, the amount of attack vectors should be as low as possible. But, we can not live in total isolation, and need to depend on something. The dependencies we need should be pinned to specific versions. That does also apply to container-images. These dependencies should be monitored continuously, to check that your dependencies does not have any known vulnerabilities.

Your pipeline should include a mechanism to check for vulnerable dependencies in an automated way. OWASP Dependency-Check is a tool for that purpose, and can be triggered by your pipeline. Snyk is also an alternative that is widely used, the same is Github Dependabot, which we talked about yesterday. Just as important as having the tools in place, you also need to establish routines on how to act when they report something is wrong. The value of such tools is very much reduced if you don't follow-up on their findings.

If you have automated build or deploy from your main-branch, make sure that pushing directly to that branch without going through a pull-request first is being rejected. Otherwise, that is a highway into your environments, and will let others run and deploy their code. If you have your code in a public repository, you should never let automated builds be triggered by opening a pull-request. That is basically the same as triggering on direct push. You should instead wait until the pull-request is merged by someone authorized to do so.

Applications usually have some sort of unit- or integration-tests, and these tests are usually run when the application is built. Thus, these tests is also running when your pipeline builds your code. A good idea is to have tests that verifies that authentication and authorization work as intended. You should also have tests that cover how the application handles invalid input. These tests should, as far as possible test the real implementation and cases. They should preferably not require the application to run in a special "local", "mock" or "test"-mode, disabling most of the security mechanisms. Running such tests in an automated way by a pipeline gives you lots of security-bang for the buck.

Even if we all know that we should keep credentials and other potentially sensitive data away from our source code, it ends up there from time to time anyway. The probability can be heavily reduced by enabling a pre-commit hook, that scans the code for sensitive data, before the code is committed. This puts more responsibility on the developers, demanding that they enable the hook on their own computers. While they definitely should do so, it is a good idea to also have a mechanism in the pipeline that will reject to build your code if it contains sensitive data. You can argue that it is too late if the pipeline detects it, as the code already will have been committed and pushed. But, it will give you a chance to act - remove the sensitive data and re-write the commit history. There are a few tools available, that you can use to scan for sensitive data. Repo-supervisor, git-secrets and truffleHog are worth checking out.

This short text is of course not the complete, definitive guide on how to build a secure pipeline. But, we hope it can make you reflect a bit upon your own pipelines, and the pipelines you use, to see if you can make some improvements.

How secure is your build pipeline?

Blås i dævve personas. Blås heller liv i innsiktsarbeidet, og lag historier du tror på selv. Det er først da du kommer nærmere de faktiske folka som bruker produktet ditt.

Så kult at du ramlet inn på denne artikkelen, a! Hvor ble du klar over at den fantes, tro? Uansett. Før du kom helt ned hit leste du sikkert så vidt den tørre tittelen (i manko på å komme på noe bedre), som inneholder ordet "brukerhistorier”.

Kanskje du til og med nå tenker “ja, dette har jeg jo vært borti før. Skrive sånne dølle greier liknende ‘som en innholdsprodusent vil jeg ha et ingressfelt i CMS-et, slik at jeg kan skrive ingresser til rådgivningsartiklene.’ Tror ikke jeg får noe særlig ut av å lese denne artikkelen, altså..”

Og før du trykker på back-knappen, eller brygger deg litt kaffe i stedet, vil jeg bare si at ja, kanskje akkurat dét er litt dølt. Men det hjelper nå utviklerne å sette seg inn i kontekst og forstå hva en person i en bestemt rolle trenger rent teknisk sett. Og hvor dølt hadde det ikke vært for deg å gå glipp av det jeg egentlig skal fortelle om, på grunn av din forutinntatte antakelse? For er det noe vi ofte gjør, kanskje uten å registrere det engang, er det å anta både det ene og det andre.

Uansett kan jeg fortelle deg nå, med en eneste gang, at:

dette dreier seg ikke om slike tekniske brukerhistorier

og..

dette dreier seg ikke om deg eller din arbeidsrolle.

Ikke brukerhistorier-historier. Men tjenestedesign.

Dette dreier seg om historier jeg lærte meg å lage som en metode innen tjenestedesign, da jeg jobbet for en leverandør av TV-kanaler. Men ikke ulikt tekniske brukerhistorier, setter du brukerens behov i fokus. Gjennom gode, troverdige historier basert på reelle innspill under innsiktsfasen, ser du ditt produkt og din merkevare gjennom en reell persons ståsted. Alle som bruker ditt produkt eller din tjeneste har hver sin historie, som forteller hvorfor og hvordan de endte opp med å bruke nettopp ditt produkt. Og hvordan du fortsetter å bruke det.

Alt i alt dreier dette seg om å kartlegge en kundereise gjennom en persons historie, en såkalt persona. Historien forteller noe om hvordan personen blir klar over merkevaren, tar i bruk produktet, kanskje kommer tilbake for mer og forteller andre om det (word of mouth-effekten).

Og kanskje du nå tenker “ja, men persona, a, du. Det er så 2012. Har laget mange verdiløse personas opp igjennom, skal jeg si deg!”, etterfulgt av en sånn latter til hun Signe i NRK-programmet Parterapi (stakkars Tormod).

Skap en verdifull persona

Og det er nettopp dette jeg ønsket å utfordre med noen litt.. ikke uortodokse, men kanskje mer autentiske teknikker.

Men la oss ta det første først: Jeg jobbet sammen med en tjenestedesigner da leverandøren av TV-kanalene ville ha hjelp av oss til å lage nettopp personas. Men de ville ha personas som ga mening, og som flere avdelinger kunne forholde seg til i sitt arbeid. Målet var å få færre til å “churne”. Altså nei, ikke å kinne smør, som er ordets opprinnelige betydning på engelsk, men at færre skulle si opp abonnementet sitt etter en viss periode. Altså at de heller skulle få mer nytte av sitt abonnement fremfor å stivne og bli passive kunder. Kunden vår følte de manglet en nerve i sin kommunikasjon med brukerne. Og hva kan gro en slik nerve? Empati. Hvordan utvikle empati? Med innsikt.

Sanne historier basert på brukertester og -intervjuer

Så for at disse personaene ikke skulle bli like stive, tamme og tradisjonelle som kaldt, ferdigkinna smør uten salt, måtte det troverdige historier til. Historier fulle av følelser og detaljer. For er det noe vi ønsker å få ut av en innsiktsfase der kundereisen kartlegges, er det å virkelig se hva den totale opplevelsen av merkevaren gjør med menneskene som kommer borti den. Altså ikke å anta, men å vite.

Derfor brukte vi informasjonen vi fikk fra brukertestene og -intervjuene med ekte, eksisterende kunder som alle representerte hver sin målgruppe, til å lage historier som stemte godt overens med de viktigste detaljene fra intervjuene. Vi brukte personene til å inspirere oss i valg av alder, bosted, fritidsaktiviteter, øyeblikket der personen fattet interesse for produktet, installerte det og brukte det. Vi brukte deres sjargong og tilpasset oss språket i hver enkelt historie etter hvilke ord de selv brukte. Og så la vi til ulike opplevelser og følelser knyttet til hver situasjon basert på hva som kom frem i intervjuene.

Awareness, bestilling, pre-installering, installering, i bruk

Når du skal kartlegge en kundereise for en bestemt merkevare, bør fasene tilpasses produktet. Er det noe som må lastes ned? Sendes fysisk? Installeres? Monteres? Dersom en slik situasjon tar stor plass i kundereisen, bør det som foregår der vies en hel fase til.

I vårt tilfelle bestemte vi oss for disse fasene:

Awareness – hvordan blir kunden oppmerksom på produktet?

Bestilling – hvordan bestiller kunden produktet, og hvordan føles det?

Pre-installering – hva slags kontakt har kunden med merkevaren før produktet blir installert?

Installering – hvordan foregår installeringen fra kundens perspektiv?

Bruk – hvordan blir produktet tatt i bruk av kunden videre? Hvordan er livet til kunden etter at produktet kom i det?

Det hører også til historien at vi var ganske inspirert av typisk kundereisekartlegging, også kalt customer journey mapping, som dette:

Så vi var vel litt preget av språket da vi selv definerte fasene, prøver jeg vel kanskje å si her.

Sett historien opp som et manus

Etter intervjuene ble vi enige om hva slags inntrykk personene ga. Igjen satt vi med beskrivelser på deres personlighet. Nå var den største jobben foran meg som tekstforfatter: La personligheten, språket, følelsene og opplevelsen av merkevaren skinne gjennom i historiene.

Jeg skrev historiene fra start til slutt i et tekstdokument. Lot tastene sprette og poengene fare, uten å ta hensyn til hvilken fase personen jeg skrev om var i. Da historien var skrevet ferdig, satte jeg de ulike scenene inn i faser. Jeg sørget også for at hver enkelt scenen hadde nok detaljer til at det hele kunne eventuelt tegnes — ja, til og med filmes, om noen ville! På den måten kunne kunden velge ulike måter å formidle historiene på.

Ett av fem resultater kan du se nedenfor. Da kan du forsøke å holde et ark over fanene til høyre, og kun lese den flytende teksten nedover, for så å lese scenene beskrevet, og hvilken fase de er i etterpå. Stemmer det overens med inntrykket du får i selve teksten?

Bry deg om personaene. For de finnes faktisk. Til en viss grad.

Så dette var altså min beskrivelse av personaen Anne på 47 år. Anne som blir kunde av Viasat. Følte du noe for henne? Klarer du å se henne for deg? Ble du nysgjerrig på henne?

Det tar gjerne et liv å bli ordentlig kjent med en person, sies det (okei, jeg sa det i hvert fall nå). Men forteller du en historie av en persons liv grundig og interessant nok, kan det være det som nettopp trengs i en merkevare- og markedsføringsammenheng.

Derfor er det gull verdt å lage unike historier om halvfiktive personer som representerer en bestemt målgruppe knyttet til ditt produkt, når du ønsker å forstå mer om dem. Og det gjør du ved å servere små gullkorn, detaljer og beskrivelser i historien. Litt etter litt vil du få et klarere bilde av hele kundereisen til personen du har med å gjøre. Og dette er ikke noe du bare finner på; det har selvfølgelig en viss grodd rot til virkeligheten. Og hvorfor har det det, tro? Jo, fordi du har brukt reell, kvalitativ innsikt. Som igjen har gitt en unik mulighet til å utøve empati når dere fremover har kontakt med både potensielle og eksisterende kunder. Da skal du se det blir mer liv i produktet ditt, også!

Verdien av gode brukerhistorier

The Kotlin standard library has a lot of amazing stuff and today we will take a closer look at what let, run, also and apply is and when to use them.

The two things they all have in common is that they create a new scope where we can do stuff and that we can use them on all the types. If we look at the signature of the different methods some of them are more similar than others.

Let's start with a brief introduction on how to read the signatures above. The first part is the generic types the function uses, the letter doesn't matter, but what matters is how many letters there are. Each letter corresponds to a generic type, which can be whatever. The second part is the function and the parameters it takes in, in this case they all take functions as parameters. Lastly we have the return type which matches one of the generic types.

So if we take a closer look at what the definition of let is we can see it uses two generics. First we have the generic T which is the type we can run .let on, which means we can run it on anything that is a type (e.g. a data class, a boolean or a list). The second type is R which is both the return type and the return type of the function we pass as a parameter. This means we pass in a function to let that return whatever and that type will be the final result of calling .let on something. If we have an expression like "hello".let { it.length } we can see that the function we pass returns an Int and because of that we also know that the return type of the whole expression will be an Int.

Let's take a look on what this means in practise:

Here we see that both apply and also returns the object we invoked them on, while let and run returns something new. If we look back at the signatures we can see that this matches the generics and the return types.

Side note: If you're wondering about the T.() syntax that is used by run and apply to access properties like name directly check out last year's article about Receiviers

Why and When

So the big question is when and what should you use? After working with Kotlin full time for almost 5 years I’ve found myself leaning more and more towards using let and also and very seldom using apply and run. Let's explore why that is! The main reason for that is that both let and also use an explicit parameter, and when having any nested code at all, makes it much more clear what is happening.

Apply

The example often used to highlight the power of apply is changing properties on a class, which assumes that we are working with mutable data. If we are talking about a Kotlin project with minimal Java code in the code base then that might be a code smell, but apply is useful when interfacing with the Java builder pattern modifying properties that typically are mutable.

In this example Apply is perfectly fine. But when working with immutable data we typically wont use apply. Let's look at an alternative to apply.

Also

Also works very similar to apply, except that instead of having implicit access to the properties of the thing we are invoking it on we get the reference passed to our lambda.

A good example for when to use also is when you want to log some information while doing a chain of operations.

Here we see the beauty of the standard library. By using .also we avoid assigning an intermediate result just to log it and I personally think the code reads a lot better when using also.

But back to .apply, why shouldn’t we use apply in this context?

For this simple example using apply is totally fine, but once we start nesting expressions this will get pretty messy pretty fast.

In a real application you will most likely have more code surrounding the places where you use apply/also and then using .also over .apply even in the simple example makes it much more clear where the properties come from. Prefer clarity over concise.

Let

Let is very useful and can be used for a range of things. You can use it for null checking, creating a new scope and it can be used to make your code more readable.

Normally you would use the elvis operator for null checks, but if your code needs to do something more than just returning a default value it might not be feasible to use the elvis operator.

Here .let allows us to nest code and do more than what you would normally be able to do when using just the elvis operator. Let is also great for when we want to chain operations.

One thing to be weary of when using let is that creating new scopes aren’t always the way to go. Moving some logic to a function, instead of having everything in a single expression, may make the code easier to follow.

vs

Run

Run is kind of weird. It’s a mix of both .apply and .let, it has the behaviour of let and the implicit nature of .apply. What this means is that we can use properties without explicitly referring to the object and the last line of the code block will be returned.

At first glance it looks pretty useful when the object you are working with both has some mutable variables you want to change and you also want to create something based on what you changed. Let's take a closer at another example:

Here we create an instance of Server, mutate the port variable and call the function createServer on Server. Confused? Me too. Even in this small example I would argue that using either let or apply would give us more clarity on what is happening here. Is the createServer function part of the Server class or is it a function somewhere else? The problem though is that you very fast lose clarity of what you are doing when using run. I would argue using apply or let is almost always better than using run. Let us rewrite the example with using let and apply and see if it makes our intention clearer.

Better

Best

I would not recommend using run if you aren’t sure what you are doing, it might offer more concise code, but in my experience using run often results in confusion when coming back to the code at a later point.

Summary

So what have we learned? They all have their place, but being explicit is often a good idea. If you’re unsure what to use, stick with let and also and try to keep your code as clear as possible!

Why and When: let, apply, run, also

One of the great things about Elm is the ability to easily and accurately model your data with the use of custom types. Custom types are normally used when a type can have multiple shapes, or represent multiple state. For instance, you can create a custom type to represent the state of a user in your webapp, like this:

In this example, a user is either not logged in, in which case we don't have any data about the user, or the user is logged in, and we have some user data. We call the two "variants" of the custom type (NotLoggedIn and LoggedIn) the custom type's constructors. Since they are, in fact, functions that return a value of type UserState.

Single Constructor

Even though custom types usually have at least two constructors, you can actually create custom types with only one constructor. This might seem pointless the first time you hear about it, but it can be quite useful in certain situations. We will examine one use for these single-constructor custom types in this post, while we will look at another (probably more widely used) use for them in a post later in December.

In our use case, we will consider the situation where we have a function for calculating body mass index (BMI) in our app. A person's BMI depends on their weight and height, and can be written like this (using kilos for weight and meters for height):

Now, while this function works correctly, it's not exactly a pleasant experience to use. Consider, for example, the following code, where we use the bodyMassIndex function:

Did you spot the error? No? Well, neither would the Elm compiler. The error is that our bodyMassIndex function expects the first argument to be weight, but we passed height as the first argument. While the person using our bodyMassIndex function would probably notice their error quite fast, it is still unnecessary that we allow for the error to be made. This is an example of where we could use single-constructor custom types.

We can start by making two single-constructor custom types:

Both constructors of the custom types have the same name as the name of the custom type, which is normal to do with single-constructor custom types. Next, let's say we change our bodyMassIndex function to have the following type signature:

Now we can use the new version of bodyMassIndex in the view:

If we did this, we would get a compilation error, saying that bodyMassIndex expects it's first argument to be a Weight, not a Height, which is what we wanted to achieve!

The price of this refactor, however, is the added complexity to our bodyMassIndex function, since the most basic implementation of the new type signature would look something like this:

Cleaning Up

At this point, you are probably thinking that this just isn't worth it. Because that is one ugly function. But don't worry, Elm has a neat trick for making this function almost as simple as the first version, which had only Floats as arguments.

Similarly to the technique described in yesterday's post, where Jørgen showed that we can pattern match on fields in a record in the argument definition of a function, we can also do this with single-constructor custom types. The name of the constructor and the variable name you want to use is written inside parenthesis in the function definition, which makes the function almost identical to the first version of the function:

The overhead of making a refactor like this is now almost nothing, and can, in certain situations give your code guarantees that it otherwise wouldn't have.

Worth noting is that this pattern matching only works with single-constructor custom types, not custom types with multiple constructors. And, as mentioned above, we will see another use for this technique of using single-constructor custom types, later in December.

Single-Constructor Custom Types

Back in 2009, Ryan Dahl entered the stage on JSConf and presented his newest project, Node.js. And since then, Node has grown into an enormous ecosystem with over 1.5 million packages on NPM.

9 years later, during JSConf 2018, he enters the stage again. This time, he apologizes to the JavaScript community and discusses the 10 things he regrets about Node. Towards the end, he reveals his new project, an alternative framework for JavaScript development.

The new project is called Deno. And this year, Deno finally left the alpha stage, offering a stable CLI and solid documentation. Which means it's the perfect time to have a closer look!

Server-side development, reimagined

Deno's official philosophy is to be a productive and secure scripting environment for the modern programmer. Simply put, Deno enables you to execute JavaScript straight in your terminal, without the need for a web browser.

Sounds like Node, doesn't it? Yes. Like Node, Deno is built upon Chrome's open source V8 engine, which compiles our JavaScript to machine code. Like Node, Deno comes with a simple command-line interface. Like Node, Deno is made by Ryan Dahl.

Still – Deno is a new take on server-side JavaScript, offering a more modern design:

Security by default: In Deno, programs run without special permissions like access to the file system, network access and read-access to environment variables. There are special flags for enabling and fine-tuning these permissions for programs you trust.

TypeScript compatibility: Deno supports, and encourages the use of TypeScript without any additional configuration.

Standard modules: Deno offers an audited set of standard modules for things like filesystem access. This also includes APIs common in the browser, like fetch and the window global.

Built-in utilities: Deno comes with a set of handful utilities like a formatter, linter, a file watcher, script bundler, a testing framework and much more.

The built-in utilities may be the biggest selling point of Deno, supplying the developer with a set of commands only available in Node through a large number of third-party dependencies. Just look at all these tools! 🛠️

Kill the package manager

Node can do almost all the things you get from Deno by using said third-party dependencies. These are installed using NPM, the Node Package Manager. NPM has seen some criticism over the years, regarding both the centralized registry and the comically large node_modules folder. Despite these challenges, it remains a user-friendly method of bundling other people's code into your own application.

Deno, on the other hand, has taken a very different approach. Dependencies must be specified with a full url:

Speaking of dependencies – Deno does not use require(), as we all know from Node. Rather, it uses the superior syntax of ES Modules! That means you can import and export dependencies just like you would in a browser app.

Anyway, this design decision of importing full URLs has a bunch of consequences. First, there is no need for a centralized package repository. There is no NPM equivalent for Deno, there are only URLs. In addition, since the version is also included in this URL, there is no package.json file for listing dependencies.

I must admit, this didn't sound very compelling to me. Imports getting more verbose, and no common registry to search for dependencies? But here's the thing. As explained in their documentation, Deno doesn't try to be a full replacement to Node. And they do admit Node and NPM is likely to exist for a while. Rather, Deno tries to be an alternative JavaScript framework, a toolkit better designed for certain tasks.

A Swiss Army Knife

Over the years, I've come to love JavaScript, and TypeScript even more so. To me, it's the perfect language for hobby projects, automation, app development and so on. As for scripting, I've written my fair share of Python and Bash, but I still prefer TypeScript.

Node is not always a pleasure to work with. You cannot use ES Modules out of the box. To compile TypeScript, you need a plugin like ts-node. You format your code with Prettier, check it using ESLint, use Nodemon to watch for file changes and Webpack for bundling your files. To test your code, you need an external framework like Jest. The list goes on. Deno offers all of these tools, plus more, in a single executable – like a Swiss army knife of JavaScript development.

Then there's the little things, such as the window global. In Deno, you can use alert, prompt and confirm just like you would in a browser:

You also get an implementation of fetchfor doing network requests. You can gracefully manage lifecycle events just like you would in the browser. When you're done, you can even install your script as an executable for your shell environment, with the deno install command.

All these features amount to a great developer experience in JavaScript's matured ecosystem. And for that, I think Deno deserves a place in our toolkit, alongside Node.

Deno, a framework for JavaScript-ing

Elm is young language in the grand scheme of programming languages, but the community has still managed to produce some classic and defining talks. For some people in the community these are well known and for others these might be a discovery.

Even though these talks are Elm talks they have lessons that can be applied to other languages as well.

The life of a file - Evan Czaplick

Link: https://youtu.be/XpDsk374LDE

Length: 47 minutes

In this talk Evan addresses the question "How do I grow Elm code?". Along with practical examples we get some great insight into how to think about different solutions and modeling the problems space with our code. It is also exciting to get a peak into the mind of the creator of Elm.

Making Impossible States Impossible - Richard Feldman

Link: https://youtu.be/IcgmSRJHu_8

Length: 25 minutes

This title is so iconic, it has almost become a meme! 😎 The talk illustrates how getting your data model right can remove a lot of issues and get rid of those pesky "This should not happen" situations in your code.

Elm Radio reflections

For those interested in nerding out on these topic I would recommend checking out the two corresponding episodes of Elm Radio where Dillon Kearns and Jeroen Engels reflect and discuss these classic talks.

#013 Make impossible states impossible

#014 The life of a file

In closing

What are some need-to-watch talks for you language of choice? Are there other talks in the Elm community that you would highlight?

3-Dec

Today's posts