Hjertnes.blog

#

December 03, 2017

When I observe people discuss Net Neutrality I think back on the most important skill I got out of my philosophy degree. And that is to look for an understanding of all the different sides and to identify the different layers of opinion.

In this case you have those who think NN is a good idea, and you have those who don’t. And for those who think NN is the way to go you have different opinions regarding how to do it. Some think Title 2 is the best option, while others think that approach is a little bit too heavy handed.

I don’t have any particular opinions on how we get there. But I think that there shouldn’t be any differences. All traffic is treated equal. And ideally no transfer cap. You pay for a certain speed, and that’s it.

One of those typical “deals” I see from certain carriers that really annoy me is that “Spotify or Netflix doesn’t count against your data cap”.

It is a bad idea to have it if it is only limited to one service for music and one for movies. But would it be a problem if it was all music and movie streaming? As long as it was easy enough to be approved as either.

Import and Export

December 01, 2017

A important note: this article is intended to be a explaination of how you can import and export code using ES6 modules. It doesn’t deal with how the various other schemes work or how you should do it in node. And it doesn’t deal with how to make sure the different schemes interact with each other. This is simply put how I do it in my Webpack + Babel based projects.

The way we are going to deal with modules in Javascript in the future is by the import and export pattern. You are probably used to it, if you are using babel and or webpack as a pair of your tool chain. There are some support for it in node, but the support are rather limited, and I haven’t looked much on it, except for seeing in the change log that some support were addeed.

The basic idea is that the code in one Javascript file, is not visible to be imported into another Javascript file, unless you tell it “hey you can import this”. Each file can have one thing that is the default one, and any number of other exports. If you are using React the default export might be your compoenent connected to Redux, but you might also want export the component without that; then the connected might be prefixed with “export default” and the other prefixed with just “export”.

For example:

The code above is intended as a demostration only, it doesn’t work because it is missing some imports and so on.

If you have some piece of code, that is marked with export default then you import it with import WhatEverYouWantToCallIt from './Filename', and if you prefix it with just export then you import it like this `import {theNameInTheModule} from ‘./Filename’.

The biggest difference is that the default is imported without {}, and you can call it what the hell you want; while the rest need to be imported with their actual name and you need to place {} around it or them. The import export syntax introduced in ES6 is far superior to what we had before it, and is very intuitive as soon as you get a grasp on {module} vs module and export vs export default. This is without one of the “Javascript starts to feel like a real programming language” moments.

#

November 30, 2017

Should I connect the feeds of my blogs into micro.blog? 🤔

#

November 30, 2017

I get why some people want an iOS laptop or iPad laptop. While at the same time realizing it would never be for me. I would be perfectly happy if Apple would make their keyboards reliable again. And maybe a SD card slot?

Immutability

November 30, 2017

You basically have two different ways which you can change the contents of a variable. You can change or mutate it, or you can repalce it. There are good and bad sides to both. The biggest advantage of mutating data is that it is more efficient. While the biggest advantages of Immutability is that you often avoid a certain type of very difficult to avoid bug and that they are easier to understand.

Let’s take the following example. You have a toggle button, that changes the status of a list or selection of items. And it crashes 20% of the time when our CEO uses it. If this was a mutable method you would end up in a interesting place, because parts of the data set would be in one state, while the rest would be in another. While it wouldn’t be a huge problem if we used a immutable method like .map, because nothing would happen until we complated the map and replaced the exisitng state.

When you deal with immutability, you can write very simple methods that take any number of arguments, makes a copy of the data and changes it, returns a new copy. This means that it only needs to know what it is supposed to do and it will always do the same thing with the same input. WHile a immutable method might live in a class, and attributes defined in the class instead of arguments.

What happens if some other methods change one of them in the middle?

I personally think that using pure functions, that returns a new copy of the data and gets all the “state” as parameters is a much clearer and less buggy way to solve problems. More reliable code is always better than the fastest possible; right?

Moving code to gists

November 30, 2017

For various reasons I have moved this site over to WordPress; none of them are very important in the grand scheme of things. Anyways. I have been spending quite a lot of time trying to figure out how to best deal with code in these blog posts. And I have come to the conclusion that the best compromise between work I have to do, and the best possible expereince for you as a reader of this site is to embed GitHub Gists.

#

November 29, 2017

When I wonder: why haven’t I spent much time on micro.blog this week, the answer is almost always in wakatime.

#

November 29, 2017

I remember when I was very happy with like 10 good pictures out of a roll of film

Adding elements to an array

November 29, 2017

I spend a lot of time on this site trying to convince people that immutable data structures are the way to go. They might be a little bit more difficult from time to time, and a little bit slower; but I believe it is worth it because when you use immutable techniques instead of mutable you know that you need to actually tell your code “replace this with this” for something to change. And I believe it is a good way to avoid a lot of annoying bugs.

The standard way to add a element to a array in Javascript is using the push method like below:

Or you could do it with concat, which is the way I prefer to do it:

The result is the same, but with the latter you can do what ever you want with the list, without worrying about fucking up the original, before you explicitly tell it to be replaced.