January 31, 2018

Xcode X at WWDC? 🤔


January 30, 2018

I guess this will be a week with a lot of podcast skipping, because I don’t give a shit about the HomePod


January 30, 2018

Hello World?

Exception handling.

January 30, 2018

Handling exceptions is a pain in the ass no matter what language you use. I hate it in JavaScript, I hate it in C# and I hate it in Python. Exceptions are in many ways the least horrible way to deal with errors, at least that I know about.

Most languages that have try / catch or try / expect(python) syntax let you specify a exception or not. This means that you add multiple blocks of code to deal with different scenarios.

For example:

  • Try to read a file

  • Do this if the file doesn’t exist

  • Do this if we don’t have the permissions

  • Do this if the file is empty

  • Do this if we receive some other error.

This is not possible with the current catch(error){} syntax in JavaScript. But there are some ways to simulate it.

It’s not perfect, but it is a start.


January 29, 2018

Spacemacs have been on my radar for almost two years at this point.

I have been using Visual Studio Code for close to two years, and then Sublime Text since 2011, and Textmate since 2008; and before that in in between I have used VIM for close to 15 years.

I decided to try to make the jump because I was becoming more and more unhappy with Code, and when I tried to get VIM to do the same kind of things that was possible with Code the result was never good enough. But then I discovered that Emacs might be the perfect fit, because most of what I wanted was posssible in a more elegant and stable way.

The reason I never gave emacs a change was because the keyboard shortcuts drove me nuts, and the learning curve was very high. But everything was way more apporachable with Spacemacs. I decided to initially give it a week. And I was sold after just a few hours.

The power of emacs have given me a real performance boost. And I have moved a lot of stuff I used standalone apps for over to emacs since then.

Yarn vs NPM

January 29, 2018

There are two widely used package managers for Node at the moment. One of them comes bundled with Node, and then you have Yarn.

The argument for using yarn over npm used to be a lot stronger before NPM version 5. Because, back then nom did not use a lock file. A lock file is a file that keeps track of the dependency graph between changes. This means that when you don’t change your package.json, yarn or npm will read their lock files (if they exist) when install your projects dependencies. It saves some time because instead of going through the package.json in your dependencies and their dependencies and so on, it will just read it from a single file.

What to use in 2018?

To use the existing package format from NPM was probably the smartest thing yarn did. Because everyone with a working package.json file could just run yarn install instead of npm install. I still keep lock files of both up to date and checked into git in most if not all of my projects. Parts of it is because of stuff I haven’t updated, other parts is to make sure people I work with can use what ever they are comfortable with.

I prefer yarn over npm because I think the way the command line interface have been designed makes a hell of a lot more sense. And because it is a lot faster. But yarn can be very aggressive on your bandwidth, and npm might work better if you don’t have the best internet connection.

Even with the changes that have come to npm the last year, yarn is faster. And I guess they have a lot more freedom to make something that is a joy to use when they don’t need to think about compatibility.

Imagine how many much stuff that would break, including tutorials if NPM did a re-write that changed the interfaces?