Runar Ovesen Hjerpbakk

Science-based software development

Testing Azure Blob Storage using xUnit

Azure Blob Storage is persistent cloud data storage for any kind of unstructured data. Slack Profilebot uses this service to store a whitelist of users with incomplete profiles that should not be reminded to update their profiles. Every user is represented by a file containing that user’s id. This is complete overkill, I know, but it served a purpose. It taught me both how to use and test Blob Storage.

Read More

Two Xamarin.iOS build errors

I’m creating a new Xamarin Forms app using a PCL-project for shared code and an iOS project for the iOS specific details. After a short hiatus, I upgraded to Visual Studio for Mac version 7.0.1 for a nice morning of coding. No such luck, the iOS project would not build.

Read More

Make the macOS firewall to permanently allow iOS apps running in the simulator

macOS has an awesome firewall, however the default setting is very harsh for us iOS developers.

Read More

Profilebot - the profile checking Slackbot for you!

In a large Slack team, it’s important that user profiles are completed enough for the users to recognise each other. Profilebot is a simple bot used for validating Slack user profiles. It is written in C# and it’s easy to extend for all your profile checking needs. It runs out of the box either as a console app (Windows) or a Windows service.

See the source on GitHub.

Read More

Open folder in Visual Studio Code from the Finder

When working on many simultaneous projects with Visual Studio Code (VS Code), it is convenient having a fast way of opening the project folders. With the open from the terminal shell extension, and the macOS service below, your project folders can be opened from both the Terminal and the Finder.

Read More

Isaac Asimov wrote almost 500 books in his lifetime—these are the six ways he did it

Isaac Asimov was a hero. An awesome author and an ambassador of wonder. A master of science fiction with the science part remaining.

And he wrote.

A lot!

To match the number of novels, letters, essays, and other scribblings Asimov produced in his lifetime, you would have to write a full-length novel every two weeks for 25 years.

I know my productivity is nowhere near that. So how did he do it? The linked article has 6 reasons. Below is my take on them as a professional developer:

1. Never stop learning

That’s an easy one. If you stop learning in our profession, you’re done. The physics of programming is in constant flux. Hardware and network advances brings with them new application models. The fashion changes, so too does our user interfaces. You might be comfy at your current gig, but what about the next one?

Asimov read, a lot, about all kinds of different subjects. We too can learn the different nuances of development and bring our experience from other problems, languages and frameworks with us to our current problem.

Not only do we have books to learn from, think about the many learning opertunites online, from Pluralsight to MIT.

And if you ever get tired, retire to a comfy job at NASA. But that position has already been filled.

2. Don’t fight getting stuck

Getting stuck gives you an opportunity to work on something else for a while. Pair with a colleague, learn from someone, work on another task. Your brain is still working on the original problem while you’re busy doing something else.

In a personal setting without a team around to help, getting stuck on your most important project is OK if the second or third most important project is also important! Do not stress if the first thing on your TODO-list is not getting done, as long as other valuable task keeps being finished.

3. Beware the resistance

Self-doubt is the mind-killer.

Yes, what you create will have bugs, not everyone’s going to love it, it is not perfect and that’s OK. Do not let the fear of failure or what others think keep you from accomplishing your goals.

This is the resistance.

So try that hard task. Start, even if you do not see the whole solution yet.

4. Lower your standards

As in the former advice, you’ll not achieve perfection on the first try.

Never has that been more true than in software development. Iteration is the name of the game. Start small and build on it, every iteration better than the last.

And how do you know if it’s better? Let the user try it every step of the way.

5. Make MORE stuff

The more you create, the less each thing matters. Thus, if your just good enough app flopps, you’ll have your mind occupied with the next one.

This intensifies the peace and calm of his life.

This means no sacred cows. Being sentimental towards your creations is an activity for retirement. The code you wrote yesterday might be crap. And that’s OK, you’ll write more today.

6. The secret sauce

How did Asimov get ideas?

By thinking and thinking and thinking till I’m ready to kill myself.

This means that if your creativity got you down, do something about it. Take a break, change your physical location, brainstorm with your colleagues. Do not wait for a divine spark of inspiration, be proactive and work for it.


Turns out being a writer is hard work. It takes dedication and focus. Sometimes also sacrifice. You need self belief and a sense of self worth, even if others find your work lacking, all the while learning along the way.

This is also required for being an awesome developer.

Fluid Width Video

While creating the site used to document my paternity leave, I needed to embed a video on how to roast duck breast in the oven. Embedding a video from YouTube is easy, but Google has specified both its width and height in the embed snippet. This was good enough 10 years ago, but not today with all our fancy responsive web design.

The linked post has many solutions for embedding video with a responsive width based on the users current viewport. I use the method below and it works perfectly.

.videoWrapper {
	position: relative;
	padding-bottom: 56.25%; /* 16:9 */
	padding-top: 25px;
	height: 0;
.videoWrapper iframe {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
<div class="videoWrapper">
    <!-- Copy & pasted from YouTube -->
    <iframe width="854" height="480" src="" frameborder="0" allowfullscreen></iframe>

Why Do Achievements, Trophies, and Badges Work?

From The Psychology of Video Games:

Eight potential reasons why badges, achievements, and trophies might work are:

  1. They anchor our performance expectations higher
  2. Having goals increases our self efficacy
  3. Completing goals leads to satisfaction
  4. They create goal commitment
  5. They act as guidance mechanics and provide feedback
  6. They facilitate psychological flow through feedback
  7. They trigger social proof
  8. They trigger motivating social comparisons

Agile is full of ceremony, some of which remind me of these points:

  • The team’s velocity anchors the team to what is considered a good performance
  • The sprint goal can communicate expectations beyond the team’s previous velocity
  • A successful sprint can be celebrated
  • If the goal was reached with time to spare, the team can be more ambitious next sprint
  • Progress is tracked through the sprint dashboard, Kanban board or other post-it heavy contraptions

Xamarin.iOS app crash on startup in simulator

I updated to Xamarin Studio 6 this morning. A beautiful update with dark mode, full Roslyn support and prettier icons. And it prevented my Xamarin.iOS app from starting in the simulator.

Read More

Scriptcs IntelliSense in Visual Studio Code

We’ve lately rewritten our build systems at work using scriptcs. Scripts with C# as the language with full access to the rest of .Net. Aka PowerShell as it should have been. This rewrite has been awesome for several reasons:

  • Ease of use: Since we’re a C# shop, writing the build system in scriptcs is both convenient and time saving. I still remember TFS 2012 XAML based builds with dread.
  • Flexibility: The build system is build server agnostic, the same script can be used on Team City, TFS, locally or on any other server
  • Ownership: The build system is now so trivial that every team can easily understand and extend the system when needed. The build system becomes part of the product, not something the other guys do.
  • Server or local? Same, same: The same scripts are used locally and on the server. The previous XAML based builds were an opaque mess.

Read More